--- message from comp.os.linux.development.system ----------------------
From: chadr@brttech.com
Subject: BUG: IPX interface deletion
We've been using our server as a PPP dialin for some time. We only just
expanded it to handle IPX-based clients, as some of you may know from my
previous messages. :-)
I'm having a problem that appears to be in the kernel itself. I've contact
the authors of PPP but I'm not sure they can solve it - the kernel really
isn't their fault! The problem has occurred across 2.2.0e and f, across
kernels 1.3.87-pre2.0.7 (the spread I've been testing this across).
The problem comes when the PPP client disconnects. The kernel should kill
the route so it doesn't know about it anymore. It's not, and when the
client reconnects they cannot use IPX because it will reject their IPX
network address.
I got a line in my messages saying:
date pppd[PID]: ioctl(SIOCSIFADDR, IPX_DLTITF) 22: Invalid argument
PPPD is calling the ioctl required to delete the IPX interface, in this case
ppp1. It's getting EINVAL back.
The routine it's calling ends up in net/ipx/af_ipx.c in the kernel code.
The routine there wants to look for the IPX interface and call a deletion
function on it, which should be fairly normal. The problem is, by the time
it gets there the interface has disappeared and become invalid.
I put some debugging code into my kernel (apprehensively <G>) and was able
to determine what my IPX setup looks like. During normal operation, the
linked list ipx_interfaces has a single entry, which is my ethernet card.
When a PPP client connects and requests IPX ability, a new node is added to
the list for them. There are then two entries, in order they are the
ethernet device and the PPP device.
When the PPP client disconnects, for some reason the PPP entry disappears.
The list gets a new node, but is reversed. The new node, then the ethernet
node, in order. The new node has a NULL pointer and a 0 datalink type - it
just looks invalid all across the board. I don't know where it comes from.
This happens BEFORE the ioctl call from PPPD. So of course by the time it
gets there it can no longer find the interface to delete, and returns with
an error. Something must be getting there first, but whatever it is isn't
doing the job, because the clients have to change their local network
numbers to new values each time they dial in, QUITE ANNOYING.
So what could be happening? I'm not the kernel hacker I wish I was - who
is? Who can I talk to about this? This seems to be a pretty serious bug,
if clients have this problem... If anybody wants to help out I can provide
all the information and testing you require... I traced the deletion ioctl
and I can confirm that if the interface didn't disappear before it was
called, it would have found it - everything matched the dialin's entry.
Thanks,
Chad
------------------------------------------------------------------------------
Chad Robinson (Task) "May you live in interesting times."
chadr@brttech.com - Chinese curse
------------------------------------------------------------------------------
-- Henrik Storner | "Life is like a 10 speed bicycle. storner@osiris.ping.dk | Most of us have gears we never use." http://eolicom.olicom.dk/~storner/ | C. Schultz