Re: ioctl SIOCGIFADDR bug

Rob van Nieuwkerk (robn@verdi.et.tudelft.nl)
Fri, 06 Aug 1999 20:55:37 +0200


Hi Bob,

> I have observed a possible bug in the kernel (or device drivers) when using
> ioctl with the SIOCGIFADDR command to get the address of one's network
> interface, typically "eth0".
>
> The bug is that the ioctl() must be called twice as the first time it
^^^^^^^^^^^^^^^^^^^^
> returns garbage. The other SSIOCGIF* commands (such as NETMASK and BROADCAST)
> do not suffer from this even though their code paths in the kernel are in
> common. The ifconfig program seems to not suffer from this problem because
> it invokes the ioctl() with other SIOCGIF* commands prior to invoking the
> SIOCGIFADDR command.

Maybe this could be related to a problem I reported twice on the
linux kernel list. See below. I never got a any reaction ..

Greetings,
Rob van Nieuwkerk

----------------------------------------------------------------
Date: Tue, 6 Apr 1999 13:19:42 +0200 (CEST)

Hi,

This is basically a repost from a bug-report I sent to linux-net 2 weeks
ago. I did not receive any reaction and the problem still remains
(did several kernel upgrades since then).

I have a problem with one of my routers not configuring eth0 after a reboot
since I've switched to Linux 2.2.* (from 2.0.36). The system is now
running Linux 2.2.5-ac4.

Debugging the network config scripts showed that it was this problem:

+ ifconfig eth0 130.161.38.165 netmask 255.255.240.0 broadcast 130.161.47.255
SIOCSIFFLAGS: Resource temporarily unavailable
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

My "solution" is to do *exactly the same* ifconfig command after the first
one fails. Then it succeeds ! Sometimes the first one *is* successful.

I have another router with the same setup that does never have this problem.

So it seems that there is some kind of timing problem that makes
the SIOCSIFFLAGS control fail temporarily.

Is this a known problem ?

A friend suggested that it might have something to do with the Ethernet
driver (3c503). For example probing/registering the interrupt line or
something like that. Sounds unlikely to me.

My setup:
---------
- standard Red Hat 5.2 (completely up-to-date, with all 2.2 updates
from Red Hat)
- Cyrix DX2 66, 16 MB RAM
- 3c503 Ethernet card
- 2 PPP lines (but the problem shows *before* PPP is started !)
- 2.2.5-ac4 kernel built with gcc-2.7.2.3 (on RH 5.2, 2.2.5-ac2)
- all drivers built into the kernel: no modules or kerneld !
- system has always functioned flawlessly with Linux 2.0.x

Red Hat details:
----------------
I have added an extra "./ifup eth0 boot" to /etc/rc.d/init.d/network in
the "start)" section just before the "touch /var/lock/subsys/network"
This results in exactly the same ifconfig command as the one that
just failed.
----------------------------------------------------------------

-
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/