I am running linux 3.14 on a system with 2 interfaces. on the first interface, i can access our local network. on the second interface, arp packets come in but linux doesn't send out reply. is it possible that the mac address is causing linux to drop arp packets? tcpdump shows that source address is coming from a source: fe:xx:xx:xx:xx:xx. i am not able to find anything on the web to indicate how linux handles this type of mac address. the rest of the 60 byte packet looks fine. i even compared the arp packets with the ones from the first interface.

thank you in advance.

hi mathius by the way, i also notice that without running tcpdump, the driver statistic shows rx packet doesn't increment. but when running tcpdump, rx count increases. so it seems that tcpdump is causing driver to accept packets. perhaps tcpdump puts driver in promiscous mode? this is the output of 'ip a s ' and 'ip r s ' command. the eobc interface is the problem 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 noop qlen 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 noop qlen 1000

link/ether 00:a0:c9:00:00:03 brd ff:ff:ff:ff:ff:ff

pad# ip r s

default via 192.168.0.100 dev eobc

default 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#
following xavier's suggestion, i am still seeing the same issue. ( i eliminated the duplicate defaults) and modified routing as such: pad# ip r s default 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

  • Can you provide the output from the commands ip a s and ip r s? – Mathias Weidner Dec 17 '14 at 8:44
  • hi mathias, here is the dump of 'ip r s' default via 192.168.0.100 dev eobc default 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 – mark Dec 17 '14 at 18:14
  • hi mathis, i included the output in the original comment above. i was not able to add them in the comment (too long). thank you. – mark Dec 17 '14 at 18:23
  • @mark You have two default routes defined. – Xavier Lucas Dec 17 '14 at 21:17
  • hi xavier, thank you. i modified the routing. still same issue not getting arp to go out. here's the change:<p>pad# ip r s default via 172.24.22.1 dev mgmt<p><p> 172.24.22.0/24 dev mgmt src 172.24.22.68<p><p> 192.168.0.0/24 dev eobc<p><p> pad# – mark Dec 18 '14 at 5:46

Your Answer

By clicking "Post Your Answer", you acknowledge that you have read our updated terms of service, privacy policy and cookie policy, and that your continued use of the website is subject to these policies.

Browse other questions tagged or ask your own question.