My ethernet card does not create any `ethX` device. How can I solve it?

Question

I am testing a new network card on Ubuntu Linux Desktop v14.04.3 LTS 64 bits. Its name is:

Silicom PXG6BPi Six Port Copper Gigabit Ethernet PCI-X Bypass Server Adapter

But it seems to be a discontinued device, and it generates no ethX at all:

luis@ThreepWood:~$ sudo ifconfig -a
eth0      Link encap:Ethernet  direcciónHW 00:1d:60:13:df:cb
          Direc. inet:192.168.11.110  Difus.:192.168.11.255  Másc:255.255.255.0
          Dirección inet6: fe80::21d:60ff:fe13:dfcb/64 Alcance:Enlace
          ACTIVO DIFUSIÓN FUNCIONANDO MULTICAST  MTU:1500  Métrica:1
          Paquetes RX:578 errores:0 perdidos:0 overruns:0 frame:0
          Paquetes TX:596 errores:0 perdidos:0 overruns:0 carrier:2
          colisiones:0 long.colaTX:1000
          Bytes RX:55654 (55.6 KB)  TX bytes:89718 (89.7 KB)

lo        Link encap:Bucle local
          Direc. inet:127.0.0.1  Másc:255.0.0.0
          Dirección inet6: ::1/128 Alcance:Anfitrión
          ACTIVO BUCLE FUNCIONANDO  MTU:16436  Métrica:1
          Paquetes RX:204 errores:0 perdidos:0 overruns:0 frame:0
          Paquetes TX:204 errores:0 perdidos:0 overruns:0 carrier:0
          colisiones:0 long.colaTX:0
          Bytes RX:16592 (16.5 KB)  TX bytes:16592 (16.5 KB)

As can be seen, the only NIC detected is the internal one (eth0).
I have tested some others multiple ethernet cards, like some 4-port ones, and they are seen by the operating system as 4 NIC, i.e: eth4, eth5, eth6 and eth7.

The device seems to be at the PCI list:

luis@ThreepWood:~$ sudo lspci | grep "copper" -i
05:04.0 Ethernet controller: Silicom Ltd. Silicom 6 port Copper Giga Ethernet 546 Bypass Server Adapter (PXG6BPI) (rev 03)
05:04.1 Ethernet controller: Silicom Ltd. Silicom 6 port Copper Giga Ethernet 546 Bypass Server Adapter (PXG6BPI) (rev 03)
05:05.0 Ethernet controller: Silicom Ltd. Silicom 6 port Copper Giga Ethernet 546 Bypass Server Adapter (PXG6BPI) (rev 03)
05:05.1 Ethernet controller: Silicom Ltd. Silicom 6 port Copper Giga Ethernet 546 Bypass Server Adapter (PXG6BPI) (rev 03)
05:06.0 Ethernet controller: Silicom Ltd. Silicom 6 port Copper Giga Ethernet 546 Bypass Server Adapter (PXG6BPI) (rev 03)
05:06.1 Ethernet controller: Silicom Ltd. Silicom 6 port Copper Giga Ethernet 546 Bypass Server Adapter (PXG6BPI) (rev 03)

I am rather used to find that Linux detects nearly all network cards automatically.

How can I solve this?
Do I need to install drivers? Or maybe it is just a question of kernel recompilation? Maybe it is just a matter of loading some modules?

It seems the reseller does not offer an easy access to its drivers.

@John, ifconfig -a yields just the same output. I have edited the original question to reflect. — Sopalajo de Arrierez, Dec 31 '15 at 18:29
Here is the only trace of a driver I found. This driver patch dates 2012 and targets the 2.6 kernel line so it's a little weird your installation doesn't support it. Have you checked with a RedHat-derived distro like CentOS orFedora? Anyway the supported chipset is a Broadcom BCM5700 by the looks of it. Try modprobe tg3 for now. Maybe the driver is just blacklisted ... — , Dec 31 '15 at 19:18
@Nasha: why could a network driver be blacklisted? Unstability, maybe? modprobe tg3 shows no output, and ifconfig -a still shows no more ethX interfaces. — Sopalajo de Arrierez, Dec 31 '15 at 19:59
Instability, right but also negative interaction with hardware or other drivers... From what I've observed there's always one Broadcom driver (bcm43 or bcm44 IIRC) that attends the blacklist under Ubuntu. But I admit I never investigated why. That's for one thing. I suggested testing a RH derived distro because I know by experience RedHat has an excellent server hardware support. Obsolete hardware should hence be best supported. Well, as long as it was stable in the first place, of course. Using a Desktop distribution might be one reason your hardware is blacklisted... — , Dec 31 '15 at 20:02
I only have limited faith in Ubuntu on a server. Or: I trust RedHat much more than Canonical. Not a reason to rip it off your machine, of course. Just try a live CD or DVD from CentOS. — , Dec 31 '15 at 20:32
@Nasha, latest CentOS offers the same results: ifconfig -a yields only the main (internal) card and the loopback adapters. Thanks anyway, as I have solved it by installing/compiling drivers. — Sopalajo de Arrierez, Jan 02 '16 at 14:25

score 1 · Answer 1 · answered Jan 01 '16 at 02:36

As long as the PCI card is detected, and the ethX interfaces do not show, the probable solution would be to install the driver.
This is the procedure for the PXG6BPi card (extracted from its official docs):

1.- Install the compilation tools:

# apt-get update
# apt-get install make gcc

2.- Download official drivers (login data are drivers/all according to the reseller email response).

3.- The more recent driver as for today (December 2015) is /Intel_e1000BPx/Kernel_31x/e1000bp-7.3.21-k8.silc.6.1.tar.gz, so :

$ tar e1000bp-7.3.21-k8.silc.6.1.tar.gz
$ cd e1000bp-7.3.21-k8.silc.6.1

4.- Compile and install:

# make install

5.- Load the driver to start it:

# modprobe e1000bp

or (to disable the bypass card special feature):

# modprobe e1000bp BPoff=1,1,1,1,1,1

6.- Check the results:

ifconfig -a
# ifconfig eth1 up

Note that, with this device, you will get 6 ethX NICs.

For my particular case:

luis@Threepwood:~$ sudo ifconfig -a
eth0      Link encap:Ethernet  direcciónHW 00:1d:60:13:df:cb
          Direc. inet:192.168.11.110  Difus.:192.168.11.255  Másc:255.255.255.0
          Dirección inet6: fe80::21d:60ff:fe13:dfcb/64 Alcance:Enlace
          ACTIVO DIFUSIÓN FUNCIONANDO MULTICAST  MTU:1500  Métrica:1
          Paquetes RX:27599 errores:0 perdidos:0 overruns:0 frame:0
          Paquetes TX:17635 errores:0 perdidos:0 overruns:0 carrier:2
          colisiones:0 long.colaTX:1000
          Bytes RX:27301761 (27.3 MB)  TX bytes:1882457 (1.8 MB)

eth1      Link encap:Ethernet  direcciónHW 00:e0:ed:14:84:fe
          DIFUSIÓN MULTICAST  MTU:1500  Métrica:1
          Paquetes RX:0 errores:0 perdidos:0 overruns:0 frame:0
          Paquetes TX:0 errores:0 perdidos:0 overruns:0 carrier:0
          colisiones:0 long.colaTX:1000
          Bytes RX:0 (0.0 B)  TX bytes:0 (0.0 B)

eth2      Link encap:Ethernet  direcciónHW 00:e0:ed:14:84:ff
          DIFUSIÓN MULTICAST  MTU:1500  Métrica:1
          Paquetes RX:0 errores:0 perdidos:0 overruns:0 frame:0
          Paquetes TX:0 errores:0 perdidos:0 overruns:0 carrier:0
          colisiones:0 long.colaTX:1000
          Bytes RX:0 (0.0 B)  TX bytes:0 (0.0 B)

eth3      Link encap:Ethernet  direcciónHW 00:e0:ed:14:85:00
          DIFUSIÓN MULTICAST  MTU:1500  Métrica:1
          Paquetes RX:0 errores:0 perdidos:0 overruns:0 frame:0
          Paquetes TX:0 errores:0 perdidos:0 overruns:0 carrier:0
          colisiones:0 long.colaTX:1000
          Bytes RX:0 (0.0 B)  TX bytes:0 (0.0 B)

eth4      Link encap:Ethernet  direcciónHW 00:e0:ed:14:85:01
          DIFUSIÓN MULTICAST  MTU:1500  Métrica:1
          Paquetes RX:0 errores:0 perdidos:0 overruns:0 frame:0
          Paquetes TX:0 errores:0 perdidos:0 overruns:0 carrier:0
          colisiones:0 long.colaTX:1000
          Bytes RX:0 (0.0 B)  TX bytes:0 (0.0 B)

eth5      Link encap:Ethernet  direcciónHW 00:e0:ed:14:85:02
          Dirección inet6: fe80::2e0:edff:fe14:8502/64 Alcance:Enlace
          ACTIVO DIFUSIÓN FUNCIONANDO MULTICAST  MTU:1500  Métrica:1
          Paquetes RX:1018 errores:0 perdidos:0 overruns:0 frame:0
          Paquetes TX:262 errores:0 perdidos:0 overruns:0 carrier:0
          colisiones:0 long.colaTX:1000
          Bytes RX:111838 (111.8 KB)  TX bytes:15888 (15.8 KB)

eth6      Link encap:Ethernet  direcciónHW 00:e0:ed:14:85:03
          DIFUSIÓN MULTICAST  MTU:1500  Métrica:1
          Paquetes RX:0 errores:0 perdidos:0 overruns:0 frame:0
          Paquetes TX:0 errores:0 perdidos:0 overruns:0 carrier:0
          colisiones:0 long.colaTX:1000
          Bytes RX:0 (0.0 B)  TX bytes:0 (0.0 B)

lo        Link encap:Bucle local
          Direc. inet:127.0.0.1  Másc:255.0.0.0
          Dirección inet6: ::1/128 Alcance:Anfitrión
          ACTIVO BUCLE FUNCIONANDO  MTU:65536  Métrica:1
          Paquetes RX:0 errores:0 perdidos:0 overruns:0 frame:0
          Paquetes TX:0 errores:0 perdidos:0 overruns:0 carrier:0
          colisiones:0 long.colaTX:0
          Bytes RX:0 (0.0 B)  TX bytes:0 (0.0 B)

score 0 · Answer 2 · answered Dec 31 '15 at 22:58

0

Modern setups (at least on Fedora and it's ilk) don't call network interfaces ethN anymore, as this enumerated interfaces in the (semi-random!) order in which they came up. Yes, I got bitten by this on a machine with two ethernet cards on board. When doing some operations, like updating the kernel, and occasionally just by rebooting, the names of the interfaces got switched around, requiring a trip to the machine to reconfigure networking. Not nice.

Current names are keyed off the physical connection in the machine, i.e. my eno1 is the first Ethernet device. Ask ip(1) (by typing e.g. ip link list) for the current names of your network devices.

answered Dec 31 '15 at 22:58

vonbrand

18,253

Is there a key that allows reliable identification of one NIC vs the other (such as UUID for disks)? – Chris Davies Jan 01 '16 at 00:20
@roaima, that is done by udev(1), groping out topology information off the kernel and mangling it under control of it's configuration files. – vonbrand Jan 01 '16 at 01:38
But if I understand you correctly you're saying udev gets it wrong sometimes..? – Chris Davies Jan 01 '16 at 14:56
@roaima the problems I saw were before the new setup – vonbrand Jan 01 '16 at 15:22
Oh OK. I've found udev to be very reliable myself. I've not used it much on systemd installs though. – Chris Davies Jan 01 '16 at 16:27
1

@roaima The naming convention ethX is the one considered non-reliable (at least) by udev developers: a given network adapter was not guaranteed to always be given the same name on a given machine. The shift towards something like enXY was motivated to have network adapters that are deterministically and consistently named based on device type, bus, slot, [...] information. For short: UDEV current naming convention makes NIC identification reliably and deterministically predictable. – Jan 02 '16 at 16:38

My ethernet card does not create any `ethX` device. How can I solve it?

2 Answers2

Linked