Messages in this thread |  | | Date | Tue, 5 Sep 2000 00:52:56 +0000 (GMT) | From | Julian Anastasov <> | Subject | Re: Linux 2.2 - BSD/OS 4.1 ARP incompatibility |
| |
Hello,
On Tue, 5 Sep 2000, David Luyer wrote:
> > > just try "traceroute -s 111.111.111.111 d.e.f.2" > > > What shows this simple test? > > > > arp who-has d.e.f.2 tell a.b.c.1 > > > > or > > > > arp who-has d.e.f.2 tell d.e.f.1 > > When I tried traceroute -s d.e.f.1 d.e.f.2, it worked, the first time the > Linux box in question talked to the BSD/OS in question without the aid of > an extra host spoofing responses to the arp queries in question. > > The command you suggested also had the desired effect. However...
ok
> > # arp -d d.e.f.2 > # traceroute d.e.f.2 > traceroute to d.e.f.2, 30 hops max, 40 byte packets > 1 a.b.c.1 2997 ms !H 2998 ms !H 3000 ms !H
tcpdump binds to another address.
> > (ie, failure by default) > > # traceroute -s d.e.f.1 d.e.f.2 > traceroute to d.e.f.2 from d.e.f.1, 30 hops max, 40 byte packets > 1 d.e.f.2 1 ms 0 ms 0 ms > # traceroute d.e.f.2 > traceroute to d.e.f.2, 30 hops max, 40 byte packets > 1 d.e.f.2 1 ms 0 ms 0 ms > > (success, and success by default once the MAC address is known to the ARP > table) > > # arp -d d.e.f.2 > # traceroute -s 5.5.5.5 d.e.f.2 > 1 * * * > > at this point the tcpdump shows arp requests from d.e.f.1, ie, correct ARP > requests.
ok
> > But straight command line ping and traceroute with no explicit source, and > sockets which are not explicitly bound (eg, standard netkit telnet) are > perhaps being auto-bound or otherwise made to choose a.b.c.1 as their for > arp requests.
Hm, it depends. I don't think socket()+connect() will autobind to a.b.c.1 without bind(). May be there are difficulties for some of the programs to obtain the preferred source address.
> > > If the announced address is d.e.f.1 then there is no problem in > > inet_select_addr() but your application is already bound to the > > primary address. > > It's not in the case of telnet (simple to see by strace), and I expect not > in the case of traceroute with no explicit source either. However, perhaps > the automatic bind is choosing the primary address.
I have such problems (even wrong devices are selected) with tcpdump 3.4 but I have never tested any new versions. May be we have to complain about this default behaviour in tcpdump, i.e. without -i or -s?
> > So if I want it to work I most likely need to make the ARP request ignore > the higher level bindings of the socket.
Isn't that very restrictive? Hm, at first look it seems it is good arp_solicit to use only inet_select_addr. It seems the speed is not a problem. Really, is there any setup that requires each local saddr from the packet to be announced? Someone with good examples that can't work with inet_select_addr?
> > David. > -- > ---------------------------------------------- > David Luyer > Senior Network Engineer > Pacific Internet (Aust) Pty Ltd > Phone: +61 3 9674 7525 > Fax: +61 3 9699 8693 > Mobile: +61 4 1064 2258, +61 4 1114 2258 > http://www.pacific.net.au NASDAQ: PCNTF > << fast 'n easy >> > ----------------------------------------------
Regards
-- Julian Anastasov <ja@ssi.bg>
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org Please read the FAQ at http://www.tux.org/lkml/
|  |