Re: howto Name eth[0 .. n-1] in kernel 2.4.18 vs earlier kernels?

[Isaac To <kkto@csis.hku.hk>]

>>>>> "Derrick" == Derrick 'dman' Hudson <dman@dman.ddts.net> writes:

    Derrick> *Only* if you didn't specify which is eth0 and eth1.

    Derrick> | My workaround is a module dependency:
    Derrick> | 
    Derrick> | alias eth0 3c59x | alias eth1 8139too

    Derrick> This is sufficient.  (and *don't* put the modules' names in
    Derrick> /etc/modules)

I mean, the lines

  alias eth0 3c59x
  alias eth1 8139too

does not really specify eth0 is 3c59x and eth1 is 8139too.  It specifies
that if the kernel suddenly wants the network interface "eth0" when it were
not there, it will try to load 3c59x, and if it suddenly wants eth1 when it
were not there (even if eth0 was not there either), it will try to load
8139too.  It might seem that they mean the same thing, but they are not the
same.  The first network interface loaded into the module will, by default,
get eth0---no matter whether or not it is loaded by "modprobe eth0" (and no
matter what you write in the "alias" lines above.  There is nothing that
forces 8139too, when loaded, to get eth1 instead of eth0---except that eth0
is *supposed* to be taken by 3c59x already if the setup script is executed
in the order you have *expected*, so *with luck*, it will get eth1.  The
mapping is just by chance and luck, not anything to do with "you have
specified that eth0 correspond to 3c59x"...

This is really broken: e.g., if suddenly your startup script is modified so
that it won't load eth0 (e.g., you want to take down your local network),
the eth1 (8139too) interface is suddenly used before eth0 (3c59x) (which
will never be used actually).  This happens because the interface name
"eth1" is *hardcoded* into all config scripts, e.g., the PPP config files
like /etc/ppp/ppp_on_boot.dsl.  But now the assumption that 3c59x has
already taken eth0 no longer hold, so 8139too will take eth0 (even though
"modprobe eth1" is used to get it!!).  The result is that, after "modprobe
eth1", the eth1 interface is still not there, so the system call fails,
telling you that there is no such interface.  It will persist if you try to
do the same thing when 8139too is already loaded (since reference counts
within the kernel will prevent the module to be loaded again).  If you try
to load 3c59x manually after this, you will get eth1, but it will refer to
the 3c59x card instead of the 8139too card.

If you do not believe all these, try to ifdown every interface you have,
rmmod every network module, make sure that ifconfig shows nothing other than
lo, fire up modprobe eth1, and see whether "ifconfig eth0 up" and "ifconfig
eth1 up" will succeed.

Regards,
Isaac.


-- 
To UNSUBSCRIBE, email to debian-user-request@lists.debian.org 
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org