Estou tendo um comportamento estranho com uma NIC Gigabit Ethernet de duas portas; Eu configurei um computador que tem várias interfaces de rede para conectar algumas câmeras industriais e configurar um servidor DHCP (isc-dhcp-server, Ubuntu 16.04) para atribuir estaticamente seus IPs. Nota: Não há roteador / switch na configuração. Apenas NICs e conexões diretas via cabo RJ45.
Isso funciona para as outras NICs no computador. Eu vejo um pacote DHCP DISCOVERY chegando, então uma DHCP OFFER é enviada para o dispositivo remoto e é posteriormente acessada via DHCP ACK do dispositivo remoto.
Mas, para este NIC especial (LogiLink 2 Portas Gigabit LAN PCI-Express, PC0075 v.2.0; Chipset: RTL8111F; consulte folha de dados ) Acabei de ver vários pacotes DHCP DISCOVERY chegando, que são respondidos com uma DHCP OFFER no lado do servidor DHCP. Parece que o dispositivo remoto não está recebendo a DHCP OFFER . Na verdade, tentei usar uma máquina Windows como cliente, em que não vi nenhuma resposta DHCP OFFER do servidor (nenhum pacote do servidor DHCP se não ignorei nenhum, já que as janelas máquina estava apenas enviando muito se crap fora).
Agora a coisa estranha: eu mantive tudo como estava (DHCP Server tendo um IP estático de 192.168.1.1/24) e configurei o windows client para usar um IP fixo (192.168.1.2/ 24). Agora, enviar um ping do cliente do Windows para o servidor DHCP funciona (a resposta do ping é recebida com êxito), desde que o cabo esteja conectado. Assim, a NIC no servidor DHCP pode enviar pacotes e o cabo / conexão não é o problema e o cliente do Windows realmente se comunica através desta conexão. Eu mudei entre IP estático e DHCP no cliente várias vezes para validar isso (DHCP = não funciona, IP estático = tudo bem).
Alguns diagnósticos (Nota: eu alterei o endereço IP público para 42.x.x.xe para endereços MAC os últimos 4 dígitos hexadecimais foram alterados):
$ 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;
}
O que eu tentei até agora:
PERGUNTAS:
EDITAR:
Eu configurei os dispositivos do cliente (câmeras) nessa NIC usando IPs estáticos. Isso parece funcionar se eu desconectar / reconectar manualmente o cabo com algum atraso. Por qualquer motivo, a conexão não é feita de maneira automática após um desligamento. Também experimentei algumas mensagens "sem espaço disponível no buffer" ao usar outros NICs, enquanto não havia carga (apenas alguns pings com intervalo de 1s). Eu reverti para o driver integrado dos kernels - até agora não vi mensagens "no bufferspace"; mas a conexão ainda não aparece automaticamente. Gostaria de saber se isso pode ser um adaptador de rede com defeito ... e um driver que não lida corretamente com os problemas causados.
EDIT # 2:
Parece que posso usar "mii-tool -r eth1" e "mii-tool -r eth2" para forçar uma renegociação do link, em vez de desconectar / reconectar os cabos. Isso só funciona com o IP estático configurado (o DHCP ainda falha). Observe também que "mii-tool" afirma que os dispositivos negociaram um link "1000baseT-HD" (half duplex), a ethtool me diz que é full duplex. O status mostrado antes e depois dos comandos "mii-tool -r" é o mesmo para mii-tool e 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