Estou executando o linux 3.14 em um sistema com 2 interfaces. na primeira interface, posso acessar nossa rede local. na segunda interface, os pacotes arp entram, mas o linux não envia uma resposta. é possível que o endereço mac esteja fazendo com que o linux baixe os pacotes arp? O tcpdump mostra que o endereço de origem é proveniente de uma fonte: fe: xx: xx: xx: xx: xx. Eu não consigo encontrar nada na web para indicar como o Linux lida com esse tipo de endereço mac. o resto do pacote de 60 bytes parece bem. Eu até comparei os pacotes arp com os da primeira interface.
agradeço antecipadamente.
hi mathius, a propósito, eu também noto que sem rodar o tcpdump, a estatística do driver mostra que o pacote rx não incrementa. mas ao executar o tcpdump, a contagem de rx aumenta. então parece que o tcpdump está fazendo com que o driver aceite pacotes. talvez o tcpdump coloque o driver em modo promíscuo? esta é a saída do comando 'ip a s' e 'ip r s'. a interface eobc é o problema eobc
pad # ip a s 1: lo: mtu 65536 qdisc noop
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
2: eth0: mtu 1500 qdisc no início de nota 1000
link/ether 80:3f:5d:09:7f:4b brd ff:ff:ff:ff:ff:ff
3: eobc: mtu 1500 qdisc mq qlen 1000
link/ether 00:a0:c9:00:00:00 brd ff:ff:ff:ff:ff:ff
inet 192.168.0.10/24 brd 192.168.0.255 scope global eobc
valid_lft forever preferred_lft forever
inet6 fe80::2a0:c9ff:fe00:0/64 scope link
valid_lft forever preferred_lft forever
4: mgmt: mtu 1500 qdisc mq qlen 1000
link/ether 00:a0:c9:01:25:68 brd ff:ff:ff:ff:ff:ff
inet 172.24.22.68/24 brd 172.24.22.255 scope global mgmt
valid_lft forever preferred_lft forever
inet6 2001:420:293:1330:2a0:c9ff:fe01:2568/64 scope global dynamic
valid_lft 2591998sec preferred_lft 604798sec
inet6 fe80::2a0:c9ff:fe01:2568/64 scope link
valid_lft forever preferred_lft forever
5: bcm: mtu 1500 qdisc no início de 1000
link/ether 00:a0:c9:00:00:03 brd ff:ff:ff:ff:ff:ff
pad # ip r s
padrão via 192.168.0.100 dev eobc
padrão via 172.24.22.1 dev mgmt
172.24.22.0/24 dev mgmt src 172.24.22.68
192.168.0.0/24 dev eobc src 192.168.0.10
pad #
seguindo a sugestão de xavier, eu ainda estou vendo o mesmo problema. (eliminei os padrões duplicados) e modifiquei o roteamento como tal:
pad # ip r s
padrão via 172.24.22.1 dev mgmt
172.24.22.0/24 dev mgmt src 172.24.22.68
192.168.0.0/24 dev eobc