1

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.

  • 2
    Yes , you may need to install the driver for that – Ijaz Ahmad Khan Dec 31 '15 at 15:05
  • 3
    What is the output of sudo ifconfig -a? – John Dec 31 '15 at 15:06
  • @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 ... – user86969 Dec 31 '15 at 19:18
  • 1
    @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 2 '16 at 14:25
1

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)
| improve this answer | |
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.

| improve this answer | |
  • Is there a key that allows reliable identification of one NIC vs the other (such as UUID for disks)? – roaima Jan 1 '16 at 0: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 1 '16 at 1:38
  • But if I understand you correctly you're saying udev gets it wrong sometimes..? – roaima Jan 1 '16 at 14:56
  • @roaima the problems I saw were before the new setup – vonbrand Jan 1 '16 at 15:22
  • 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. – user86969 Jan 2 '16 at 16:38

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.