The linux implementation of ARP is causing me problems. Linux sends out an
ARP request with the default interface as the sender address, rather than then
interface the request came on.
For example
eth0 10.1.1.100
eth0:1 192.16.1.101
and an ARP is received on 192.16.1.101, linux responds with
10.1.1.100 as the source address in the ARP request, rather than 192.16.1.101
(which FreeBSD, Solaris, and tru64 do). To me, this is just plain wrong.
The sender address should be an address on the subnet that the request came
from, not a different one. Is there any way to fix this?
Andy
On Thu, Sep 05, 2002 at 10:09:50AM -0500, Andrew Ryan wrote:
> The linux implementation of ARP is causing me problems. Linux sends out an
> ARP request with the default interface as the sender address, rather than then
> interface the request came on.
http://www.rfc-editor.org/rfc/std/std37.txt
> For example
>
> eth0 10.1.1.100
> eth0:1 192.16.1.101
Are you really expect an aliased interface to work the way you described?
> and an ARP is received on 192.16.1.101, linux responds with
> 10.1.1.100 as the source address in the ARP request, rather than 192.16.1.101
> (which FreeBSD, Solaris, and tru64 do). To me, this is just plain wrong.
> The sender address should be an address on the subnet that the request came
> from, not a different one. Is there any way to fix this?
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On donderdag, september 5, 2002, at 05:34 , Alex Riesen wrote:
> On Thu, Sep 05, 2002 at 10:09:50AM -0500, Andrew Ryan wrote:
>> The linux implementation of ARP is causing me problems. Linux sends
>> out an
>> ARP request with the default interface as the sender address, rather
>> than then
>> interface the request came on.
>
> http://www.rfc-editor.org/rfc/std/std37.txt
>
>> For example
>>
>> eth0 10.1.1.100
>> eth0:1 192.16.1.101
>
> Are you really expect an aliased interface to work the way you
> described?
if I read this version of the internet standard correctly, it should
respond with the ip address that was requested:
"It then notices that it is a request, so it swaps fields, putting
EA(Y) in the new sender Ethernet address field (ar$sha), sets the
opcode to reply, and sends the packet directly (not broadcast) to
EA(X)."
Meaning that the reply must come from the ip-address that was beeing
looked for in the first place, not just any address used on that
interface. Though at the time of writing this was not something that was
in use at all I guess.
So yes, I think it is reasonable to assume that if I do an arp request
for one address, I do not get a reply for another address that happens
to be on the same interface... There is no way of determining that this
is indeed the address I was looking for in the first place. I have not
checked to see if Linux does this, but if it does it is plain wrong...
- ---
Met vriendelijke groeten,
Remco Post
SARA - Stichting Academisch Rekencentrum Amsterdam http://www.sara.nl
High Performance Computing Tel. +31 20 592 8008 Fax. +31 20 668 3167
PGP keys at http://home.sara.nl/~remco/keys.asc
"I really didn't foresee the Internet. But then, neither did the computer
industry. Not that that tells us very much of course - the computer
industry
didn't even foresee that the century was going to end." -- Douglas Adams
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.7 (Darwin)
iD8DBQE9d4DTBIoCv9yTlOwRAm1zAJ9DyuMA3RlAFYZeJkulWYOFPPrFZwCdGIHx
pIvaA6utByxRaHKq58JdTso=
=jsvP
-----END PGP SIGNATURE-----
Andrew Ryan wrote:
>
> The linux implementation of ARP is causing me problems. Linux sends out an
> ARP request with the default interface as the sender address, rather than then
> interface the request came on.
>
> For example
>
> eth0 10.1.1.100
> eth0:1 192.16.1.101
>
> and an ARP is received on 192.16.1.101, linux responds with
> 10.1.1.100 as the source address in the ARP request, rather than 192.16.1.101
> (which FreeBSD, Solaris, and tru64 do). To me, this is just plain wrong.
> The sender address should be an address on the subnet that the request came
> from, not a different one. Is there any way to fix this?
I'm not sure how you're managing to get that behaviour. I just reproduced the scenario on a 2.2.17
kernel and logged the output. 47.129.82.232 is configured as eth0:0, with 47.129.82.53 being eth0,
and pcary1ja maps to 47.129.82.54.
08:04:59.650707 eth0 > 0:0:0:0:0:0 0:30:65:a0:ff:c6 arp 42: arp who-has 47.129.82.232 tell pcary1ja
(0:30:65:a0:ff:c6)
0001 0800 0604 0001 0030 65a0 ffc6 2f81
5236 0000 0000 0000 2f81 52e8
08:04:59.650707 eth0 < 0:30:65:c0:23:c4 0:0:0:0:0:1 arp 64: arp reply 47.129.82.232 is-at
0:30:65:c0:23:c4 (0:30:65:a0:ff:c6)
0001 0800 0604 0002 0030 65c0 23c4 2f81
52e8 0030 65a0 ffc6 2f81 5236 5555 5555
5555 5555 5555 5555 5555 5555 5555 e796
9051
As you can see, the reply is properly sent out with the source IP address of 47.129.82.232.
Are you sure you aren't misreading something? If you change the source IP address then the arp
reply is totally useless as it is a reply to another request entirely.
Chris