linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
* [2.4 PATCH] bugfix: ARP respond on all devices
@ 2003-07-27 20:52 Bas Bloemsaat
  2003-07-27 22:12 ` David S. Miller
  2003-07-27 23:40 ` Carlos Velasco
  0 siblings, 2 replies; 168+ messages in thread
From: Bas Bloemsaat @ 2003-07-27 20:52 UTC (permalink / raw)
  To: marcelo, netdev, linux-net; +Cc: layes, torvalds, linux-kernel

Yesterday (20030726) I found out, that with two NICs on one ethernet
segment, ARPing for one IP address gave me two answers, one from each NIC
with the MAC address from each of them. They each have a seperate IP
address. First I thought the NICs where doing proxy arp on each other,
but it turned out that this wasn't the case. On closer examination it
turned out that any ARP request to a local IP resulted in a response,
even if the devices were on different subnets or ethernet segments.

I learned from the kernel sources that any NIC receiving an ARP request
for any local IP adress would respond to that request. Among others, that
has the following implications:
- when you have two NICs same ethernet segment, only one of them is used:
they both respond to any ARP request. As only the first response is ever
used (fasted router), only the NIC that responds first receives any
traffic. This NIC may or may not be bound to the destination IP. It may
not even be reachable because of iptables-rules. This also defeats a
common form of load balancing.
- when you have two NICs on seperate ethernet segments, for example on a
firewall, it is possible to probe one NIC for the IP address of the other.
This can be used to gain information about the inside network of the
firewall, which is a (minor) security risk. While this is not really
practical because every IP address has to be tried, often the inside is of
a limit range (10.x.x.x, 192.168.x.x), which makes it useful.

I think this is unwanted behaviour. This patch corrects the situation. It
makes every device only respond to ARP requests for IP addresses bound to
that device, not all local IP addresses. Proxy ARP still applies as
before.

The patch was made from 2.4.21. It patches 2.4.22-pre8 cleanly and tests
okay on both. Please apply.


diff -urN linux-2.4.21.orig/include/linux/inetdevice.h linux-2.4.21-okayclean/include/linux/inetdevice.h
--- linux-2.4.21.orig/include/linux/inetdevice.h	2002-08-03 02:39:45.000000000 +0200
+++ linux-2.4.21-okayclean/include/linux/inetdevice.h	2003-07-27 18:51:28.000000000 +0200
@@ -86,6 +86,7 @@
 extern u32		inet_select_addr(const struct net_device *dev, u32 dst, int scope);
 extern struct in_ifaddr *inet_ifa_byprefix(struct in_device *in_dev, u32 prefix, u32 mask);
 extern void		inet_forward_change(void);
+extern int 		inet_addr_local_dev(struct in_device *in_dev, u32 addr);

 static __inline__ int inet_ifa_match(u32 addr, struct in_ifaddr *ifa)
 {
diff -urN linux-2.4.21.orig/net/ipv4/arp.c linux-2.4.21-okayclean/net/ipv4/arp.c
--- linux-2.4.21.orig/net/ipv4/arp.c	2002-11-29 00:53:15.000000000 +0100
+++ linux-2.4.21-okayclean/net/ipv4/arp.c	2003-07-27 21:12:17.000000000 +0200
@@ -66,6 +66,7 @@
  *		Alexey Kuznetsov:	new arp state machine;
  *					now it is in net/core/neighbour.c.
  *		Krzysztof Halasa:	Added Frame Relay ARP support.
+ *		Bas Bloemsaat	:	(20030727) Fixed respond on all devices bug
  */

 #include <linux/types.h>
@@ -766,7 +767,9 @@
 		rt = (struct rtable*)skb->dst;
 		addr_type = rt->rt_type;

-		if (addr_type == RTN_LOCAL) {
+
+		/* check if arp is for this device */
+		if (inet_addr_local_dev(in_dev,tip)) {
 			n = neigh_event_ns(&arp_tbl, sha, &sip, dev);
 			if (n) {
 				int dont_send = 0;
@@ -778,6 +781,8 @@
 				neigh_release(n);
 			}
 			goto out;
+
+		/* check if we can and have to proxy it */
 		} else if (IN_DEV_FORWARD(in_dev)) {
 			if ((rt->rt_flags&RTCF_DNAT) ||
 			    (addr_type == RTN_UNICAST  && rt->u.dst.dev != dev &&
diff -urN linux-2.4.21.orig/net/ipv4/devinet.c linux-2.4.21-okayclean/net/ipv4/devinet.c
--- linux-2.4.21.orig/net/ipv4/devinet.c	2003-06-13 16:51:39.000000000 +0200
+++ linux-2.4.21-okayclean/net/ipv4/devinet.c	2003-07-27 18:50:19.000000000 +0200
@@ -199,6 +199,17 @@
 	return 0;
 }

+int
+inet_addr_local_dev(struct in_device *in_dev, u32 addr)
+{
+	for_ifa(in_dev) {
+		if (!(addr^ifa->ifa_address))
+			return -1;
+	} endfor_ifa(in_dev);
+
+	return 0;
+}
+
 static void
 inet_del_ifa(struct in_device *in_dev, struct in_ifaddr **ifap, int destroy)
 {


^ permalink raw reply	[flat|nested] 168+ messages in thread
[parent not found: <e2Yb.5CB.17@gated-at.bofh.it>]
* RE: [2.4 PATCH] bugfix: ARP respond on all devices
@ 2003-08-19 12:02 Richard Underwood
  2003-08-19 12:35 ` Alan Cox
                   ` (2 more replies)
  0 siblings, 3 replies; 168+ messages in thread
From: Richard Underwood @ 2003-08-19 12:02 UTC (permalink / raw)
  To: 'David S. Miller', Stephan von Krawczynski
  Cc: willy, alan, carlosev, lamont, davidsen, bloemsaa, marcelo,
	netdev, linux-net, layes, torvalds, linux-kernel

David S. Miller wrote:
>
> > _And_ you did not explain so far why these implementations should
> > not be RFC-conform or else illegal.
> 
> Both responding and not responding on all interfaces for ARPs
> is RFC conformant.  This means both Linux and other systems
> are within the rules.
> 
	Firstly, can I point out that you have consistently talked about
REPLIES when everyone else has been talking about REQUESTS. I suspect that
this may be confusing more people than you realise.

	The RFC I quoted (985) says the ARP packets generated by Linux
should be dropped. Sure, the RFC isn't a standard, but there ARE plenty of
implementations that obey it for perfectly valid security reasons.

> Under Linux, by default, IP addresses are owned by the system
> not by interfaces.  This increases the likelyhood of successful
> communication on a subnet.
> 
	This is crap.

	ARP is local to a broadcast net. The ARP standard explicitly
prohibits responding to an ARP request on a different interface.

	If you broadcast a request asking for a reply on an entirely
different subnet, you're asking for trouble. You REDUCE the likelyhood of a
successful ARP reply, not increase it.

	All you can possibly achieve by sending REQUESTS from the wrong IP
number is assist screwed up networks where you've got multiple subnets on
the same copper and cause a shed-load of security issues.

> For scenerios where this doesn't work, we have ways to make the
> kernel behave the way you want it to.
> 
	There are many ways of "fixing" it. I've chosen a static ARP entry
for my next-hop. I really don't care. The issue is that the Linux ARP code
is, apparently by design, flawed.

> There is no discussion about changing the default, because that
> might break things for some people.  So this discussion is pretty
> useless.

	Can you give one good example where this is the case?

	What makes all this worse is that once an ARP request has been
queued using the wrong IP number, further connections that would otherwise
have generated a valid ARP request will be blocked as Linux won't queue a
second request - despite it coming from a different IP number.

	This means that connectivity is non-deterministic, and while
everything may work for 99.9% of the time, when an ARP entry gets deleted
and the next ARP request comes from the wrong IP number you lose
connectivity.

	I wonder how many unsolved random network problems there have been
due to this. "Just reboot it, it'll work again." Great!

	If you insist on leaving the code as it is, at the very least allow
multiple incomplete ARP requests, one per source IP.

	Thanks,

		Richard

^ permalink raw reply	[flat|nested] 168+ messages in thread
* RE: [2.4 PATCH] bugfix: ARP respond on all devices
@ 2003-08-19 14:34 Richard Underwood
  2003-08-19 14:54 ` Willy Tarreau
  2003-08-19 19:08 ` Alan Cox
  0 siblings, 2 replies; 168+ messages in thread
From: Richard Underwood @ 2003-08-19 14:34 UTC (permalink / raw)
  To: 'Alan Cox'
  Cc: 'David S. Miller',
	Stephan von Krawczynski, willy, carlosev, lamont, davidsen,
	bloemsaa, Marcelo Tosatti, netdev, linux-net, layes, torvalds,
	Linux Kernel Mailing List

Alan Cox wrote:
> 
> You increase it and you shortcut on shared lans. Thats really a seperate
> issue to the question of which source is used. If you loopback someone
> elses address on your own lo device I'm not suprised weird 
> shit happens, put the alias on eth0 where it belongs.
> 
	Woah! I'm not talking about JUST load-balanced networks. This is a
far more generic problem.

	As an example, I have a router/firewall for the office that has two
interface cards, both with perfectly valid internal addresses - these
addresses aren't used anywhere else on the network.

	Two of the interfaces are: 172.20.240.2/24 and 172.24.0.1/16. My
default gateway is 172.20.240.1 and there aren't any other non-interface
routes. If I do:

# arp -d 172.24.0.80
# ping -I 172.20.240.2 172.24.0.80

	I see:

16:18:40.856328 arp who-has 172.24.0.80 tell 172.20.240.2
16:18:40.856431 arp reply 172.24.0.80 is-at 0:50:da:44:f:37

	Now, since 172.24.0.80 is a Linux box, it's happily adding
172.20.240.2 into its ARP table and reply to it, hence the reply.

	But if I was to do this in the other direction (arp -d 172.20.240.1;
ping -I 172.24.0.1 172.20.240.1) then I'd lose connectivity over my default
route because 172.20.240.1 won't accept ARP packets from IP numbers not on
the connected subnet. The <incomplete> ARP entry will block any further ARP
requests from valid IP numbers.

	This, in my opinion, isn't on. There must be thousands of Linux
installations out there that (1) have more than one interfaces and (2) are
connected to routers or firewalls that drop ARP requests in the same way. 

	Actually, it's not that bad in this case as the next hop will
probably send an ARP request at some point which will override it - but
that's really not the point.

	If the routeing was asymetric, or the next hop had a static ARP
entry for me, all communication would quite simply be lost. It'd just take
the first packet after an ARP entry times out to be from the wrong IP
address, and the host would be off the net.

	I personally don't think "shared LANs" should be favoured over best
practice. Even in the case of shared LANs, nothing "breaks" as David Miller
suggests would happen if the ARPs were fixed.

	Thanks,

		Richard

^ permalink raw reply	[flat|nested] 168+ messages in thread
* RE: [2.4 PATCH] bugfix: ARP respond on all devices
@ 2003-08-19 16:54 Richard Underwood
  2003-08-19 16:51 ` David S. Miller
  0 siblings, 1 reply; 168+ messages in thread
From: Richard Underwood @ 2003-08-19 16:54 UTC (permalink / raw)
  To: 'David S. Miller', Stephan von Krawczynski
  Cc: willy, alan, carlosev, lamont, davidsen, bloemsaa, marcelo,
	netdev, linux-net, layes, torvalds, linux-kernel

David S. Miller wrote:
> 
> It means that systems (like Linux) that make IP addresses owned by the
> host instead of specific interfaces cannot correctly interoperate with
> such remote systems.
> 
	This makes sense for replies, but not for requests.

	When a HOST sends out an ARP request, it's NOT associated with a
single connection, it's associated with the host. Why should it pick a
"random" IP number to send as the source address?

	The way the network code is currently, you're reducing your
connectivity to chance. There should be a defined process for making a
connection to another host. As it stands, this process is simply not
predictable.

	If you insist that an ARP request IS directly associated with a
connection, then you are required to have one ARP cache per source IP
address. It'd be predictable again ... but I don't think anyone wants to go
there.

> It is also the case that a host cannot possibly be aware of all
> subnets present on a given LAN, therefore is should be liberal in it's
> replies to ARP requests.
> 
	Well, actually, I know exactly which IP subnets are on which LAN
segments - they're defined by the IP address and subnet of the interface. I
think you'll find that this a pretty basic feature of most hosts.

> Finally, it violates the most basic rule of IP networking:
> 
> "Be liberal in what you accept, and conservative in what you send"
> -Jon Postel
> 
	I'm sorry, but Linux simply isn't being conservative in what it
sends. It's being bloody awkward.

	Look at it this way - when a host sends out an ARP request, it WANTS
a reply, it's not doing it for fun. If it uses the IP number of the
interface it's sending the ARP request on, it will ALWAYS get a reply
(assuming there's one to get.) If it uses the IP number of another
interface, it MAY get a reply, but it MAY NOT.

	Are there any cases when this is reversed? I don't think so! Linux
is being intentionally difficult, and as far as I can tell, for no good
reason.

> In general, when a host posses the information necessary to allow
> other hosts to communicate, it should provide that information
> whenever possible.
> 
	No, it should follow the rules for letting traffic pass through it.
Just because a host can see two networks, doesn't mean it should route
between them - it possesses information, but there have to be rules to
determine how this information is used.

	Compare it to IP: If a firewall sees a packet come in on an
interface it shouldn't, it'll probably drop it - it's called anti-spoofing.
Should the firewall forward the packet on just because it can?

	So at the lower layer, a router sees an ARP packet with what looks
like a "spoofed" source address. Should it trust it implicitly and place it
in its cache, or should it drop it?

	No one yet has given one single example of a network that relies on
Linux's current behaviour. I've given two examples of networks that break
because of it. I would kindly suggest that the default should be changed.

	Thanks,

		Richard

^ permalink raw reply	[flat|nested] 168+ messages in thread
* RE: [2.4 PATCH] bugfix: ARP respond on all devices
@ 2003-08-19 17:56 Richard Underwood
  2003-08-19 17:53 ` David S. Miller
  0 siblings, 1 reply; 168+ messages in thread
From: Richard Underwood @ 2003-08-19 17:56 UTC (permalink / raw)
  To: 'David S. Miller'
  Cc: skraw, willy, alan, carlosev, lamont, davidsen, bloemsaa,
	marcelo, netdev, linux-net, layes, torvalds, linux-kernel

David S. Miller wrote:
> > 	When a HOST sends out an ARP request, it's NOT associated with a
> > single connection, it's associated with the host. Why 
> should it pick a
> > "random" IP number to send as the source address?
> 
> It's not "random", it is using the IP address it intends
> to use as the source in packets it will output once the
> ARP completes.
> 
> In fact, if you look at the code in arp_solicit(), the source address
> is coming directly from the packet we are trying to output.
> 
	Which nicely sums up the bug, really.

1) The ARP response (or lack thereof) will be used for more than that
connection, using a single packet's source IP address is meaningless and
just a little aribtrary.

2) Depending on which ARP request or reply gets seen first, packets may get
routed over different interfaces or not sent out at all.

3) The code is over-complex. There must already be perfectly good code to
pick up the interface's IP address as this would HAVE to be the case when a
packet has been routed from another host.

	This sort of randomness is not acceptable in a reliable network.

		Richard

^ permalink raw reply	[flat|nested] 168+ messages in thread
* RE: [2.4 PATCH] bugfix: ARP respond on all devices
@ 2003-08-19 18:05 Richard Underwood
  2003-08-19 18:21 ` David S. Miller
  0 siblings, 1 reply; 168+ messages in thread
From: Richard Underwood @ 2003-08-19 18:05 UTC (permalink / raw)
  To: 'David S. Miller', Stephan von Krawczynski
  Cc: willy, alan, carlosev, lamont, davidsen, bloemsaa, marcelo,
	netdev, linux-net, layes, torvalds, linux-kernel

David S. Miller wrote:
> 
> In the ARP request we are using the source address in the packet we
> are building for output.
> 
	Well, you shouldn't be! The ARP request represents all FUTURE
packets being sent out that interface, not just the one single packet that
happened to kick of this ARP request.

> If ARP doesn't work using that source address, we can only assume IP
> communication is not possible either.
> 
	That's clearly not a valid assumption. For a start it precludes IP
routeing, but I've also demonstrated it not to be the case with a simple
multi-homed server.

	Thanks,

		Richard

^ permalink raw reply	[flat|nested] 168+ messages in thread
* RE: [2.4 PATCH] bugfix: ARP respond on all devices
@ 2003-08-19 18:16 Richard Underwood
  2003-08-19 18:13 ` David S. Miller
  0 siblings, 1 reply; 168+ messages in thread
From: Richard Underwood @ 2003-08-19 18:16 UTC (permalink / raw)
  To: 'David S. Miller'
  Cc: skraw, willy, alan, carlosev, lamont, davidsen, bloemsaa,
	marcelo, netdev, linux-net, layes, torvalds, linux-kernel

David S. Miller wrote:
> > 	Which nicely sums up the bug, really.
> 
> Ok, then how would you propose to be able to send
> packets out an interface _before_ we have addresses
> assigned to it?
> 
	IP packets you mean? You don't? ;) It would depend on why you're
doing it naturally. Mostly, I'd have thought that if a host doesn't have an
IP number it doesn't get to use ARP.

> Linux allows that, and in fact it's a useful feature.
> 
> Consider MSG_DONTROUTE as well.
> 
	Irrelevant, ARP should stick to resolving Layer 2 issues, not be
misused as some Layer 3 routeing protocol.

> BTW, this ARP source address algorithm we use comes from
> ipv6, it would be instructive to go and see why they do
> things the way they do.
> 
	If you'd like to give me a reference, I'd be happy to look at the
spec. It doesn't matter where you got the concept from, though - it's
flawed.

		Richard

^ permalink raw reply	[flat|nested] 168+ messages in thread
[parent not found: <mdtk.Zy.1@gated-at.bofh.it>]
* RE: [2.4 PATCH] bugfix: ARP respond on all devices
@ 2003-08-19 19:00 Richard Underwood
  2003-08-19 18:58 ` David S. Miller
  0 siblings, 1 reply; 168+ messages in thread
From: Richard Underwood @ 2003-08-19 19:00 UTC (permalink / raw)
  To: 'David S. Miller'
  Cc: skraw, willy, alan, carlosev, lamont, davidsen, bloemsaa,
	marcelo, netdev, linux-net, layes, torvalds, linux-kernel

David S. Miller wrote: 
> > 	IP packets you mean? You don't? ;) It would depend on why you're
> > doing it naturally. Mostly, I'd have thought that if a host 
> doesn't have an
> > IP number it doesn't get to use ARP.
> 
> Of course it gets to use ARP, nothing prevents this.
> 
> If I know that IP X has my configuration information, I
> have every right to send X a packet from zero-net to
> ask for that information before I have any IP addresses
> attached to the interface.
> 
	Ick! And how is IP X going to get the information back? Broadcast
it, too? Here was me thinking that protocols like BOOTP and DHCP were
appropriate for this.

	If you are going to send from 0.0.0.0, then I assume there's
something in the ARP standard to say "don't cache this ARP request" - I must
have missed it. If so, that's a special case - no need to spoil things
elsewhere, though.

> Also, when one specifies a specific device in an output
> address and we cannot find the IP part of the address
> in the routing tables, we still procure a valid route for
> the requester.
> 
	Well, what do you do currently? If the packet you're routeing came
from another host, there's no way in hell you can use their IP address in an
ARP request ... is there? I certainly hope you don't go that far!!!

	If it's a locally generated packet, then the next hop must be on the
same subnet as the address it's coming from - there's your IP number.

> Besides normal IP addresses, multicast tools use these
> facilities.
> 
	Multicast uses ARP? That's news to me!

		Richard

^ permalink raw reply	[flat|nested] 168+ messages in thread
[parent not found: <mfYi.374.31@gated-at.bofh.it>]
* RE: [2.4 PATCH] bugfix: ARP respond on all devices
@ 2003-08-19 22:12 Richard Underwood
  2003-08-19 22:11 ` David S. Miller
  0 siblings, 1 reply; 168+ messages in thread
From: Richard Underwood @ 2003-08-19 22:12 UTC (permalink / raw)
  To: 'Alan Cox'
  Cc: 'David S. Miller',
	Stephan von Krawczynski, willy, carlosev, lamont, davidsen,
	bloemsaa, Marcelo Tosatti, netdev, linux-net, layes, torvalds,
	Linux Kernel Mailing List

Alan Cox wrote:
> 
> One thing I agree with you about is that an ARP resolution for an
> address via one path should not block a resolution for it by another
> path since to begin with the two paths may be to different routers
> one of which is down.

Alan,

	I can't believe that you're advocating networking code where:

1) It's not predictable - the route of a packet depends on the ARP reply
generated due to a previous packet.

2) Linux will fail to communicate with the vast majority of routers under
some, fairly basic, conditions.

	I'm certain that Cisco (for example) won't change their ways. I
can't blame them, either - no one else does it this way and there's no good
reason for doing it like this either.

	I think I'm going to give up at this point because I know I'm not
going to get anywhere. A simple static ARP entry will fix my problems,
although I'd prefer a more generic solution.

	Good luck!

		Richard

^ permalink raw reply	[flat|nested] 168+ messages in thread
* RE: [2.4 PATCH] bugfix: ARP respond on all devices
@ 2003-08-20  8:58 Richard Underwood
  2003-08-20 15:23 ` jamal
  0 siblings, 1 reply; 168+ messages in thread
From: Richard Underwood @ 2003-08-20  8:58 UTC (permalink / raw)
  To: 'David S. Miller', Alan Cox
  Cc: skraw, willy, Richard Underwood, carlosev, lamont, davidsen,
	bloemsaa, marcelo, netdev, linux-net, layes, torvalds,
	linux-kernel

David S. Miller wrote:
> 
> Indeed, would people stop quoting from RFC 985 and
> RFC 826.

	In case anyone missed it, the following message was posted to
linux-net and netdev. This is currently a draft standard, but anyone
implementing IPv6 should be following it. It clearly states that the the
source address for the equivalent of the ARP request should be the INTERFACE
address.

	While it doesn't directly apply to IPv4 (except for David's claim
that IPv4 ARP is based on IPv6 ARP) it does clarify the situation nicely.

	I, for one, will be glad when (!) we all migrade to IPv6 and we can
once and all be done with this nonsense, unless Linux plans to deviate from
the standard?

	Thanks,

		Richard

-----Original Message-----
From: Steven Blake [mailto:slblake@petri-meat.com]
Sent: 20 August 2003 05:58
To: David S. Miller
Cc: netdev@oss.sgi.com; linux-net@vger.kernel.org
Subject: Re: [2.4 PATCH] bugfix: ARP respond on all devices


On Tue, 2003-08-19 at 13:53, David S. Miller wrote:

> BTW, this ARP source address algorithm we use comes from
> ipv6, it would be instructive to go and see why they do
> things the way they do.

Are you sure?  See below:

========================================================================

RFC 2461              Neighbor Discovery for IPv6          December 1998


4.3.  Neighbor Solicitation Message Format

   Nodes send Neighbor Solicitations to request the link-layer address
   of a target node while also providing their own link-layer address to
   the target.  Neighbor Solicitations are multicast when the node needs
   to resolve an address and unicast when the node seeks to verify the
   reachability of a neighbor.

         0                   1                   2                   3
         0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        |     Type      |     Code      |          Checksum             |
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        |                           Reserved                            |
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        |                                                               |
        +                                                               +
        |                                                               |
        +                       Target Address                          +
        |                                                               |
        +                                                               +
        |                                                               |
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        |   Options ...
        +-+-+-+-+-+-+-+-+-+-+-+-

   IP Fields:

      Source Address
                     Either an address assigned to the interface from
                     which this message is sent or (if Duplicate Address
                     Detection is in progress [ADDRCONF]) the
                     unspecified address.

      Destination Address
                     Either the solicited-node multicast address
                     corresponding to the target address, or the target
                     address.

      Hop Limit      255

      Authentication Header
                     If a Security Association for the IP Authentication
                     Header exists between the sender and the
                     destination address, then the sender SHOULD include
                     this header.





Narten, et. al.             Standards Track                    [Page 21]

========================================================================


Regards,

// Steve

^ permalink raw reply	[flat|nested] 168+ messages in thread
* RE: [2.4 PATCH] bugfix: ARP respond on all devices
@ 2003-08-20 20:10 Richard Underwood
  0 siblings, 0 replies; 168+ messages in thread
From: Richard Underwood @ 2003-08-20 20:10 UTC (permalink / raw)
  To: 'David S. Miller', Bill Davidsen
  Cc: dang, alan, Richard Underwood, skraw, willy, carlosev, lamont,
	bloemsaa, marcelo, netdev, linux-net, layes, torvalds,
	linux-kernel

David S. Miller wrote:
> 
> BTW, another thing which makes the source address selection for
> outgoing ARPs a real touchy area is the following.  Some weird
> configurations actually respond with different ARP answers based upon
> the source address in the ARP request.  You can ask Julian Anastasov
> about such (arguably pathological) setups.
> 
	*smirk* How horrible. I'm not sure you should be proud of supporting
this, and certainly not proud of only half-supporting it. It wouldn't work
reliably as things are now as packets will always follow the ARP reply
generated by the very first packet.

	If you want to facilitate this sort of network, you'd need to cache
an ARP reply for an IP number against BOTH the Interface AND the interface
address used as the source of the ARP request. Only then could you guarantee
that packets go to the correct IP number out of the correct interface based
on their source address.

		Richard

^ permalink raw reply	[flat|nested] 168+ messages in thread
end of thread, other threads:[~2003-08-23 21:00 UTC | newest]

Thread overview: 168+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2003-07-27 20:52 [2.4 PATCH] bugfix: ARP respond on all devices Bas Bloemsaat
2003-07-27 22:12 ` David S. Miller
2003-07-28  2:31   ` Ben Greear
2003-07-28  7:33     ` Bas Bloemsaat
2003-07-27 23:40 ` Carlos Velasco
2003-07-27 23:46   ` David S. Miller
2003-07-27 23:58     ` Carlos Velasco
2003-07-27 23:58       ` David S. Miller
2003-07-28  0:11         ` Carlos Velasco
2003-07-28  0:14           ` David S. Miller
2003-07-28  0:35             ` Carlos Velasco
2003-07-28  0:36               ` David S. Miller
2003-07-28  0:53                 ` Carlos Velasco
2003-07-28  0:55                   ` David S. Miller
2003-07-28  1:23                     ` Carlos Velasco
2003-07-28  1:35                       ` David S. Miller
2003-07-28 10:43                         ` Carlos Velasco
2003-07-28 17:09                           ` Phil Oester
2003-07-28 18:56                             ` Bas Bloemsaat
2003-07-28  4:37                     ` David Lang
2003-07-28  4:39                       ` David S. Miller
2003-07-28 10:49                       ` Carlos Velasco
2003-07-28  0:57           ` Assorted 2.6.0-test2 build warnings J.C. Wren
2003-07-28 22:11             ` Randy.Dunlap
2003-07-29 10:42               ` Adrian Bunk
2003-07-29  2:51     ` [2.4 PATCH] bugfix: ARP respond on all devices Bill Davidsen
2003-07-29  4:48       ` Lamont Granquist
2003-08-04  6:10         ` Pekka Savola
2003-08-17 13:09         ` Carlos Velasco
2003-08-17 13:16           ` Carlos Velasco
2003-08-17 13:41             ` Alan Cox
2003-08-17 13:55               ` Carlos Velasco
2003-08-17 15:12                 ` Bernd Eckenfels
2003-08-17 15:28                 ` Alan Cox
2003-08-17 15:57                   ` Bas Bloemsaat
2003-08-17 15:59                   ` Carlos Velasco
2003-08-17 16:26                     ` Alan Cox
2003-08-17 16:27                       ` Carlos Velasco
2003-08-17 17:24                         ` Alan Cox
2003-08-17 22:48                           ` Willy Tarreau
2003-08-18  5:22                             ` David S. Miller
2003-08-18  6:56                               ` Willy Tarreau
2003-08-18  7:01                                 ` David S. Miller
2003-08-18  7:29                                   ` Willy Tarreau
2003-08-18  7:43                                     ` Willy Tarreau
2003-08-18  5:31                             ` David S. Miller
2003-08-18 11:39                               ` Stephan von Krawczynski
2003-08-18 11:44                                 ` David S. Miller
2003-08-18 12:34                                   ` Stephan von Krawczynski
2003-08-18 12:30                                     ` David S. Miller
2003-08-18 12:51                                       ` Mr. James W. Laferriere
2003-08-18 12:53                                       ` Stephan von Krawczynski
2003-08-18 12:55                                         ` David S. Miller
2003-08-18 13:17                                           ` Stephan von Krawczynski
2003-08-18 13:14                                             ` David S. Miller
2003-08-18 14:23                                               ` Stephan von Krawczynski
2003-08-18 14:19                                                 ` David S. Miller
2003-08-18 15:46                                                   ` Stephan von Krawczynski
2003-08-18 13:23                                           ` jamal
2003-08-18 13:21                                             ` David S. Miller
2003-08-18 13:40                                               ` Stephan von Krawczynski
2003-08-20  6:55                                             ` Bas Bloemsaat
2003-08-18 21:54                                       ` Bill Davidsen
2003-08-18 13:40                                     ` Dominik Kubla
2003-08-18 12:51                                   ` Willy Tarreau
2003-08-18 12:53                                     ` David S. Miller
2003-08-18 14:28                                       ` Willy Tarreau
2003-08-18 14:28                                         ` David S. Miller
2003-08-18 12:08                                 ` Bas Bloemsaat
2003-08-18 12:03                                   ` David S. Miller
2003-08-18 21:32                               ` Bill Davidsen
2003-08-19  3:21                                 ` Ben Greear
2003-08-19 15:22                                   ` David S. Miller
2003-08-19  7:58                                 ` Bas Bloemsaat
2003-08-18 15:49                         ` SRC IP selection in ARP request (Was: bugfix: ARP respond on all devices) Vladimir B. Savkin
2003-08-17 16:51                     ` [2.4 PATCH] bugfix: ARP respond on all devices David T Hollis
2003-08-17 16:45                       ` Carlos Velasco
2003-08-17 17:13                         ` Arjan van de Ven
2003-08-17 19:46                           ` insecure
2003-08-18  5:11                             ` David S. Miller
2003-08-18  5:29                 ` David S. Miller
2003-08-17 13:59               ` Bas Bloemsaat
2003-08-18 10:48               ` Robert Collier
2003-08-17 13:38           ` Alan Cox
     [not found] <e2Yb.5CB.17@gated-at.bofh.it>
     [not found] ` <e43Y.6x0.17@gated-at.bofh.it>
     [not found]   ` <e43Y.6x0.19@gated-at.bofh.it>
     [not found]     ` <e43Y.6x0.21@gated-at.bofh.it>
     [not found]       ` <e43Y.6x0.23@gated-at.bofh.it>
     [not found]         ` <e43Y.6x0.25@gated-at.bofh.it>
     [not found]           ` <e43Y.6x0.15@gated-at.bofh.it>
     [not found]             ` <e4nd.6K9.5@gated-at.bofh.it>
     [not found]               ` <e4ne.6K9.11@gated-at.bofh.it>
     [not found]                 ` <e4x3.6RV.23@gated-at.bofh.it>
     [not found]                   ` <e4Qe.7cR.3@gated-at.bofh.it>
     [not found]                     ` <e503.7kj.23@gated-at.bofh.it>
     [not found]                       ` <e5jh.7yW.5@gated-at.bofh.it>
     [not found]                         ` <edJU.6nT.25@gated-at.bofh.it>
2003-07-28 20:45                           ` Julien Oster
2003-08-19 12:02 Richard Underwood
2003-08-19 12:35 ` Alan Cox
2003-08-19 18:30   ` Daniel Gryniewicz
2003-08-19 18:29     ` David S. Miller
2003-08-19 19:12       ` Daniel Gryniewicz
2003-08-19 19:10         ` David S. Miller
2003-08-20 16:49         ` Bill Davidsen
2003-08-20 17:00           ` David S. Miller
2003-08-20 17:44             ` Ben Greear
2003-08-20 17:48               ` David S. Miller
2003-08-20 23:18                 ` Julian Anastasov
2003-08-23 20:50                 ` Bill Davidsen
2003-08-20 19:08             ` Bill Davidsen
2003-08-20 20:07               ` Bas Bloemsaat
2003-08-19 19:42       ` bill davidsen
2003-08-19 13:11 ` Bas Bloemsaat
2003-08-19 15:34   ` David S. Miller
2003-08-19 17:39     ` Lars Marowsky-Bree
2003-08-19 17:36       ` David S. Miller
2003-08-19 21:01         ` Harley Stenzel
2003-08-19 16:19   ` Stephan von Krawczynski
2003-08-19 16:54   ` David S. Miller
2003-08-19 17:15     ` Stephan von Krawczynski
2003-08-19 16:56 ` David S. Miller
2003-08-19 14:34 Richard Underwood
2003-08-19 14:54 ` Willy Tarreau
2003-08-19 15:07   ` Stephan von Krawczynski
2003-08-19 15:57     ` David S. Miller
2003-08-19 16:52       ` Stephan von Krawczynski
2003-08-19 16:53         ` David S. Miller
2003-08-19 17:12           ` Stephan von Krawczynski
2003-08-19 17:09             ` David S. Miller
2003-08-19 19:04         ` Alan Cox
2003-08-19 19:01           ` David S. Miller
2003-08-19 19:19             ` Bas Bloemsaat
2003-08-19 19:16               ` David S. Miller
2003-08-20  8:49               ` Roman Pletka
2003-08-20 14:15                 ` Stephan von Krawczynski
2003-08-20 14:43                   ` Roman Pletka
2003-08-20 15:55                     ` Stephan von Krawczynski
2003-08-20 16:47                       ` Roman Pletka
2003-08-19 15:53   ` Bill Davidsen
2003-08-19 16:14     ` David S. Miller
2003-08-19 17:17       ` Bill Davidsen
2003-08-19 19:08 ` Alan Cox
2003-08-19 21:53   ` Stephan von Krawczynski
2003-08-19 16:54 Richard Underwood
2003-08-19 16:51 ` David S. Miller
2003-08-19 17:10   ` Stephan von Krawczynski
2003-08-19 17:07     ` David S. Miller
2003-08-19 19:57       ` bill davidsen
2003-08-19 17:56 Richard Underwood
2003-08-19 17:53 ` David S. Miller
2003-08-19 18:05 Richard Underwood
2003-08-19 18:21 ` David S. Miller
2003-08-20 12:52   ` Harley Stenzel
2003-08-19 18:16 Richard Underwood
2003-08-19 18:13 ` David S. Miller
2003-08-19 18:30   ` Bas Bloemsaat
     [not found] <mdtk.Zy.1@gated-at.bofh.it>
     [not found] ` <mgUv.3Wb.39@gated-at.bofh.it>
     [not found]   ` <mgUv.3Wb.37@gated-at.bofh.it>
     [not found]     ` <miMw.5yo.31@gated-at.bofh.it>
2003-08-19 18:48       ` Andi Kleen
2003-08-19 19:17         ` Daniel Gryniewicz
2003-08-19 19:21           ` Andi Kleen
2003-08-19 19:27             ` Daniel Gryniewicz
2003-08-19 19:24               ` David S. Miller
2003-08-19 19:32               ` Andi Kleen
2003-08-19 19:28                 ` David S. Miller
2003-08-20  9:53                   ` Alan Cox
2003-08-20 15:41                   ` Stephan von Krawczynski
2003-08-20 15:38                     ` David S. Miller
2003-08-19 19:38           ` Valdis.Kletnieks
2003-08-19 19:37             ` David S. Miller
2003-08-19 20:44               ` Valdis.Kletnieks
2003-08-19 19:00 Richard Underwood
2003-08-19 18:58 ` David S. Miller
     [not found] <mfYi.374.31@gated-at.bofh.it>
     [not found] ` <mkbE.6Rk.35@gated-at.bofh.it>
2003-08-19 20:00   ` Andi Kleen
2003-08-19 19:56     ` David S. Miller
2003-08-19 22:12 Richard Underwood
2003-08-19 22:11 ` David S. Miller
2003-08-19 23:15   ` Stephan von Krawczynski
2003-08-20  8:58 Richard Underwood
2003-08-20 15:23 ` jamal
2003-08-20 15:28   ` jamal
2003-08-20 20:10 Richard Underwood

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).