Hi Mikael,
On Wed, Jan 18, 2006 at 09:03:59PM +0100, Mikael Nilsson wrote: > > > Anything else that might help? In any case, the link local address does > > > *not* end up in resolv.conf. > > > > > > Actually, putting it there manually makes address lookup work again :-) > > > > Okay, that is weird. > > Is it? Just to be sure there is no misunderstanding, I added the address > 169.254.141.11 as nameserver to resolv.conf. This is the link local > address of the *router* and also the address reported in the error > message by 'host': > > ;; reply from unexpected source: 169.254.141.11#53, expected > 192.168.0.254#53 Yes basically, it indicates that your sending packets from 169.254.0.0/16 which you should be preferring your other addresses. > So I assumed that if it *expected* a reply from that address, everything > would work. And it did. I found it somewhat logical (even though it was > not logical that it didn't work in the first place). Are the below tcpdump's with or without the link-local address in resolv.conf? > > If you can could you send the output of, with and without zeronconf: > > > > an strace of 'host debian.org' > > a tcpdump during the same time > > Without zeroconf > > # tcpdump -n > tcpdump: verbose output suppressed, use -v or -vv for full protocol decode > listening on eth0, link-type EN10MB (Ethernet), capture size 96 bytes > 20:46:44.244848 IP 192.168.0.1.32825 > 192.168.0.254.53: 8639+ A? > debian.org. (28) > 20:46:44.266689 IP 192.168.0.254.53 > 192.168.0.1.32825: 8639 1/4/1 A > 192.25.206.10 (143) > 20:46:44.268119 IP 192.168.0.1.32826 > 192.168.0.254.53: 19688+ AAAA? > debian.org. (28) > 20:46:44.282645 IP 192.168.0.254.53 > 192.168.0.1.32826: 19688 0/1/0 (82) > 20:46:44.346739 IP 192.168.0.1.32826 > 192.168.0.254.53: 20742+ MX? > debian.org. (28) > 20:46:44.347355 IP 192.168.0.254.53 > 192.168.0.1.32826: 20742 0/0/0 (28) > > 6 packets captured > 12 packets received by filter > 0 packets dropped by kernel > > With zeroconf: > > # tcpdump -n > tcpdump: verbose output suppressed, use -v or -vv for full protocol decode > listening on eth0, link-type EN10MB (Ethernet), capture size 96 bytes > 20:59:06.337636 IP 169.254.253.111.32828 > 192.168.0.254.53: 25013+ A? > debian.org. (28) > 20:59:06.356490 IP 169.254.141.11.53 > 169.254.253.111.32828: 25013 1/4/1 A > 192.25.206.10 (143) > 20:59:11.338797 IP 169.254.253.111.32828 > 192.168.0.254.53: 25013+ A? > debian.org. (28) > 20:59:11.357116 IP 169.254.141.11.53 > 169.254.253.111.32828: 25013 1/4/1 A > 192.25.206.10 (143) > > 4 packets captured > 8 packets received by filter > 0 packets dropped by kernel > > So there we are, it sends from 169.254.253.111. Why, oh why? Very strange! Just to confirm, in the second tcpdump there was *no* 169.254.0.0/16 address in resolv.conf? >From the output it looks like 'host' just does a bind to the interface and lets the kernel select the outgoing address. Which means that zeroconf has to indicate to the kernel that it is only to be used as a secondary address, or unless specifically required. Thanks for your feedback so far, they should allow me to fix this problem shortly. Anand -- `When any government, or any church for that matter, undertakes to say to its subjects, "This you may not read, this you must not see, this you are forbidden to know," the end result is tyranny and oppression no matter how holy the motives' -- Robert A Heinlein, "If this goes on --" -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
