Curious why more people haven't reported this. Is it card related? Network related? Is IPV6 on for everyone, but for some reason it's not causing everyone a problem?
Personally, I would like to see an option in the setup for whether you want to enable IPV6 or not, with the default being Not. At least, until IPV6 becomes a reality for mainstream users.
I noticed that we are both on comcast. I didn't play around with nslookup or dig, but perhaps comcast' dns servers are actually returning IPV6 addresses for some hosts. If we're getting v6 addresses, but can't connect to them because we haven't got a tunnel set up, it would explain the delays, as it attempts a v6 connection, fails, then falls back to v4.
brian
On Fri, Mar 05, 2004 at 04:02:11PM -0800, Brian Krahmer wrote:
Personally, I would like to see an option in the setup for whether you want to enable IPV6 or not, with the default being Not. At least, until IPV6 becomes a reality for mainstream users.
I beg to differ, the default should be on.
I noticed that we are both on comcast. I didn't play around with nslookup or dig, but perhaps comcast' dns servers are actually returning IPV6 addresses for some hosts. If we're getting v6 addresses, but can't connect to them because we haven't got a tunnel set up, it would explain the delays, as it attempts a v6 connection, fails, then falls back to v4.
There should be no delays. If IPv6 is enabled for the interfaces, there are two options (currently):
- default route via stateless autoconfig (router advertisement) - static default route
So unless you _have_ IPv6 outside connectivity (either by some router on your LAN advertising a default route to your host or by yourself configuring a static IPv6 default route), there is no default route and any attempt to connect to an IPv6 address outside your local LAN will _immediately_ result in a "no route to host" and thus a failure. Without noticable delay.
Guys... VARs are today shipping even laptops with Windows XP with IPv6 enabled by default.
If someone has long timeout delays, there is something misconfigured... e.g. a static default to a nonexistant default router. THIS needs to be fixed.
Regards, Daniel
Daniel Roesen wrote:
So unless you _have_ IPv6 outside connectivity (either by some router on your LAN advertising a default route to your host or by yourself configuring a static IPv6 default route), there is no default route and any attempt to connect to an IPv6 address outside your local LAN will _immediately_ result in a "no route to host" and thus a failure. Without noticable delay.
If someone has long timeout delays, there is something misconfigured... e.g. a static default to a nonexistant default router. THIS needs to be fixed.
Here's the output from a dnslookup, ifconfig, and 'netstat -rn' on my box, with just IPV4 configured followed by the IPV6 results (as setup by the Fedora install):
IPV4:
0.000000 192.168.0.100 -> 68.54.80.5 DNS Standard query A www.google.com 0.011393 68.54.80.5 -> 192.168.0.100 DNS Standard query response CNAME www.g oogle.akadns.net A 216.239.39.147 A 216.239.39.104 A 216.239.39.99
eth0 Link encap:Ethernet HWaddr 00:01:03:C1:D1:BE inet addr:192.168.0.100 Bcast:192.168.0.255 Mask:255.255.255.0 inet6 addr: fe80::201:3ff:fec1:d1be/64 Scope:Link UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:51 errors:0 dropped:0 overruns:0 frame:0 TX packets:51 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:9416 (9.1 Kb) TX bytes:4229 (4.1 Kb) Interrupt:10 Base address:0xd400
Kernel IP routing table Destination Gateway Genmask Flags MSS Window irtt Iface 192.168.0.0 0.0.0.0 255.255.255.0 U 0 0 0 eth0 127.0.0.0 0.0.0.0 255.0.0.0 U 0 0 0 lo 0.0.0.0 192.168.0.1 0.0.0.0 UG 0 0 0 eth0
And here's the IPV6 version: 0.000000 192.168.0.100 -> 68.54.80.5 DNS Standard query AAAA www.google.com 5.000097 192.168.0.100 -> 68.54.80.5 DNS Standard query AAAA www.google.com 5.010537 68.54.80.5 -> 192.168.0.100 DNS Standard query response CNAME www.g oogle.akadns.net 5.010918 192.168.0.100 -> 68.54.80.5 DNS Standard query A www.google.com 5.024892 68.54.80.5 -> 192.168.0.100 DNS Standard query response CNAME www.g oogle.akadns.net A 216.239.39.104 A 216.239.39.99 A 216.239.39.147 5.025460 192.168.0.100 -> 68.54.80.5 DNS Standard query PTR 104.39.239.216.i n-addr.arpa 10.025349 192.168.0.100 -> 68.54.80.5 DNS Standard query PTR 104.39.239.216.i n-addr.arpa 10.039552 68.54.80.5 -> 192.168.0.100 DNS Standard query response, No such na me 10.039963 192.168.0.100 -> 68.54.80.5 DNS Standard query AAAA www.google.com 10.050470 68.54.80.5 -> 192.168.0.100 DNS Standard query response CNAME www.g oogle.akadns.net 10.051063 192.168.0.100 -> 68.54.80.5 DNS Standard query PTR 99.39.239.216.in -addr.arpa 15.050580 192.168.0.100 -> 68.54.80.5 DNS Standard query PTR 99.39.239.216.in -addr.arpa
(that was from loading http://www.google.com Note the AAAA responses)
eth0 Link encap:Ethernet HWaddr 00:01:03:C1:D1:BE inet addr:192.168.0.100 Bcast:192.168.0.255 Mask:255.255.255.0 inet6 addr: fe80::201:3ff:fec1:d1be/64 Scope:Link UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:123 errors:0 dropped:0 overruns:0 frame:0 TX packets:163 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:68112 (66.5 Kb) TX bytes:17927 (17.5 Kb) Interrupt:10 Base address:0xd400
Kernel IP routing table Destination Gateway Genmask Flags MSS Window irtt Iface 192.168.0.0 0.0.0.0 255.255.255.0 U 0 0 0 eth0 127.0.0.0 0.0.0.0 255.0.0.0 U 0 0 0 lo 0.0.0.0 192.168.0.1 0.0.0.0 UG 0 0 0 eth0
Routing looks the same in either case. /etc/resolv.conf is the same for both, namely this:
; generated by /sbin/dhclient-script nameserver 68.54.80.5
If there's something else in the config that's needed, without shutting off ipv6, that'd be fine. I just wanted to get my net connection working the way it should, and turning ipv6 off did the trick. .Any other tests or suggestions?
Thanks, randy
On Sat, Mar 06, 2004 at 03:10:42PM -0500, Randy Schrickel wrote:
Here's the output from a dnslookup, ifconfig, and 'netstat -rn' on my box, with just IPV4 configured followed by the IPV6 results (as setup by the Fedora install):
Who is doing the DNS lookup?
eth0 Link encap:Ethernet HWaddr 00:01:03:C1:D1:BE inet addr:192.168.0.100 Bcast:192.168.0.255 Mask:255.255.255.0 inet6 addr: fe80::201:3ff:fec1:d1be/64 Scope:Link
As you can see, IPv6 is enabled in the kernel. Otherwise you would have no inet6 link-local addr.
Please show "ip addr show dev eth0" to make sure we have all the info.
Kernel IP routing table
With "netstat -rn" you look up only IPv4 routes. Use "netstat -A inet6 -rn" or (much better): "ip -6 route".
And here's the IPV6 version: 0.000000 192.168.0.100 -> 68.54.80.5 DNS Standard query AAAA www.google.com
68.54.80.5 is being asked for AAAA RR but gives no reply. Retry:
5.000097 192.168.0.100 -> 68.54.80.5 DNS Standard query AAAA www.google.com 5.010537 68.54.80.5 -> 192.168.0.100 DNS Standard query response CNAME www.g oogle.akadns.net
Now it answers with the CNAME. I'm seeing the same effect from here:
; <<>> DiG 9.2.3 <<>> www.google.com AAAA [...] ;; ANSWER SECTION: www.google.com. 3600 IN CNAME www.google.akadns.net. [...] ;; Query time: 4727 msec
Why the resolver doesn't do an AAAA query for www.google.akadns.net. consequently, is beyond me. Looks like a bug.
Instead of following the CNAME, it asks for an A RR:
5.010918 192.168.0.100 -> 68.54.80.5 DNS Standard query A www.google.com 5.024892 68.54.80.5 -> 192.168.0.100 DNS Standard query response CNAME www.g oogle.akadns.net A 216.239.39.104 A 216.239.39.99 A 216.239.39.147
There, Akamai's DNS servers answer directly with A RRs for the CNAME.
5.025460 192.168.0.100 -> 68.54.80.5 DNS Standard query PTR 104.39.239.216.in-addr.arpa 10.025349 192.168.0.100 -> 68.54.80.5 DNS Standard query PTR 104.39.239.216.in-addr.arpa 10.039552 68.54.80.5 -> 192.168.0.100 DNS Standard query response, No such name
Interesting. Same "no response to first query" problem on a simple PTR query. Nothing IPv6 specific here.
10.039963 192.168.0.100 -> 68.54.80.5 DNS Standard query AAAA www.google.com 10.050470 68.54.80.5 -> 192.168.0.100 DNS Standard query response CNAME www.g oogle.akadns.net
This one goes quickly... 68.54.80.5 has the answer cached.
(that was from loading http://www.google.com Note the AAAA responses)
There are ne AAAA responses, but only a CNAME.
Actually, I see nothing going wrong IPv6-specific. There are two pretty normal IPv4 DNS queries not being answered - one of them even asking for a normal PTR RR, not even AAAA.
This will be probably tricky to debug properly.
Are those two different installations? Or how do you toggle "IPv6 enabled" (whatever that actually means - as both systems are obviously IPv6 enabled per se).
IPv6 transport is not involved, but pls show "ip -6 route" anyway.
If there's something else in the config that's needed, without shutting off ipv6, that'd be fine. I just wanted to get my net connection working the way it should, and turning ipv6 off did the trick. .Any other tests or suggestions?
Currently, it looks like 68.54.80.5 or your network's NAT is misbehaving somehow. What kind of device is doing the NAT?
Best regards, Daniel
Daniel Roesen wrote:
Please show "ip addr show dev eth0" to make sure we have all the info.
I'm at work now, no access to the machine having the problem. So I'll skip over all the command output you asked for right now. I can do those from home later today, but I'll answer the questions that don't need access to the machine.
Are those two different installations? Or how do you toggle "IPv6 enabled" (whatever that actually means - as both systems are obviously IPv6 enabled per se).
It's a single installation. FC1 worked fine, the Win XP side when I dual boot works fine. I "disable IPv6" by adding the line
alias net-pf-10 off
to my /etc/modprobe.conf file as mentioned earlier in this thread.
My original issue was incredibly slow DNS. Looking at things across systems with ethereal showed those multiple AAAA messages. That lead me to wondering if it was something strange going on with ipv6 on my machine, so I wanted to "turn it off" as a test. Adding that line to the file did "turn it off", and DNS was fine.
Currently, it looks like 68.54.80.5 or your network's NAT is misbehaving somehow. What kind of device is doing the NAT?
It's a D-Link wireless access point (but the machine in question isn't wireless). I get the same result whether I point my DNS to the d-link (as dhcp configures it) or if I point it to the upstream comcast address.
Thanks for the input Daniel.
randy
On Mon, Mar 08, 2004 at 06:26:35AM -0500, Randy L Schrickel wrote:
It's a single installation. FC1 worked fine, the Win XP side when I dual boot works fine. I "disable IPv6" by adding the line
alias net-pf-10 off
to my /etc/modprobe.conf file as mentioned earlier in this thread.
Well, but your second ifconfig output shows clearly, that there is an IPv6 link-local address assigned to eth0, which happens only if the IPv6 kernel module gets loaded. So in fact, your box _was_ IPv6 enabled in both cases.
Best regards, Daniel
Daniel Roesen wrote:
Well, but your second ifconfig output shows clearly, that there is an IPv6 link-local address assigned to eth0, which happens only if the IPv6 kernel module gets loaded. So in fact, your box _was_ IPv6 enabled in both cases.
Oops. Nope, that was just a bad cut and paste job on my part. The inet6 addresses definitely don't show up when I do the ifconfig with the ipv6 "disabled". My mistake. Will try it again tonight, correctly. I think it looks the same, except no inet6 addr. Sorry for the misleading info!
randy
Daniel Roesen wrote:
Try: ip -6 route del default dev eth0
and try wether you still get those timeouts.
Ok, I did that. Hmmmm, interesting....
nslookup www.google.com
159.905296 192.168.0.100 -> 68.54.80.5 DNS Standard query A www.google.com 164.906050 192.168.0.100 -> 68.54.80.5 DNS Standard query A www.google.com 164.918972 68.54.80.5 -> 192.168.0.100 DNS Standard query response CNAME www.google.akadns.net A 64.233.161.104 A 64.233.161.99
nslookup www.amazon.com199.788366 192.168.0.100 -> 68.54.80.5 DNS Standard query A www.amazon.com 199.800101 68.54.80.5 -> 192.168.0.100 DNS Standard query response A 207.171.185.16
Definitely makes a difference for some (most?) web pages, but not all. cnn.com for instance took minutes to load, and spewed out hundreds of dns lines in my ethereal trace.
lynx www.google.com
620.363071 192.168.0.100 -> 68.54.80.5 DNS Standard query AAAA www.google.com 620.374913 68.54.80.5 -> 192.168.0.100 DNS Standard query response CNAME www.google.akadns.net 620.392936 192.168.0.100 -> 68.54.80.5 DNS Standard query A www.google.com 620.405477 68.54.80.5 -> 192.168.0.100 DNS Standard query response CNAME www.google.akadns.net A 216.239.37.147 A 216.239.37.104 A 216.239.37.99 620.430031 192.168.0.100 -> 68.54.80.5 DNS Standard query AAAA www.google.com 625.432955 192.168.0.100 -> 68.54.80.5 DNS Standard query AAAA www.google.com 625.445163 68.54.80.5 -> 192.168.0.100 DNS Standard query response CNAME www.google.akadns.net 625.445556 192.168.0.100 -> 68.54.80.5 DNS Standard query A www.google.com 625.469632 68.54.80.5 -> 192.168.0.100 DNS Standard query response CNAME www.google.akadns.net A 216.239.37.99 A 216.239.37.147 A 216.239.37.104
Removing that default route certainly has an effect - but it doesn't seem to be a consistent one. Does that output help?
(really appreciate you (daniel) and whoever else actually takes the time to look at this!)
Thanks, randy
On Tue, Mar 09, 2004 at 10:23:04PM -0500, Randy Schrickel wrote:
Removing that default route certainly has an effect - but it doesn't seem to be a consistent one. Does that output help?
Not really. There seems to be a certain pattern that always the first query to a certain name server may time out. Are you sure that the v6 default route _really_ makes a difference, or is that just coincidence? Can you reproduce results by re-adding the default etc?
I seriously have not the slightest clue why v6 should make ANY difference, given that all I'm ssing from these outputs is pure IPv4 stuff. And it's not some antipathy of your ISP's DNS cache against AAAA RRs as (if I'm not mistaken) even A RR requests timed out.
One serious problem with debugging is that your ISP's cache might be the problem, or the remote nameservers. Your box only qeries the ISP cache, but we have no clue what THIS one does with your query in order to deliver results.
Can you try installing a local BIND as local cache and use 127.0.0.1 as resolver in /etc/resolv.conf, and try that?
Best regards, Daniel
Daniel Roesen wrote:
Not really. There seems to be a certain pattern that always the first query to a certain name server may time out. Are you sure that the v6 default route _really_ makes a difference, or is that just coincidence? Can you reproduce results by re-adding the default etc?
I can try re-adding the default.
I seriously have not the slightest clue why v6 should make ANY difference, given that all I'm ssing from these outputs is pure IPv4 stuff. And it's not some antipathy of your ISP's DNS cache against AAAA RRs as (if I'm not mistaken) even A RR requests timed out.
Me either. This is my first experience with v6. It just showed up as the only noticeable difference, and taking it out fixed the problem.
Can you try installing a local BIND as local cache and use 127.0.0.1 as resolver in /etc/resolv.conf, and try that?
Haven't done that before, but I can give it a try.
randy
Randy Schrickel wrote:
(really appreciate you (daniel) and whoever else actually takes the time to look at this!)
It's been a couple weeks, and I'm still playing with this, so I thought I'd post my latest news (solution?). Someone (thanks Ricky) emailed me a nice link for testing "internet speed" that should be pretty DNS intensive - http://www.numion.com/YourSpeed . Even though my last fix seemed to help, that website told me I was only getting about 30-50 kbps download speeds. The same machine, dual booted into Windows XP Pro came out about 350kbps!
So I finally did something tonight I've been thinking of - unplugging my "wireless broadband router" (a D-Link DI-614+) and plugging the cable modem directly into the PC. It's been cabled to the D-Link, not wireless on this machine. Wow. My speed to that site now came up between 400 and 500 kbps! Cool. Except my wife wouldn't be happy with no wireless to the other PC, so this won't do.
I decided to flash upgrade the router bios to see if that makes a difference. So I did that, and re-connected to the router. Now I'm getting at least 350kbps! Current bios version is "2.20, Tue 19 Aug 2003" and I've got kernel 2.6.3-2.1.253. I also wrote to D-Link's tech support, and they suggested that I change the 614's MTU to 1492. I haven't tried that, but I'm not sure it will help any more - from what I've read, that value should be used for DSL (PPoE).
I haven't tried it yet with "ipv6 enabled" to see if that original setting makes any difference at all now. Interestingly, I found this link http://www.experts-exchange.com/Networking/Linux_Networking/Q_20868797.html which talks about the same problem I've described only with Mandrake. Their solution - disable ipv6, just like I'd done before!
Sorry for the long posting, but I like to be complete. ;) I'll probably post my results again after I re-enable ipv6.
Thanks to all who have helped and offered suggestions.
randy
Randy Schrickel wrote:
http://www.experts-exchange.com/Networking/Linux_Networking/Q_20868797.html which talks about the same problem I've described only with Mandrake. Their solution - disable ipv6, just like I'd done before!
Minor correction, that link refers to the same issue with SUSE, not Mandrake.
randy
Randy Schrickel wrote:
http://www.experts-exchange.com/Networking/Linux_Networking/Q_20868797.html which talks about the same problem I've described only with Mandrake. Their solution - disable ipv6, just like I'd done before!
Rebooted with ipv6 enabled, looks like the speed is still right up there. Not as good as without the D-Link, but it's usable now.
randy
Randy Schrickel wrote, On 03/26/2004 11:03 PM:
Randy Schrickel wrote:
http://www.experts-exchange.com/Networking/Linux_Networking/Q_20868797.html which talks about the same problem I've described only with Mandrake. Their solution - disable ipv6, just like I'd done before!
Rebooted with ipv6 enabled, looks like the speed is still right up there. Not as good as without the D-Link, but it's usable now.
randy
Randy, Sorry to contact you at home but not sure if you are still monitoring this list.
Was wondering if upgrading your D-Link unit still looks like the right solution for you, even with ipv6 re-enabled. Any idea why XP was getting good results with the original d-link firmware while fc2 did not?
I don't have a D-link router but a homebrew Bering-Leaf router (LRP) on a old PC. It contains a program called dnscache which I use as my dns server. It works a lot faster when ipv6 is disabled in fc2t2 and I might need to find out if it can be upgraded to handle the AAAA record better too, like possibly your d-link now does.
Just thought I'd ask.
Tks, -gene
* Brian Krahmer (brian@krahmer.com) [040306 06:39]:
From: "Brian Krahmer" brian@krahmer.com To: "Fedora (E-mail)" fedora-test-list@redhat.com Subject: Re: disable IPV6? Message-ID: 000c01c4030e$49050df0$0200a8c0@WARHOLE X-Mailer: Microsoft Outlook CWS, Build 9.0.6604 (9.0.2911.0) Reply-To: fedora-test-list@redhat.com Date: Fri, 5 Mar 2004 16:02:11 -0800
Curious why more people haven't reported this. Is it card related? Network related? Is IPV6 on for everyone, but for some reason it's not causing everyone a problem?
Personally, I would like to see an option in the setup for whether you want to enable IPV6 or not, with the default being Not. At least, until IPV6 becomes a reality for mainstream users.
I noticed that we are both on comcast. I didn't play around with nslookup or dig, but perhaps comcast' dns servers are actually returning IPV6 addresses for some hosts. If we're getting v6 addresses, but can't connect to them because we haven't got a tunnel set up, it would explain the delays, as it attempts a v6 connection, fails, then falls back to v4.
brian
-- fedora-test-list mailing list fedora-test-list@redhat.com To unsubscribe: http://www.redhat.com/mailman/listinfo/fedora-test-list
I've found that ad.doubleclick.net does not properly handle AAAA queries. The progressively longer timeouts occur until the maximum number arrive, and the requestor shrugs and continues in ipv4. The problem is actually with doubleclick. If they'd just fix their DNS...
-
Brian Krahmer -
Daniel Roesen -
Derek Tattersall -
Gene Smith -
Randy L Schrickel