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/
This archive was generated by hypermail 2b29 : Thu Sep 07 2000 - 21:00:20 EST