Hello everybody,

Maybe (most likely) somebody has a solution for a problem that's bugging me
now for several days and for which I somehow can't find a solution.

One of the computers I maintain (using Debian) has three network interface
cards (NICs). In the past I used a self-compiled kernel specifying the
required drivers in the configuration file and defining which NIC should be
associated with what interface using a lilo append specification like this:

append="ether=7,0x300,eth0 ether=5,0x310,eth1 ether=10,0xfc00,eth2"

That works fine, but not with a modular kernel. When installing Debian's
linux-kernel one of the first things I noted was that the 3c509 module that I
needed wasn't loaded when I booted the computer using that kernel. I added
3c509 to /etc/modules which *did* load that module.

First question: what do I do to make sure that 3c509 is loaded into the
kernel automatically, like the module I need for one of the other NICs (which
is 8139too required for a RealTek RTL8139 NIC.

The next thing I noted that after adding 3c509 only one of the two NICs
requiring that module was listed in, e.g., dmesg (So, two NICs use 3c509, one
NIC uses 8139too, the latter and only one NIC requiring 3c509 is now
recognized.

Second question: why aren't both NICs requiring 3c509 recognized? What do
I do to make sure that all three are recognized?

Finally it is important to associate a NIC with a specific
interface. Previously I could do that with lilo's append statement, but how do
I do that with a modular kernel? Following an advice I got from a colleague of
mine I specified interfaces and NIC-MAC addresses in
/etc/udev/rules.d/70-persistent-net.rules like this:

SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="00:20:af:0b:48:be", ATTR{type}=="1", KERNEL=="eth*", NAME="eth0"
SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="00:60:8c:c1:c3:d5", ATTR{type}=="1", KERNEL=="eth*", NAME="eth1"
SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="00:50:fc:a4:c2:c3", ATTR{type}=="1", KERNEL=="eth*", NAME="eth2"

and rebooted the kernel. Unfortunately it had no noticeable effect.

Third question: what do I do to make sure that a specific interface will
be associated with a specific network interface?

That's all. Any reply or suggestion or answer will be highly
appreciated. If any more information is required, please let me know.

Cheers,

Frank.

Hi,

And welcome to LQ!

Did you come across this one?


Cheers,
Tink

What version of Debian are you using. Both of my Etch machines use /etc/udev/rules.d/z25_persistent-net.rules

To jstephens84: Thanks for your reply to my posting. If I remember correctly the z* rules are indeed used with etch, but lenny changed that into rules starting with a numeric prefix. But it's quite possible that both are still in use. Anyway, I'm using lenny and the computer we're talking about only has rules starting with a number.

And to Tinkster: thanks too, of course. No I didn't see that one until now, but I did read
http://www.reactivated.net/writing_udev_rules.html, from which I got the syntax for the rules I've tried so far. After quickly browsing through the uri you suggested I got the impression that it describes more or less the same syntax. But I'll have to read it more thoroughly.

Somehow, however, I think the answers to my questions shouldn't be difficult or complex. Only hard to find. Or easy to miss? I've googled for things like `Associating NICs and network interface names', `multiple ethernet cards' etc. etc. but nothing useful turned up. Weird.

Yes you would change where it says name="ethX" you could change that to say eth-intel and then you would need to change your interfaces file for the update you made. That should get what you are looking for. Unless I really misunderstood what you are looking for.

Also as far as making the module load at boot time you just need to add the necessary information into the modules file.

### Sorry forgot to add how to ###
edit the /etc/modules file and add the following but Change X to your eth number

Hi jstephens84,

Thanks for the clarifications. So, if I understand you well I define three aliases, with two using the same module? E.g.,
alias eth0 3c509
alias eth1 3c509
alias eth2 8139too

and then use the udev rule to disambiguate which NIC goes with eth0 and which one with eth1?

I'll try that (my) tomorrow. It's getting too late over here to try it out right now. I'll be back with my findings.
Thanks again.

Frank.

You may have to change your modules also so that it matches the udev file as well as the interfaces file.

Well I think I followed your advice (but the problem persists). Here's what I did:

/etc/modules now contains:

alias eth0 3c509
alias eth1 3c509
alias eth2 8139too

The udev 70-persistent-net rules is as shown before, matching MAC addresses to interface names

From kern.log I get the impression that all interfaces are properly recognized:

[ 11.979810] eth0: RealTek RTL8139 at 0xfc00, 00:50:fc:a4:c2:c3, IRQ 11
[ 11.983845] eth0: Identified 8139 chip type 'RTL-8100B/8139D'
[ 12.101114] udev: renamed network interface eth0 to eth2

(so that's eth2, matching the udev rule)

and then:

[ 47.818913] eth0: 3c5x9 found at 0x300, BNC port, address 00:20:af:0b:48:be, IRQ 7.
[ 47.861847] eth1: 3c5x9 found at 0x310, BNC port, address 00:60:8c:c1:c3:d5, IRQ 5.

(again: interfaces matching the udev rule specs)

But following the reboot only eth2 is actually up, and the 3com cards are not accessible.


Kern.log also reports:

Dec 11 14:23:40 styx kernel: [ 50.881919] eth2: link up, 10Mbps, half-duplex, lpa 0x0000

but it doesn't show a comparable message for the other two interfaces. Is that strange or irrelevant? The /etc/network/interfaces file hasn't been changed and (still) shows the interface/MAC associations also found in the udev rule file. I know that specifying interface/MAC associations in the network/interfaces file is deprecated, but that's all I need to do when booting the non-modular kernel. E.g., it contains

auto eth0
iface eth0 inet static
address 192.168.17.17
netmask 255.255.255.0
broadcast 192.168.17.255
hwaddress ether 00:20:af:0b:48:be

and comparable blocks for eth1 and eth2.

Just in case it's of any use: following the reboot to the modular kernel the routing table does show the interfaces.

I'm afraid I'm still clueless as to what's happening here: the NICs seem to be recognized by the kernel, eth2 comes up, but eth0 and eth1 apparently not. What's puzzling too is that all's well with the non-modular kernel and nothing was changed (except for using the modular kernel of course). Somehow I still think there's a minor point I'm missing but then: a needle in a haystack is also a `minor point' (pun?)

The problem has been solved. And the problem was indeed caused by an `external' factor. The computer is kind of old and still uses some ISA slots. It turned out that the parallel port and one of the 3com cards used the same IRQ resulting in a conflict making the interface associated with that card inaccessible. In the previously used non-modular kernel I had not added the parallel port driver so there the conflict never appeared. When browsing once again through the dmesg file I suddenly realized that there two identical IRQs were mentioned.

So I've put parport_pc as well as parport in /etc/modprobe.conf/blacklist. If I understand it correctly then that will prevent these modules from being loaded at the next kernel installation. It has no noticeable effect on the current kernel so I've defined the file /etc/network/if-pre-up.d/eth0 containing:

#!/bin/sh

if /bin/grep parport_pc /proc/modules > /dev/null ; then
/sbin/rmmod parport_pc
/sbin/rmmod parport
fi

Now, just before configuring eth0 the two offending modules are removed from the kernel and eth0 is
cleanly configured.

Jstephens84 and Tinkster: thanks again for your supportive posts!

Frank.

Glad that it worked out for you.