[blfs-support] Unable to load certain websites
aes368 at cornell.edu
Sat Mar 23 17:25:49 PDT 2013
Thanks for your reply. Installing polipo and using its DNS resolver did not
solve the issue but setting dnsQueryIPv6 to false did! Turns out the entire
issue was with IPv6 querying. Now with ipv6 disabled in the kernel
everything loads fine. I should have tried that earlier. I think the ipv6
problem is with my home router setup so when I go back to school I will
reenable ipv6 and see if there is still an issue.
Thanks for everyone's help!
On Sat, Mar 23, 2013 at 6:16 PM, Aleksandar Kuktin <akuktin at gmail.com>wrote:
> >On Wed, 20 Mar 2013 12:26:04 -0400
> >Alexander Spitzer <aes368 at cornell.edu> 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 @126.96.36.199 (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.
> 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.
> FAQ: http://www.linuxfromscratch.org/blfs/faq.html
> Unsubscribe: See the above information page
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the blfs-support