[gentoo-desktop] Re: python.org and ipv6

[Duncan]

Lindsay Haisley <fmouse-gentoo@×××.com> posted
1242442935.27501.113.camel@××××××××××.com, 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