Lindsay Haisley <[email protected]> posted [email protected], excerpted below, on Fri, 15 May 2009 22:02:15 -0500:
> I'm having some problems reaching *.python.org with web browers here, > and the problem appears to be related to ipv6 issues. My desktop system > is connected to a Linux router which has an assigned /64 v6 block from > freenet6. Firefox defaults to using ipv6 if there's an AAAA record for > an address. This isn't a problem in most cases. > > If I access most v6 enabled web servers, e.g. www.kame.net or > testmyipv6.com with firefox, no problem. I get back a page indicating > that I"ve made a v6 connection to the web server. www.python.org also > resolves with an aaaa record (2001:888:2000:d::a2), and I can ping6 the > server, so I know that routing is OK. I can't, however, get a response > from the server with a firefox, which just blocks trying to retrieve a > page. Disclaimer: Note that I'm still entirely IPv4 and the following suggestions, based on IPv4, simply assume IPv6 versions of the same thing exist and work similarly. In addition to Tom's suggestion, I'd add trying a(n IPv6) telnet session to the web server as well. Very basic, just open the connection, then type quit if you get one. You can of course do a get, etc, if desired, but it's often not necessary or helpful. Sometimes the "raw" interface is helpful at diagnosing errors that get hidden by the fancy browser interface and that's all it takes. If you get a proper telnet connection that equally properly quits when told to, you're most of the way there already. What about tcptraceroute? The manpages don't seem to indicate tcptraceroute itself does IPv6, but standard traceroute does with -6, and has -T to use TCP SYN packets for tracing (with -p to specify port number). A run using TCP packets on the target port, contrasted with a normal traceroute run (and contrasted further with a traceroute -I, ICMP run, if desired), can be VERY helpful. Another nice thing about it is that it usually allows seeing hops behind firewalls, since they obviously must allow TCP SYN packets thru to that port or the web server wouldn't work. If ping and a normal trace (the IPv6 versions in this case) are getting thru but a tcptraceroute to the assigned port isn't, you know it's a TCP specific issue and at what layer-4/IP hop it's happening. mtr is IPv6 enabled (USE flag) and can be helpful for certain diagnostics as well, altho it tends to be most useful at detecting levels of packet loss and where, due to its continuous tracing functionality. -- Duncan - List replies preferred. No HTML msgs. "Every nonfree program has a lord, a master -- and if you use the program, he is your master." Richard Stallman
