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
