Take the 2-minute tour ×
Server Fault is a question and answer site for system and network administrators. It's 100% free, no registration required.

I've got a robot running linux with wired and wireless adapters. When I boot up, it connects to the wireless fine. When I assign an IP to the wired (either statically or with DHCP), it looks like it works. As in, ifconfig shows a proper IP and route shows proper routes. However, when I do an ARP request of the wired IP, the ARP reply contains the wireless MAC.

??? There's no bridge running on the robot, so why don't I get the wired MAC???

When the wire is disconnected, the wired IP replies to ping...

Why is the robot replying over the wireless interface to IP requests on the wired???

EDIT: both the wired and wireless adapters on the same IP subnet. I do an ARP request from a computer (tried with different computers) on the same IP subnet.

relevant ifconfig output:

eth0      Link encap:Ethernet  HWaddr 00:01:C0:04:BD:F7  
          inet addr:192.168.0.110  Bcast:192.168.0.255  Mask:255.255.255.0
          UP BROADCAST MULTICAST  MTU:1500  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000 
          RX bytes:0 (0.0 B)  TX bytes:0 (0.0 B)
ra0       Link encap:Ethernet  HWaddr 24:3C:20:06:3E:6D  
          inet addr:192.168.0.101  Bcast:192.168.0.255  Mask:255.255.255.0
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:0 errors:59 dropped:0 overruns:0 frame:0
          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000 
          RX bytes:31023598 (29.5 MiB)  TX bytes:85640627 (81.6 MiB)

relevant route output:

Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
192.168.0.0     0.0.0.0         255.255.255.0   U     0      0        0 ra0
192.168.0.0     0.0.0.0         255.255.255.0   U     0      0        0 eth0

It's a very cutdown linux, so I don't have tools like artptables, iptables, sysctl, brctl, etc.

EDIT: diagram as requested

network diagram

EDIT: I am dumping traffic and looking at the ARP table. An ARP request of 192.168.0.110 returns an ARP reply containing 24:3C:20:06:3E:6D. The source MAC of the ARP reply packet is also 24:3C:20:06:3E:6D. I've tried fiddling with _filter, _ignore, and _announce, as mentioned here, but to no avail.

EDIT: setting a gateway (on either interface) makes no difference (as it shouldn't).

EDIT: this worked fine on a previous version of the OS (based on openembedded). is it possible they changed something?

share|improve this question
5  
maybe a diagram would be cool, and you could put a robot in it...extra cool points –  The Unix Janitor Mar 15 '11 at 8:30
    
Are both the wired and wireless adapters on the same IP subnet? Where do you "do an ARP request" from? It might help to include the results of 'ifconfig' and show your routing table. –  Dave Mar 16 '11 at 5:12
    
Did this ever get resolved? I'm seeing a similar issue, and have been thoroughly unable to find the resolution. –  Kirk Nov 1 '11 at 21:24
1  
i believe the kernel module for the wireless card was broken. –  Jayen Nov 2 '11 at 1:36
1  
The question is WHY are you doing this... I'm guessing that you are wanting it so that when the robot is mobile it can talk, but when you plug in an Ethernet cable you can get high transfer speeds? If so, have you considered bonding the wired and wireless interfaces, putting them both on the same IP, and then configuring it so that if the wired is up, it gets priority, but if not traffic goes over the wireless? I used to set up my laptop this way and it worked great, but now I have 300Mbps wireless rather than 2Mbps, so I don't do that any more. –  Sean Reifschneider Nov 8 '11 at 1:51

5 Answers 5

When you say you get an ARP response for the wrong interface, are you actually dumping traffic or just looking at the resulting ARP table? It's possible you're getting ARP replies for both interfaces...

Anyway, I believe the answer to your problem lies in properly manipulating rp_filter and arp_filter. The documentation for each of them is included below.

I suggest first trying this:

echo 1 > /proc/sys/net/ipv4/conf/all/arp_filter

You may need to make this change as well:

echo 0 > /proc/sys/net/ipv4/conf/all/rp_filter
rp_filter - BOOLEAN
    1 - do source validation by reversed path, as specified in RFC1812
        Recommended option for single homed hosts and stub network
        routers. Could cause troubles for complicated (not loop free)
        networks running a slow unreliable protocol (sort of RIP),
        or using static routes.

    0 - No source validation.

    conf/all/rp_filter must also be set to TRUE to do source validation
    on the interface

    Default value is 0. Note that some distributions enable it
    in startup scripts.

arp_filter - BOOLEAN
    1 - Allows you to have multiple network interfaces on the same
    subnet, and have the ARPs for each interface be answered
    based on whether or not the kernel would route a packet from
    the ARP'd IP out that interface (therefore you must use source
    based routing for this to work). In other words it allows control
    of which cards (usually 1) will respond to an arp request.

    0 - (default) The kernel can respond to arp requests with addresses
    from other interfaces. This may seem wrong but it usually makes
    sense, because it increases the chance of successful communication.
    IP addresses are owned by the complete host on Linux, not by
    particular interfaces. Only for more complex setups like load-
    balancing, does this behaviour cause problems.

    arp_filter for the interface will be enabled if at least one of
    conf/{all,interface}/arp_filter is set to TRUE,
    it will be disabled otherwise

For a more thorough treatment, see this article:

http://www.embedded-bits.co.uk/tag/rp_filter/

share|improve this answer
    
I am dumping traffic and looking at the ARP table. An ARP request of 192.168.0.110 returns an ARP reply containing 24:3C:20:06:3E:6D. The source MAC of the packet is also 24:3C:20:06:3E:6D. I've tried both of your suggested filter settings, but to no avail. I've also tried playing with _ignore and _announce, as mentioned here. –  Jayen Mar 17 '11 at 1:01

i think there is a misconfiguration between your wireless AP and your switch. switch and AP are getting confused where to send packets. not sure about this though. also, i think you should try to define a gateway where programs can know where to send packets. something like

route add default gw 192.168.0.1

share|improve this answer
    
laptops on both the wired and wireless work fine, so it's not the AP or switch. also, a gateway is only necessary when i'm trying to get outside the subnet. (i tried it anyway, and it doesn't change anything. doesn't matter if i add the gateway to eth0 or ra0.) –  Jayen Mar 17 '11 at 4:23
    
there is no RX/TX on your eth0, indicates some config. error? –  fmysky Mar 17 '11 at 21:47
    
hrm, i guess that's true. eth0 should at least receive the ARP request, since it's a broadcast, right? –  Jayen Mar 17 '11 at 22:28
    
yes, thats what i thought –  fmysky Mar 17 '11 at 23:16
    
arp problem in that lwn article seems to affect only 2.4.x kernels –  fmysky Mar 17 '11 at 23:26

What you are seeing is normal behavior when you have two interfaces on the same network. It is described in this LWN article.

share|improve this answer
    
setting arp_filter has no effect. why not? –  Jayen Mar 17 '11 at 22:27
1  
Since both your interfaces have routes to the local network, linux will send packets from either of your IPs out either of your interfaces. Thus it will answer ARP requests for either of your IPs from both interfaces. To change this, you must not only set arp_filter to 1, you must also enable source-based routing and set up routing tables that ensure that traffic for each IP goes out the interface you want. It's a slightly different scenario than what you have, but wlug.org.nz/SourceBasedRouting might help you. –  sciurus Mar 18 '11 at 1:48

Following up on Insyte's comment.

Lets do some naming:

  • PC1 - Top Right
  • PC2 - Top Left
  • PC3 - Bottom Left

For you have your robot reachable from the 3 PCs via both wired and wireless media. And for they are on same subnet you cannot for sure tell that which way the arp request for your wired media has gone through. By that what I mean is when the switch broadcasts for an arp request, your robot receives it on both the interfaces [referring to your diagram] so for it receives the arp request for the IP on the wired media on the wireless media too chances are it replied with the physical address of the wireless media for the box does have that IP configured in it

I have had this issue in the past, it wasn't exact to yours but was similar. By default linux replies with the physical address of the interface it receives the arp request regardless of which interface the IP is configured onto. So in your case connect PC3 to the robot's eth0 interface directly and do an arp request for 192.168.0.101 it would reply you with the physical address of the eth0 interface instead of ra0.

My deployment scenario was:

[RTR] |------------eth0---[server]
|--------| switch1 |-----eth1-----[server]

Its the same switch, that both interfaces connect to. Hopeful that it would help you.

The router had primary and secondary IP address configured on its interface for two different networks on the two different interfaces on the server. But receiving an arp request on eth1 for IP address of eth0 it did reply with the physical address of eth1

To prevent it the following has so far worked for me

# echo 2 > /proc/sys/net/ipv4/conf/eth0/arp_announce
# echo 1 > /proc/sys/net/ipv4/conf/eth0/arp_ignore
# echo 2 > /proc/sys/net/ipv4/conf/ra0/arp_announce
# echo 1 > /proc/sys/net/ipv4/conf/ra0/arp_ignore

put it somewhere on your robot so you can get it be applied at boot.

Recommendations: I would recommend you have two different subnets be configured (say 192.168.1.x/24 on ra0 and 192.168.2.x/24 on eth0) you can use IP aliases on your PCs and your robot would be accessible over any of the two IPs. You cannot have two outbound paths for same subnet on a same host. Not unless there is something that makes your robot prefer one over another. Your robot can only take one path to send packets out of it.

Some readings: arp_announce, arp_ignore

share|improve this answer
    
arp_announce & arp_ignore didn't work for me. see my comment on insyte's solution. Two different subnets is unfortunately, not an option. Also, as per the last edit of my question, this worked fine on a previous version of the OS, so I can have two outbound paths for same subnet on a same host. –  Jayen Nov 2 '11 at 22:10

As this worked fine on a previous version of the OS (based on openembedded), my solution was to wait for the next version of the OS. My best guess was that the wireless kernel module was buggy.

share|improve this answer
    
Unlikely, since the behavior you are experiencing is expected as mentioned by @sciurus. It may be that the previous release where it "worked fine" was the buggy one and they have fixed it :-). Actually, it's just whichever one responds last is the one that sticks in the ARP table on the remote end. Since wireless is likely slower than wired, you're going to get wireless. –  Sean Reifschneider Nov 8 '11 at 1:47

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.