>On Wed, 20 Mar 2013 12:26:04 -0400 >Alexander Spitzer <[email protected]> wrote: > > > Have you tried konqueror from kde or firefox? > > > No, but I've tried python. It can't be the rendering. Running > "urllib.urlopen("http://en.wikipedia.org";)" stalls like in the > browser. Adding a line to /etc/hosts with the wikipedia server's IP > and the same line runs instantaneously. > Running "dig @8.8.8.8 (my configured DNS) en.wikipedia.org" resolves > the name in under 30 ms! So something wierd is happening. I could try > looking into glibc but like you said why would it fail for only some > websites? > > I guess I could install Firefox anyway. What I really want is Google > Chrome but that's going to be a challenge.
Chiming in... >From the description in this thread, the location of the problem is in the DNS resolver. AKA glibc. This hypothesis can be verified by using a different DNS resolver. The easiest way to do this is to put a HTTP proxy with it's own DNS resolver on your system and have the browser use it. You can use Polipo for testing because it is a simple and straightforward proxy. http://www.pps.univ-paris-diderot.fr/~jch/software/polipo/ Now, IF using polipos own DNS resolver makes the problem go away, but configuring polipo to use glibc's DNS resolver makes the problem appear, then you have your diagnosis. The problem then becomes "what is causing glibc to behave like that"? If the Polipo test comes back positive, then I think you should escalate the debugging and - I'm not joking - use tcpdump to sniff your own traffic to see what *exactly* is going on on the wire. I'll guide you through the process, because glibc behaving in this way is untolerable and we must get to the bottom of it, especially if you are willing to put up with the debugging. -- You don't need an AI for a robot uprising. Humans will do just fine. --Skynet -- http://linuxfromscratch.org/mailman/listinfo/blfs-support FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
