lkml.org 
[lkml]   [1999]   [Aug]   [7]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: ioctl SIOCGIFADDR bug
Hi Rob,

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

My problem turns out to be an apparently undocumented requirement that the
family type must be set in the buffer for SIOCGIFADDR to work (but not for
the mask or broadcast commands to work) and if you don't (i.e. all bytes 0)
it will return the last four bytes of the network card's MAC address but set
this byte (the 18th, at offset 17) to 1 which will cause it to work the
next time.

> Greetings,
> Rob van Nieuwkerk

Bob

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

\
 
 \ /
  Last update: 2005-03-22 13:53    [W:0.054 / U:0.376 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site