"A month of sundays ago Kurt Roeckx wrote:"
> On Thu, May 25, 2000 at 03:41:04PM +0200, Cougar wrote:
> > What is the reason of removeing alias interface after shutting it down. In
> > 2.0.x (tested with 2.0.38) kernel it was possible to set it up again
> There appear to be 2 problems. ifconfig upto 1.35 (net-tools 1.46) behave
> differently then the newer versions. The old versions will work like
> ifconfig will open alot sockets, for each protocol. The old versions used
> the first opened in the ioctl(), the new the last opened. We have a patch
> for that if you want.
> Then there is the kernel problem. It seems to react differently on the
> socket type the ioctl() was called with, and this shouldn't happen if you
> ask me. The problem is that it downs the whole interface, instead of just
> the alias, atleast in 2.2 and 2.3. You're the first to say that it works
> normal with 2.0, but with what version of ifconfig?
It works normally in 2.0.36 for me too, with the pre-1.35 ifconfigs at
least. To be even a bit more exact than Kurt has been, the situation is
1) In current kernels current ifconfigs accidentally select a socket
of type AF_INET6 on which to execute their ioctl, IF the ipv6 module
is loaded in the kernel. The ioctl then downs the whole interface as
well as the alias, which is a bummer.
2) Without the ipv6 module in the kernel, current ifconfigs
inevitably select an non AF_INET6 family socket on which to work
their evil, and only the alias, not the interface, is downed by the
ioctl call. That's good.
3) In current kernels, old ifconfigs, or current ifconfigs compiled
without ipv6 support, always work correctly. The former because
they acidentally choose a non AF_INET6 socket to try. The latter
because they never try to choose an AF_INET6 socket.
4) In old kernels (pre 2.2.), old ifconfigs work fine. New ifconfigs
probably work fine too.
The current work around I have is to add a test to the ifconfig code
that stops it choosing an AF_INET6 socket if it can avoid it. This will
be in the next test cycle for the net-tools, I understand. Kurt has
another variant that simply reorders the loop traversal that chooses
The correct fix is probably to check out why the same ioctl works
different magic in the kernel, according to whether the socket family
is AF_INET6 or not.
I haven't had time to look, and I am completely unfamiliar with network
code, let alone kernel network code. If anyone knows where to look,
please tell or do.
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to firstname.lastname@example.org
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Wed May 31 2000 - 21:00:14 EST