bugfix: ARP respond on all devices
A message that is not in the archive (sent off-list or not yet received): [email protected]
A message that is not in the archive (sent off-list or not yet received): [email protected]
A message that is not in the archive (sent off-list or not yet received): [email protected]
A message that is not in the archive (sent off-list or not yet received): [email protected]
Quoted 4 lines · Lars Marowsky-Bree
Yes, both are "correct" in the sense that the RFC allows this interpretation. The _sensible_ interpretation for practical networking however is #2, and the only persons who seem to believe differently are those in charge of the Linux network code...
Just spend a minute to think about multihoming and failover between multiple links on a host.
For that the Linux default makes a lot of sense - you get automatic transparent failover between interfaces without any effort.
In my experience everybody who wants a different behaviour use some more or less broken stateful L2/L3 switching hacks (like ipvs) or having broken routing tables. While such hacks may be valid for some uses they should not impact the default case.
-Andi
Quoted 4 lines · Andi Kleen
In my experience everybody who wants a different behaviour use some more or less broken stateful L2/L3 switching hacks (like ipvs) or having broken routing tables. While such hacks may be valid for some uses they should not impact the default case.
So, changing your default route is a "hack"? That's all that's necessary. You can even do it with "route del/route add".
Signature · 1 line
Daniel Gryniewicz <[email protected]>
Quoted 8 lines · Daniel Gryniewicz
Quoted 4 lines · Andi Kleen
In my experience everybody who wants a different behaviour use some more or less broken stateful L2/L3 switching hacks (like ipvs) or having broken routing tables. While such hacks may be valid for some uses they should not impact the default case.
So, changing your default route is a "hack"? That's all that's necessary. You can even do it with "route del/route add".
Necessary to do what exactly?
-Andi
Quoted 11 lines · Andi Kleen
Quoted 8 lines · Daniel Gryniewicz
Quoted 4 lines · Andi Kleen
In my experience everybody who wants a different behaviour use some more or less broken stateful L2/L3 switching hacks (like ipvs) or having broken routing tables. While such hacks may be valid for some uses they should not impact the default case.
So, changing your default route is a "hack"? That's all that's necessary. You can even do it with "route del/route add".
Necessary to do what exactly?
Cause Linux to issue an arp request with a tell address not on the interface sending the arp.
Signature · 1 line
Daniel Gryniewicz <[email protected]>
Quoted 8 lines · On 19 Aug 2003 15:27:48 -0400 Daniel Gryniewicz <[email protected]> wrote:
Quoted 7 lines · Andi Kleen
Quoted 6 lines · Daniel Gryniewicz
Quoted 4 lines · Andi Kleen
In my experience everybody who wants a different behaviour use some more or less broken stateful L2/L3 switching hacks (like ipvs) or having broken routing tables. While such hacks may be valid for some uses they should not impact the default case.
Quoted 7 lines
Quoted 4 lines
Quoted 2 lines
So, changing your default route is a "hack"? That's all that's necessary. You can even do it with "route del/route add".
Necessary to do what exactly?
Cause Linux to issue an arp request with a tell address not on the interface sending the arp.
Nobody has shown this to be invalid. In fact, it has been shown clearly that systems not responding to such ARP requests are buggy.
The only thing a system implementor can claim this accomplishes is "pseudo security", and it barely even provides that.
Quoted 8 lines · Daniel Gryniewicz
Quoted 7 lines · Andi Kleen
Quoted 6 lines · Daniel Gryniewicz
Quoted 4 lines · Andi Kleen
In my experience everybody who wants a different behaviour use some more or less broken stateful L2/L3 switching hacks (like ipvs) or having broken routing tables. While such hacks may be valid for some uses they should not impact the default case.
Quoted 7 lines
Quoted 4 lines
Quoted 2 lines
So, changing your default route is a "hack"? That's all that's necessary. You can even do it with "route del/route add".
Necessary to do what exactly?
Cause Linux to issue an arp request with a tell address not on the interface sending the arp.
I was merely talking about _answering_ ARP requests on all interfaces.
What happens on outgoing active ARPs is a different thing. Reasonable choices would be either the prefered source address of the route or the local interface's address. I must admit I don't have a strong opinion on what the better behaviour of those is, but neither of them would seem particularly wrong to me.
-Andi
Quoted 5 lines · On 19 Aug 2003 21:32:35 +0200 Andi Kleen <[email protected]> wrote:
What happens on outgoing active ARPs is a different thing. Reasonable choices would be either the prefered source address of the route or the local interface's address. I must admit I don't have a strong opinion on what the better behaviour of those is, but neither of them would seem particularly wrong to me.
Andi, we take the source address from the packet we are trying to send out that interface.
Just as it is going to be legal to send out a packet from that interface using that source address, it is legal to send out an ARP request from that interface using that source address.
Quoted 7 lines · David S. Miller
Andi, we take the source address from the packet we are trying to send out that interface.
Just as it is going to be legal to send out a packet from that interface using that source address, it is legal to send out an ARP request from that interface using that source address.
Legal yes, but it can get you into holes with asymettric routing.
Quoted 9 lines · On Tue, 19 Aug 2003 12:28:47 -0700 "David S. Miller" <[email protected]> wrote:
Quoted 5 lines · On 19 Aug 2003 21:32:35 +0200 Andi Kleen <[email protected]> wrote:
What happens on outgoing active ARPs is a different thing. Reasonable choices would be either the prefered source address of the route or the local interface's address. I must admit I don't have a strong opinion on what the better behaviour of those is, but neither of them would seem particularly wrong to me.
Quoted 7 lines
Andi, we take the source address from the packet we are trying to send out that interface.
Just as it is going to be legal to send out a packet from that interface using that source address, it is legal to send out an ARP request from that interface using that source address.
Aehm, sorry but the logic is bogus. A routed packet will be sent out this interface with a foreign IP as source, too. Though nobody will want to send an arp request with a foreign ip as source.
But you say here: Just as I can send out a packet with IP X from that interface I can send out ARP request with same source.
Obviously you don't want that.
So you cannot step from A to B in your logical chain here.
Again. I'd like to stress I don't want to insult you or anything. The simple thing is this: there are a lot setups out there that could benefit from your tolerance in this issue. Can't we simply take the issue to the point: "you are right, but you show tolerance for boxes that are not completely wrong" ? I mean the world is full of people that are right and intolerant, so that in fact doesn't really make them special ...
Please let us keep in mind that joe-average-user cannot handle complex setups with arpfilter, arp_filter or anything the like. But he can right away enter IT-superstore XYZ and buy a brand new router box for 20 bucks. If he is unlucky (and you stay intolerant) he will for sure _not_ blame this box but his desktop linux if things don't work out as expected.
I think we should at least make a minimum effort to keep things simple (and explainable to joe-average-user), even if the background is complex. Everywhere we have a solution for a problem that is overly complex, we will fail to gain a broad market share, because there may very likely be easier solutions under <name-some-os> _and_ we attract support problems for all distributors.
Regards,
Stephan
Quoted 2 lines · On Wed, 20 Aug 2003 17:41:33 +0200 Stephan von Krawczynski <[email protected]>…
Aehm, sorry but the logic is bogus. A routed packet will be sent out this interface with a foreign IP as source, too.
I'm talking about "local" addresses.
When we're routing, we'll use an interface address of course.
But when the packet is originating from our host, and the source address in the outgoing packet is local to us, we will use it as the source in the ARP packet.
Look at the algorithm in net/ipv4/arp_solicit() to see what I mean.
Quoted 2 lines · Daniel Gryniewicz
So, changing your default route is a "hack"? That's all that's necessary. You can even do it with "route del/route add".
(trimming down a bit)
% ip link show
3: eth3: <BROADCAST,MULTICAST,UP> mtu 1500 qdisc pfifo_fast qlen 100
link/ether 00:06:5b:ea:8e:4e brd ff:ff:ff:ff:ff:ff
6: eth1: <BROADCAST,MULTICAST,NOTRAILERS,UP> mtu 1500 qdisc pfifo_fast qlen 100
link/ether 00:02:2d:5c:11:48 brd ff:ff:ff:ff:ff:ff
% ip route sho
198.82.168.0/24 dev eth1 proto kernel scope link src 198.82.168.169
128.173.12.0/22 dev eth3 proto kernel scope link src 128.173.14.107 127.0.0.0/8 dev lo scope link
default via 128.173.12.1 dev eth3
eth1 is an 11mbit wireless on a fairly loaded net, eth3 is a 100mbit line.
If I try 'ip ro add default dev eth1 metric 1 via 198.82.168.1', things actually work As Expected - if I'm in the docking station, traffic goes via eth3 because it's lower cost, if I'm wandering it goes via wireless.
Until I fall out of the 128.173.12.1 ARP cache, it ARPS for my eth3 address, and my laptop gratuitously answers via eth1 - and since that isn't even the same router, it doesn't listen. Meanwhile, my laptop *doesnt* fall over to using wireless because it still has a lower-cost default route for the 100mbit side (and even if it did, any existing connections would still be hosed).
I can't believe I need to go beat my kernel over the head with 'arpfilter' or other crap just to get 2 interfaces to each reliably say "here I am" on their own damned subnet, not the OTHER subnet where nobody gives a rat's posterior about the other interface....
Quoted 5 lines · On Tue, 19 Aug 2003 15:38:51 -0400 [email protected] wrote:
% ip route sho
198.82.168.0/24 dev eth1 proto kernel scope link src 198.82.168.169 128.173.12.0/22 dev eth3 proto kernel scope link src 128.173.14.107127.0.0.0/8 dev lo scope link
default via 128.173.12.1 dev eth3
Please set the preferred source for eth1 to $(IP_OF_ETH1) and the preferred source for eth3 to $(IP_OF_ETH3) then do this:
bash# echo "1" >/proc/sys/net/ipv4/conf/eth1/arp_filter bash# echo "1" >/proc/sys/net/ipv4/conf/eth3/arp_filter
This also will make applications connecting using unspecified source addresses behave more sanely as well.
The thing you claim is the right thing to do is the wrong thing to do in environments other than your own.
Quoted 9 lines · David S. Miller
Please set the preferred source for eth1 to $(IP_OF_ETH1) and the preferred source for eth3 to $(IP_OF_ETH3) then do this:
bash# echo "1" >/proc/sys/net/ipv4/conf/eth1/arp_filter bash# echo "1" >/proc/sys/net/ipv4/conf/eth3/arp_filter
This also will make applications connecting using unspecified source addresses behave more sanely as well.
If I'm reading the code right, this will cause the interface to only deal with ARP that have that interface's IP configured, whatever it happens to be at this instant, so will DTRT for my configuration even when I'm doing DHCP or other similar...
Quoted 2 lines
The thing you claim is the right thing to do is the wrong thing to do in environments other than your own.
I never said it was the Right Thing for all environments, only that the default is sub-optimal for some (probably common) setups...
I'm off to test - if that's all that's needed, I'm outta this thread. ;)