Can't get an IPV6 ip address with any 802.11g adaptor

I've recently been going dual stack with IPV4 and IPV6 where possible since my isp supports ipv6rd, as does my router - an Asus RT-N56U on firmware 3.0.0.4.374_979 (which is the latest at the time I asked this question). Some of my systems arn't picking up an ipv6 address, and the only common thread I can find is they're all using 802.11g to connect. So far, I've tested a Thinkpad R60 on xubuntu 13.04 and lubuntu 13.04 and 13.10 with intel 3945 abg and and a Thinkpad R61 on windows 7 with an intel 3495 abg and a WUSB54G v4. I believe there's a second R61 that dosen't have an ipv6 address either running XP, but I haven't checked closely to see if its enabled. The R60 connects to ipv6 fine on a wired connection. IPV4 works fine in all cases.

On the other hand, all my other systems that are connected over 802.11n, using ralink, intel or broadcom nics work fine with ipv6, getting a proper ipv6 address automatically with no additional setup. I believe I'm using ipv6 router advertisement (or whatever the default automagical ipv6 setup method is)

As such I've ruled out being the OS (I've tried two different ones, and ipv6 works on a wired connection) drivers or network stacks (since the OSes would use fundamentally different drivers) as well as hardware (tested two different laptops with two different network cards). I'm stumped.

Is there some fundamental incompatibility with ipv6 and 802.11g hardware? How would I troubleshoot this?

For completeness' sake, these are the router side ipv6 settings

enter image description here

EDIT As advised by the comments, I tried setting the router to legacy mode - my 802.11 n gear is still in ipv6, and the windows 7/R60 system is not. This is rather curious, and rules out the protocol alone.

Update 2: Tested pinging 224.0.0.1 on 3 systems and 4 NICs

+--------------------+----------------+----------------------+--------------+---------------------------------------------------+--+
|       System       |      NIC       |         OS           | IPV6 Working |                  Ping 224.0.0.1                   |  |
+--------------------+----------------+----------------------+--------------+---------------------------------------------------+--+
| X220               | Intel N1000    | Windows 7 64 bit     | Yes          | 100% loss "PING: transmit failed.General failure" |  |
| R61                | Intel 3945 abg | Windows 7 32 bit     | No           | 100% loss "Request timed out"                     |  |
| R61                | Intel WUSB54G  | Windows 7 32 bit     | No           | 100% loss "Request timed out"                     |  |
| Asus P8z77 Desktop | Ralink AR9845  | Windows 8.1 64 bit   | Yes          | 100% loss "Request timed out"                     |  |
| Asus P8z77 Desktop | Ralink AR9845  | Kubuntu 13.04 64 bit | Yes          | 100% loss - no error message until ctrl-c         |  |
| Router             | -              | -                    | -            | 100% packet loss no error message                 |  |
+--------------------+----------------+----------------------+--------------+---------------------------------------------------+--+

Update 3: I did a minor change to my network, and added a second router to my network , my trusty old DDWRT, set up as a pure access point, and set as a DHCP forwarder. IPV6 works perfectly there. While this dosen't fix my initial issue, I ought to be able to get data off the same system on a lan where it dosen't work.

I do believe we can rule out the protocol - might be a router issue instead.

Journeyman Geek

Posted 2013-11-17T07:02:00.670

Reputation: 119 122

There's no difference. This is most likely a firmware bug in your router. I've run IPv6 over 802.11g for years. – Michael Hampton – 2013-11-18T00:57:57.787

That seems plausible, but a ipv6 capable router is one of the few things I can't swap out for testing. – Journeyman Geek – 2013-11-18T02:56:27.203

Put some OpenWRT on that thing. – Michael Hampton – 2013-11-18T02:57:06.450

Not supported, as far as I can tell and other than this, the stock firmware is pretty good. I'll end up testing this with my old router (a wrt54gl) once I have it reflashed with something suitable, and I can schedule some downtime to poke at this. – Journeyman Geek – 2013-11-18T03:01:10.413

Have you tried setting you router to 802.11g only? That way if the systems who could handle 802.11n/IPV6 before, still get IPV6 over 802.11g you know it's a problem with the older 802.11g adapters. (and that IPV6 works over 802.11g for your router) – Rik – 2013-11-18T08:51:53.090

Set it to legacy, and my 802.11n gear still has ipv6 and my 802.11g gear is still on ipv4. Curious – Journeyman Geek – 2013-11-18T10:04:19.957

Strange ;) I know you tried the R60 on cable but have you also tried if the R61 (with windows 7) has IPV6 directly connected to the cable? If it does have IPV6 on cable you could try the WUSB54G on one of the working (ipv6) machines to see if it's definitively a driver/adapter issue. – Rik – 2013-11-18T10:46:05.110

I need to. I can try the wusb54G on one of the systems where ipv6 works on wireless - it dualboots windows and kubuntu. At this rate I'll need a table for the combinations I tested! They're in physically distinct locations and all the systems that are problematic are older and have dead batteries, so might take a while to test – Journeyman Geek – 2013-11-18T11:20:00.160

Can the G client in question successfully receive multicasts -- even IPv4 multicasts -- over its 802.11g interface? For example, go to another machine on the same wireless network, and ping 224.0.0.1 (that's the "All Hosts" IPv4 multicast address), and see if you get a ping response back from the IPv4 address of the 802.11g client that has the problem. (1/2) – Spiff – 2013-11-19T01:45:57.550

(2/2) I suspect your G client isn't receiving multicasts successfully, and this is causing a problem for IPv6 neighbor discovery and router advertisement/discovery. Because of 802.11 protocol details, when multicast breaks, it usually only breaks in the AP-to-client direction, not in the client-to-AP direction, so be sure to test the correct direction. – Spiff – 2013-11-19T01:47:37.700

I've tried the test and updated my question. I need to try a few more systems since the output seems inconsistent. – Journeyman Geek – 2013-11-19T02:21:02.730

Didn't know you could ping 'multicast'. But all my Windows machines couldn't do it (and don't respond to it). My Linux machines did get a response from other Linux machines with the ping 224.0.0.1 but no response from my Win7 (with native IPV6 and IPV4). @JourneymanGeek Do the 11g adapters just don't get any IPV6-address or do they get an IPV6 but just don't work? You might want to show the ipconfig /all from one of the adapters. I have two very old 11g adapter here, and both get IPV6 (but i'm on native IPV6). (I take it IPV6 is checked as protocol in the adapter ;) – Rik – 2013-11-19T12:33:29.820

Yep. ping on Windows doesn't work with multicast addresses. That's because it discards broadcast pings. Also see this question on Server Fault: broadcast ping on windows LAN. So ping 224.0.0.1 does not work on/to Windows-machines.

– Rik – 2013-11-19T12:46:47.223

They just have a link local address. I'm waiting on a 802.11n usb adaptor to double confirm and will be trying my desktop on linux (where IPV6 works), and the R60 (its in a room where we have guests, so I need to get it out to test properly) later. IPV6 is enabled on the R61, and it has a teredo and a link local interface – Journeyman Geek – 2013-11-19T13:23:50.267

On linux, they seem to have 100% packet loss as well – Journeyman Geek – 2013-11-19T13:32:46.967

I don't think you would need the Teredo and ISATAP adapters anymore (they are hidden devices) (here they are removed). As it stands your router should provide "native/emulated" IPv6 support. Teredo is used to give a single machine IPv6 access behind a IPv4 NAT router. And ISATAP provides IPv6 emulation over IPv4 infrastructure. See here. But that shouldn't be the cause, because you have IPv6 connectivity 'on the wire'. (1/2)

– Rik – 2013-11-19T13:59:57.400

(2/2) To disable Teredo do netsh interface teredo set state disabled. To disable ISATAP do netsh interface ipv6 isatap set state state=disabled. To disable 6to4 do netsh interface ipv6 6to4 set state state=disabled undoonstop=disabled. But again, this should not be a necessity at this moment. (On the other hand.... if the 11g drivers favor the Teredo over the WiFi link it could be the cause :/) – Rik – 2013-11-19T14:00:29.323

I'll try that. Dosen't explain the linux system that I first noticed this problem on however. I need to update the chart with that but I don't have access to the system at the moment. I've disabled ISATAP and teredo and its still not working on the R61. Tried disabling them, no difference there. – Journeyman Geek – 2013-11-19T14:07:22.157

Ok. You can leave them disabled then because with what you are implementing they are not needed anymore locally on the systems (because IPv6 will be supported through the router.) Now we need to find a way to "debug" dhcp on those machines. You could try setting a static IPv6 number, dns and gateway (check the other systems for those) to see if traffic does flow through the adapters (and that it's just a dhcp matter) (testing it with a ping -6 ipv6.google.com). – Rik – 2013-11-19T14:17:52.667

Looking at the x220, it has all that enabled, and I didn't have an issue, I'll leave them off, but thats not likely to be the issue. I'll probably try setting them statically in the morning. DNS and Gateway is a non issue, but ip addresses look scary. – Journeyman Geek – 2013-11-19T14:25:31.247

@Rik IPv6 hosts don't usually use DHCPv6 to get their IPv6 addresses. They usually use IPv6's StateLess Address AutoConfiguration (SLAAC); they get the local IPv6 prefix via IPv6 router discovery, and then set the lowest 64 bits by deriving an address from their MAC address. – Spiff – 2013-11-19T20:48:04.930

@JourneymanGeek Hrm, based on your ping results, I think maybe Windows in general doesn't like the all-hosts multicast address (or maybe you have a firewall enabled on your Windows hosts that's blocking response to multicast pings?). We might need to come up with a different test for whether AP-to-client multicasts are working for your problem client. Perhaps try (again from another wireless machine and not the problem client) pinging the subnet broadcast address? For example, if you're on 192.168.1.0/24, ping 192.168.1.255. – Spiff – 2013-11-19T20:54:16.257

Or run a packet capture tool in non-promiscuous mode on the client with the problem, and see if you capture any multicast or broadcast packets from other devices on the network. – Spiff – 2013-11-19T20:55:27.277

@Spiff I mentioned a few comments back that ping on Windows doesn't work with multicast addresses. Do you have a working Windows environment where this does work? Capturing the traffic with something like wireshark should work better. – Rik – 2013-11-19T21:03:26.940

I haven't had luck from the linux install on my desktop (where ipv6 works) with multicast pings either. I have 2 systems where this works, both running 11n adaptors. – Journeyman Geek – 2013-11-20T00:06:18.450

With wireshark, what sort of filters should I be looking at? – Journeyman Geek – 2013-11-20T00:11:51.193

Ideally you would start with filter ipv6 to see if you get chatter via IPv6 on your adapter. Look for Neighbor Advertisements on fe80::.... Here is a good (7 part) article about "IPv6 multicast background traffic". But if you don't get multicast chatter you might want to see if IPv4 gives you multicasts. (at least from what i've learned the last 2 days ;)

– Rik – 2013-11-20T09:41:20.290

@JourneymanGeek Did you check for the new firmware for the RT-N56U? There are some updates (2013.08.12, 2013.08.20 and latest is 2013.10.11). Some of the changes are fixes to the DHCP for IPv6. It would still be weird 11n can get IPv6 over WiFi and 11g not, but maybe it's something they fixed in the latest firmware. (We should have checked this right at the beginning ;)

– Rik – 2013-11-27T11:06:30.327

I'm on the latest as far as the router seems to be aware. I'm on 3.0.0.4.374_979, which is the latest. I'm planning on spending a weekend or two hacking on this in mid-late december after my exams. I'm also waiting on a 802.11n dongle so I have more datapoints, and so I can sit in range of either AP and run more tests. – Journeyman Geek – 2013-11-27T11:15:23.030

Can't get an IPV6 ip address with any 802.11g adaptor

Answers