DragonFlyBSD

:Hi,
:
:Yesterday everthing works like a charm. Then, today in a different
:network, Thunderbird, Firefox3 and ssh seems to
:need around a minute to connect (resolve DNS or load a page, don't
:know exactly), while w3m (text browser) doesn't show
:any of the problems (it immediatly shows the page). ping does work of
:course too. Could that be related to threading issues?
:
:The only difference to yesterday (where everything worked perfectly)
:is that today I use bge0 instead of rum0.
:I'll try it later in an again different network where I can both test
:bge0 and rum0.
:
:Regards,
:
: Michael

Try turning off any automatic checksumming features on the interface.

What you are describing typically occurs when a network interface
    starts dropping or mis-checksumming certain packets.

Other possibilities include: long or fragmented packets being
    improperly blocked or erroring out.

-Matt
                    Matthew Dillon 
                    <dillon@backplane.com>

Hm, it's very strange. "w3m" (a text browser) actually works like hell,
while "fetch" doesn't work. When I open the same page (your Hammer patch
diff for example) in w3m, it appears immediatly, while when I try to
fetch it with "fetch", it gets stuck in

#fetch -v http://apollo.backplane.com/DFlyMisc/hammer02.patch
   looking up apollo.backplane.com

and nothing further happens. So it seems to be a DNS problem.
But I thought they all are using the same resolver library.

Works:

ping
   w3m
   dig

Hangs:

fetch
   firefox
   thunderbird
   ssh

This only happens in this local net here, regarless whether I use the
wireless card or the built in ethernet. Other operating systems work
fine (I tried FreeBSD and MacOSX).

Any further hints what this could be?

Regards,

Michael

: #fetch -v http://apollo.backplane.com/DFlyMisc/hammer02.patch
: looking up apollo.backplane.com
:
:and nothing further happens. So it seems to be a DNS problem.
:But I thought they all are using the same resolver library.

As far as I can tell my DNS is working.  You could try ktracing
     the fetch to see where it's stalling, and tcpdump to trace the DNS
     queries.  Also check your resolv.conf and so on and so forth.

Other common foulups including broken dns search paths specified
     in resolv.conf, network routing and/or port issues, etc.

-Matt

Does fetch -4 work?

Joerg

Yes it does! You found the problem!

So in Firefox/Thunderbird I have to use the following line and
everything works out well:

user_pref("network.dns.disableIPv6", true);

Thanks a lot!

Regards,

Michael

Well, you should now check why you have a ipv6 route or why AAAA records
are slow.

Joerg