1

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

mark
  • 29
  • 1
  • 1
  • 7
  • Can you provide the output from the commands `ip a s` and `ip r s`? – Mathias Weidner Dec 17 '14 at 08: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:

    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

    pad#

     – mark Dec 18 '14 at 05:46
  • According to the MAC addresses, both NICs should be from Intel, right? What bothers me is the MAC address 00:a0:c9:00:00:00. Maybe your kernel driver is not appropriate for the ethernet card. – Mathias Weidner Dec 19 '14 at 09:50
  • @mark Can you clarify what are the IPs concerned by the ARP broadcast (source / destination) ? What's the target mac address ? A tcpdump excerpt would help, just to make sure we get the full picture. – Xavier Lucas Dec 19 '14 at 10:33
  • Are the two interfaces connected to the same VLAN? – pepoluan Dec 22 '14 at 09:44
  • hi everyone . thank you for your help. pepoluan is correct. it turned out that interfaces were on different vlan...thank you for all your help. hope you have happy new year.! – mark Dec 28 '14 at 04:11

0 Answers0