Linux-kernel mailing list archive 1999-37,: Probable bug in handling disabled network interfaces (2.2.12)

# Probable bug in handling disabled network interfaces (2.2.12)

Karl Kleinpaste (karl@justresearch.com)
17 Sep 1999 18:37:43 -0400

- Messages sorted by: [ date ][ thread ][ subject ][ author ]
- Next message: Richard B. Johnson: "(no subject)"
- Next message: Dipl.-Ing. Uwe Koloska: "Re: bug in socket.h (and maybe many other kernel headerfiles)"
- Previous message: Jeff Garzik: "Re: Turning lucent winmodem into soundcard"

[ To linux-kernel and cipe-l. For l-k readers, CIPE is Olaf Titz's
crypto IP encapsulator, useful as a basis for VPNs tunnelled over
the greater Internet. ]

I'm running 2.2.12 under RH6.0. I see no references in the 2.2.13preN
announcements to anything like this.

I've run into what I consider a probable bug in how interfaces that
have been disabled are mishandled. A brief description:

I have a normal system, with interfaces lo and eth0, and typical
(minimal) routing. I add this network tunneller, CIPE, which employs
a pseudo-interface called cipcb0. cipcb0 is used normally for a
while, having been configured by a daemon peculiar to that device
(ciped-cb). Now the daemon is gone, and so the device has been
configured down, though not using ifconfig(8) itself, with the module
still loaded. If you ask about it with "ifconfig cipcb0", the
interface is present, with all configuration data still intact, except
that the UP marker is missing, of course. The result...

The system still responds to the address associated with cipcb0. It
responds to ARP broadcasts, evidently on the assumption that, having
received the ARP and noticing that it had /some/ interface with that
address -- even a disabled interface -- it responded affirmatively,
with its own eth0 mac address. So any ensuing conversation with other
systems is carried out, *without* the support of encrypted tunnelling,
simply acting as though eth0 had an alias which happens to be the
(disabled) cipcb0's address.

"rmmod cipcb", so that cipcb0 truly disappears, makes the system stop
responding to the downed interface's address.

I would contend that the proper reaction of the system would be not to
answer the ARP query in favor of interfaces currently marked as down,
or in fact to process any packets at all received for downed interfaces.

An associate's reference to hypermail coughed up
http://www.uwsg.indiana.edu/hypermail/linux/kernel/9903.0/0854.html
but this is a different case, and I assure you, "ifconfig cipcb0"
shows the interface as down (er, "lacking UP").

Opinion, counteropinion?

--karl

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/

- Next message: Richard B. Johnson: "(no subject)"
- Next message: Dipl.-Ing. Uwe Koloska: "Re: bug in socket.h (and maybe many other kernel headerfiles)"
- Previous message: Jeff Garzik: "Re: Turning lucent winmodem into soundcard"