David S. Miller wrote:
quoted
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
quoted
"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
On Tue, 19 Aug 2003 18:56:18 +0100
Richard Underwood [off-list ref] 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?
Linux allows that, and in fact it's a useful feature.
Consider MSG_DONTROUTE as well.
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.
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