"A month of sundays ago Peter T. Breuer wrote:"
> "A month of sundays ago Alan Cox wrote:"
> > > [not ac]
> > > Because the this only happens with IPv6, it is an obvious bug. In
> > > addition, about 99.9% of people are using commands like 'ifconfig eth0:5
> > So strace your ifconfig eth0:5 down figure out which ioctl is causing the
> It might be the ifconfig version. The most obvious differences in the
It looks like it. I switched kernels on my machine with a 2.2.10 kernel
exhibiting th ebug downstairs, loaded ipv6 and tried the test (ifconfig
lo:0 127.0.0.2; ifconfig lo:0 down, does lo disappear too?). It worked
fine with my version of ifconfig. net-tools 1.432 ifconfig 1.29
(1997-09-23), linked against libc 5.4.38.
I then took the ifconfig from downstairs and ran it up here. It
exhibited the bug. net-tools 1.54 ifconfig 1.39 (1999-03-18), linked
against glibc 2.1.2.
Does anyone want the full traces? They're really pretty different,
but only about a page long each.
> traces is that downstairs (2.2.10), the ifconfig does a whole lot of
> rooting around in proc:
>
> access("/proc/net", R_OK) = 0
> access("/proc/net/unix", R_OK) = 0
> socket(PF_UNIX, SOCK_DGRAM, 0) = 3
> socket(PF_INET, SOCK_DGRAM, IPPROTO_IP) = 4
> access("/proc/net/if_inet6", R_OK) = 0
> socket(PF_INET6, SOCK_DGRAM, 0) = 5
> access("/proc/net/ax25", R_OK) = -1 ENOENT (No such file or directory)
>
> None of that upstairs here (2.2.15). Downstairs (2.2.10), the final
> ioctl is:
>
> ioctl(5, SIOCGIFFLAGS, 0xbffff5ec) = 0
> ioctl(5, SIOCSIFFLAGS, 0xbffff5ec) = 0
>
> and upstairs (2.2.15) it is:
>
> ioctl(3, SIOCGIFFLAGS, 0xbfffee60) = 0
> ioctl(3, SIOCSIFFLAGS, 0xbfffee60) = 0
>
> Downstairs (2.2.10), 5 is a socket:
>
> access("/proc/net/if_inet6", R_OK) = 0
> socket(PF_INET6, SOCK_DGRAM, 0) = 5
>
> and upstairs (2.2.15), 3 is a slightly different socket:
>
> socket(PF_INET, SOCK_DGRAM, IPPROTO_IP) = 3
>
Peter
-
To unsubscribe from this list: send the line "unsubscribe linux-net" in
the body of a message to [EMAIL PROTECTED]
