1

I'm experiencing some strange behaviour with a Dual Gigabit Ethernet NIC; I've setup a computer which has multiple network interfaces to connect some industrial cameras and setup a DHCP Server (isc-dhcp-server, Ubuntu 16.04) to statically assign their IPs. Note: There is no router/switch in the setup. Just NICs and direct connections via RJ45-cable.

This works for the other NICs on the computer. I see a DHCP DISCOVERY packet coming in, then a DHCP OFFER is sent to the remote device and is later on acknoledged via DHCP ACK from the remote device.

But, for this special NIC (LogiLink 2-Port Gigabit LAN PCI-Express, PC0075 v.2.0; Chipset: RTL8111F; see datasheet) I just see multiple DHCP DISCOVERY packets coming in which are replied with a DHCP OFFER on the DHCP server side. It looks like the remote device is not receiving the DHCP OFFER. In fact I tried using a Windows machine as a client, where I did not see any DHCP OFFER reply from the server (no packets at all from the DHCP server if I did not overlook any, since the windows machine was just sending a lot if crap out).

Now the strange thing: I kept everything as it was (DHCP Server having a static IP of 192.168.1.1/24) and configured the windows client to use a fixed IP (192.168.1.2/24). Now sending a ping from the windows client to the DHCP server works (ping reply is received successfully) as long as the cable is connected. Thus, the NIC at the DHCP server is able to send out packets and the cable/connection is not the issue and the Windows client does actually communicate via this connection. I switched between static IP and DHCP config at the client multiple times to validate this (DHCP=not working, static IP=everything fine).

Some diagnostics (Note: I changed the public IP address to 42.x.x.x and for MAC adresses the last 4 hex digits were changed):

   $ lspci -k | grep 'RTL' -A2
   06:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller (rev 07)
           Subsystem: Realtek Semiconductor Co., Ltd. RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller
           Kernel driver in use: r8168
           Kernel modules: r8169, r8168
   07:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller (rev 07)
           Subsystem: Realtek Semiconductor Co., Ltd. RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller
           Kernel driver in use: r8168
           Kernel modules: r8169, r8168

   #### NOTE: This was when the Windows Client was connected to eth3, eth1/eth2 disconnected; the "RUNNING" shows up properly for eth1/eth2 as soon  the cable is connected ####
   $ ifconfig
   eth0      Link encap:Ethernet  HWaddr 10:7b:44:a5:ff:42
             inet addr:42.0.0.1  Bcast:42.0.0.255  Mask:255.255.255.0
             inet6 addr: fe80::127b:44ff:fea5:ff42/64 Scope:Link
             UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
             RX packets:44357 errors:0 dropped:2143 overruns:0 frame:0
             TX packets:590 errors:0 dropped:0 overruns:0 carrier:0
             collisions:0 txqueuelen:1000
             RX bytes:5653188 (5.6 MB)  TX bytes:94249 (94.2 KB)
             Interrupt:20 Memory:92f00000-92f20000

   eth1      Link encap:Ethernet  HWaddr 00:13:3b:0f:ff:f1
             inet addr:192.168.1.1  Bcast:192.168.1.255  Mask:255.255.255.0
             inet6 addr: fe80::213:3bff:fe0f:fff1/64 Scope:Link
             UP BROADCAST MULTICAST  MTU:1500  Metric:1
             RX packets:191 errors:0 dropped:0 overruns:0 frame:0
             TX packets:34 errors:0 dropped:46 overruns:0 carrier:0
             collisions:0 txqueuelen:1000
             RX bytes:20166 (20.1 KB)  TX bytes:2400 (2.4 KB)
             Interrupt:45 Base address:0x2000

   eth2      Link encap:Ethernet  HWaddr 00:13:3b:0f:ff:f2
             inet addr:192.168.2.1  Bcast:192.168.2.255  Mask:255.255.255.0
             inet6 addr: fe80::213:3bff:fe0f:fff2/64 Scope:Link
             UP BROADCAST MULTICAST  MTU:1500  Metric:1
             RX packets:1388 errors:0 dropped:0 overruns:0 frame:0
             TX packets:140 errors:0 dropped:68 overruns:0 carrier:0
             collisions:0 txqueuelen:1000
             RX bytes:155296 (155.2 KB)  TX bytes:10878 (10.8 KB)
             Interrupt:46 Base address:0x8000

   eth3      Link encap:Ethernet  HWaddr 00:e0:4c:13:ff:f3
             inet addr:192.168.3.1  Bcast:192.168.3.255  Mask:255.255.255.0
             inet6 addr: fe80::2e0:4cff:fe13:fff3/64 Scope:Link
             UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
             RX packets:357 errors:0 dropped:0 overruns:0 frame:0
             TX packets:72 errors:0 dropped:0 overruns:0 carrier:0
             collisions:0 txqueuelen:1000
             RX bytes:49440 (49.4 KB)  TX bytes:9345 (9.3 KB)

   lo        Link encap:Local Loopback
             inet addr:127.0.0.1  Mask:255.0.0.0
             inet6 addr: ::1/128 Scope:Host
             UP LOOPBACK RUNNING  MTU:65536  Metric:1
             RX packets:36 errors:0 dropped:0 overruns:0 frame:0
             TX packets:36 errors:0 dropped:0 overruns:0 carrier:0
             collisions:0 txqueuelen:1
             RX bytes:2671 (2.6 KB)  TX bytes:2671 (2.6 KB)

   $ cat /etc/dhcp/dhcpd.conf
   default-lease-time 600;
   max-lease-time 7200;
   log-facility local0;
   authorative;

   subnet 192.168.1.0 netmask 255.255.255.0 {
     range 192.168.1.2 192.168.1.254;
   }
   subnet 192.168.2.0 netmask 255.255.255.0 {
     range 192.168.2.2 192.168.2.254;
   }
   subnet 192.168.3.0 netmask 255.255.255.0 {
     range 192.168.3.2 192.168.3.254;
   }
   subnet 192.168.4.0 netmask 255.255.255.0 {
     range 192.168.4.2 192.168.4.254;
   }

   host cam1 {
           hardware ethernet 00:01:0d:c2:ff:01;
           fixed-address 192.168.1.2;
   }

   host cam2 {
           hardware ethernet 00:01:0d:c2:ff:02;
           fixed-address 192.168.2.2;
   }


   host cam3 {
           hardware ethernet 00:01:0d:c2:ff:03;
           fixed-address 192.168.3.2;
   }


   host cam4 {
           hardware ethernet 00:01:0d:c2:ff:04;
           fixed-address 192.168.4.2;
   }

   host notebook {
           hardware ethernet 80:fa:5b:4b:ff:05;
           fixed-address 192.168.1.2;
   }

What I've tried so far:

  • I tried to replace the cable and to use both of the ports, without a change.
  • I tried to use the built-in kernel drivers (Ubuntu 16.04, Kernel 4.4.0-124-generic AND the driver from RealTek (r8168-8.045.08), which the NIC is currently using according to "lspci -k"
  • I tried to configure the NIC to use 10-MBit/s Half-Duplex, which had no influence.

QUESTIONS:

  • Why doesn't the DHCP OFFER show up at the Client for this NIC (eth1/eth2), while it worked fine with eth3 (different adapter, other using a RTL81524-2 chipset)?
  • How to fix it?
  • Any suggestions what I can try? (except for setting up static IP addresses at the clients)

EDIT:

I configured the client devices (cameras) on that NIC using static IPs. This seems to work if I manually disconnect/reconnect the cable with some delay. For any reason the connection doesn't come up properly in an automated fashion after a shutdown. Also I experienced some "no buffer space available" messages when actually using other NICs, while there was near to no load (just some pings with 1s interval). I reverted to the kernels integrated driver - so far I didn't see "no bufferspace" messages; but the connection still doesn't come up automatically. I wonder if this might be a defective network adapter... and a driver that does not handle the caused issues correctly.

EDIT #2:

Seems that I can use "mii-tool -r eth1" and "mii-tool -r eth2" to force a renegotiation of the link, instead of disconneting/reconnecting the cables. This only works with static IP configured (DHCP still fails). Also note that "mii-tool" claims the devices negotiated a "1000baseT-HD" (half duplex) link, ethtool tells me it's full duplex. The status shown before and after the "mii-tool -r" commands are the same for mii-tool and ethtool:

   # mii-tool
   SIOCGMIIREG on eth0 failed: Input/output error
   SIOCGMIIREG on eth0 failed: Input/output error
   eth0: negotiated 1000baseT-FD flow-control, link ok
   eth1: negotiated 1000baseT-HD flow-control, link ok
   eth2: negotiated 1000baseT-HD flow-control, link ok
   eth3: negotiated 1000baseT-FD flow-control, link ok
   SIOCGMIIPHY on 'eth4' failed: Operation not supported

   # ethtool eth1
   Settings for eth1:
           Supported ports: [ TP MII ]
           Supported link modes:   10baseT/Half 10baseT/Full
                                   100baseT/Half 100baseT/Full
                                   1000baseT/Half 1000baseT/Full
           Supported pause frame use: No
           Supports auto-negotiation: Yes
           Advertised link modes:  10baseT/Half 10baseT/Full
                                   100baseT/Half 100baseT/Full
                                   1000baseT/Half 1000baseT/Full
           Advertised pause frame use: Symmetric Receive-only
           Advertised auto-negotiation: Yes
           Link partner advertised link modes:  10baseT/Half 10baseT/Full
                                                100baseT/Half 100baseT/Full
                                                1000baseT/Half 1000baseT/Full
           Link partner advertised pause frame use: Symmetric Receive-only
           Link partner advertised auto-negotiation: Yes
           Speed: 1000Mb/s
           Duplex: Full
           Port: MII
           PHYAD: 0
           Transceiver: internal
           Auto-negotiation: on
           Supports Wake-on: pumbg
           Wake-on: g
           Current message level: 0x00000033 (51)
                                  drv probe ifdown ifup
           Link detected: yes


   # ethtool eth2        
   Settings for eth2:
           Supported ports: [ TP MII ]
           Supported link modes:   10baseT/Half 10baseT/Full
                                   100baseT/Half 100baseT/Full
                                   1000baseT/Half 1000baseT/Full
           Supported pause frame use: No
           Supports auto-negotiation: Yes
           Advertised link modes:  10baseT/Half 10baseT/Full
                                   100baseT/Half 100baseT/Full
                                   1000baseT/Half 1000baseT/Full
           Advertised pause frame use: Symmetric Receive-only
           Advertised auto-negotiation: Yes
           Link partner advertised link modes:  10baseT/Half 10baseT/Full
                                                100baseT/Half 100baseT/Full
                                                1000baseT/Half 1000baseT/Full
           Link partner advertised pause frame use: Symmetric Receive-only
           Link partner advertised auto-negotiation: Yes
           Speed: 1000Mb/s
           Duplex: Full
           Port: MII
           PHYAD: 0
           Transceiver: internal
           Auto-negotiation: on
           Supports Wake-on: pumbg
           Wake-on: g
           Current message level: 0x00000033 (51)
                                  drv probe ifdown ifup
           Link detected: yes
  • On the client side can you run a wireshark please to make sure the DHCP OFFER is not seen but discarded by the OS. From your output, I just don't like the dropped count on TX frame for eth1&eth2, but I'am not expert on Linux, more for Windows, thus maybe someone else could answer why the dropped counter can be hight – yagmoth555 May 16 '18 at 12:28
  • Also, mirror the switch port. Had such an effect months ago, rebootet switch, everything came back to work. Wired. – bjoster May 16 '18 at 13:13
  • @yagamoth555: The dropped count could be either due to wrong checksum. I used a Windows VM on the DHCP server to setup the cameras and saw wireshark complaining about some FRAMEs sent via the VM having a bad CRC. Also it might be because I used CATe5 cables (7 Meters, shielded) for some connections instead of CAT6, which should be used for 1000-Base-T, thought. – SDwarfs May 16 '18 at 13:50
  • @bjoster: I don't use any switches. Just NIC (Server, 192.168.1.1/24) <<=>> patch cable <<=>> NIC (Client, 192.168.1.2/24). In case you speak about the "Asmedia 1182E" switch integrated on the NIC.... How to configure it? – SDwarfs May 16 '18 at 13:54
  • On Ubuntu Bionic Beaver I have a Realtek Ethernet controller RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller and see something similar. dhclient never receives any DHCP offers. Happening in Windows 10 as well. Plugged in different ethernet adapter (USB adapter) and that works fine. Did you find a solution? – Colin Sep 25 '18 at 18:20

Your Answer

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

Browse other questions tagged or ask your own question.