Webmail Support



  • @morbiuswilters said:

    Um, that doesn't seem to be the same thing at all.  Lingerance had different physical networks with different network addresses, so an interface should not respond to an ARP with the MAC of another interface on a separate network.
     

    Okay, never mind.  Sorry, didn't read the thread carefully.  My bad. 

    But your statement below is still incorrect:

    If this is right, it's a bug with his kernel because a normal Linux machine should never return a MAC address for an IP that is not bound to the interface the ARP request came in on.

     



  • @CodeSimian said:

    @morbiuswilters said:

    Um, that doesn't seem to be the same thing at all.  Lingerance had different physical networks with different network addresses, so an interface should not respond to an ARP with the MAC of another interface on a separate network.
     

    Okay, never mind.  Sorry, didn't read the thread carefully.  My bad. 

    But your statement below is still incorrect:

    If this is right, it's a bug with his kernel because a normal Linux machine should never return a MAC address for an IP that is not bound to the interface the ARP request came in on.

     

    True, but I didn't mean it quite that absolutely.  I suppose my wording was bad, but it's kind of a complicated subject and I was referring specifically to Lingerance's problem.  I understand your point, but generally you don't have a setup where Linux will respond to the ARP in such a way. 



  • @morbiuswilters said:

    I suppose my wording was bad, but it's kind of a complicated subject and I was referring specifically to Lingerance's problem.  I understand your point, but generally you don't have a setup where Linux will respond to the ARP in such a way. 
     

    Okay, cool.  Note to self: next time read entire thread carefully before posting long-winded irrelevant comment. 



  • @morbiuswilters said:

    you're saying it responds to ARPs for an IP that isn't bound to the interface the ARP came in on? That would be fucked up,
    @morbiuswilters said:
    ... generally you don't have a setup where Linux will respond to the ARP in such a way.
    Actually, according to the link that CodeSimian posted, and some testing, it appears that that is exactly how the Linux kernel behaves.

    Random example:
    eth0 192.168.1.5
    eth1 10.4.4.20
    ppp0 172.16.5.5

    ARPing from the 192.168.1.0/24 network for any of those three addresses will return the MAC of the eth0 interface. ARPing from the 10.4.4.0/24 network for any of those three addresses will return the MAC of the eth1 interface. This is true even for the 172.16.5.5 address bound to the ppp0 adapter, despite the fact that ppp is not ARPable!

    (I've just tested this with my Linux-based DSL modem, which exhibits this behaviour. I can ARP the ppp0 address from the wifi network, and get the address of the wifi NIC back.

    The kernel will even accept packets for the distant interface's IP address, unless rp_filter is turned on...



  • @random_garbage said:

    Actually, according to the link that CodeSimian posted, and some testing, it appears that that is exactly how the Linux kernel behaves.

    Random example:
    eth0 192.168.1.5
    eth1 10.4.4.20
    ppp0 172.16.5.5

    ARPing from the 192.168.1.0/24 network for any of those three addresses will return the MAC of the eth0 interface.

    Hmm, that's what I get for not having the courage of my convictions!  Anyway, when I encountered this issue at work (over a year ago), we were only worried about the issue with 2 ethernet interfaces plugged into the same physical segment, configured on the same IP subnet.   We turned on arp_filter, the problem went away, and we never looked at it again. If it had happened yesterday, I probably would've been more confident about the little details like "does this issue happen with interfaces configured for different IP subnets?".

    That's what I get for referencing a long-forgotten article without re-reading it completely! 

     



  •  By the way, thanks for testing the arp filter issue, random_garbage!  



  • @random_garbage said:

    Actually, according to the link that CodeSimian posted, and some testing, it appears that that is exactly how the Linux kernel behaves.

     

    After digging deeper into this, it appears both you and CodeSimian are correct, the default behavior for the kernel is to respond to ARPs "promiscuously".  The /proc setting is arp_ignore, not arp_filter.  My own kernels have patches applied that default arp_ignore to 2, so I had never seen this behavior before, but I pulled the kernel.org sources and confirmed that it defaults to 0.  This is majorly idiotic, but I'm pretty much used to "features" like this in the kernel.  I appreciate the info, thanks for looking into it.



  •  @morbiuswilters said:

    The /proc setting is arp_ignore, not arp_filter. 

    Just wanna point out that arp_ignore was introduced in kernel 2.6, and was recently backported to 2.4, in case anyone is running an old distro.   Full descriptions of the 2 settings can be found here:

    http://dsd.lbl.gov/TCP-tuning/ip-sysctl-2.6.txt 



  • Correction: 

    @CodeSimian said:

    arp_ignore was introduced in kernel 2.6, and was recently backported to 2.4
     


Log in to reply