Print

[jimb]

Anyone else notice this?

Basically, the scenario is I take a win7 laptop to my non-IPv6 work network, then when I leave I suspend win7.  Come back to my IPv6 enabled WLAN, but the win7 box seems to refuse to hear RA announcements.  It never gets another IPv6 address.

I tried all sorts of things to make it work.  ipconfig /renew6, netsh int ipv6 set routerdiscovery=disable then enable.  It'd never get a new IPv6 address.  Only thing that makes it work is disabling and enabling the interface.  Kind of annoying.

Mebbe I should file a bug w/ MS?

[cholzhauer]

hmm.  before i got my network a home ipv6 enabled i could boot my laptop at home, hibernate it, power up at work, and i was able to connect via ipv6 with no problem.  you mentioned a lot of things you tried, but i didnt remember seeing reboot?

[jimb]

Reboot would fix it of course.  Hibernate too since it's powering everything down completely.  It's suspend/resume that seems to have issues.  Interface comes back up but seems to ignore RAs and never gets an IPv6 address.

As I said, disable/enableing the interface and voila, it picks up RA.  Basically the interface has to be stopped and restarted to make it happy.  Not sure if it's consistent either.

[cholzhauer]

Interesting.  I'll have to try it and see what my results are.

[rwg]

I tried all sorts of things to make it work.  ipconfig /renew6, netsh int ipv6 set routerdiscovery=disable then enable.  It'd never get a new IPv6 address.  Only thing that makes it work is disabling and enabling the interface.

It sounds like your wireless NIC loses the contents of its multicast filter when going to sleep and the driver doesn't restore the filter's contents upon resume, causing it to stop passing multicast packets up to Windows.  Since ICMPv6 router advertisements are multicast, the card drops those packets on the floor, and Windows never sees them.  Bouncing the interface makes the driver reinitialize the card like it would on power-up (or upon resume from hibernation), so the multicast filter gets programmed correctly.

A way to test my theory would be to install a packet sniffer that allows you to sniff packets without switching the interface into promiscuous mode.  If you resume the laptop and IPv6 is broken, fire up the packet sniffer, make it listen for ICMPv6 packets on the wireless interface without switching the interface into promiscuous mode, and see if the sniffer can see the router advertisements.  If you don't see RAs, then the card is dropping those packets before the OS ever sees them.

Alternatively, use the packet sniffer and let it set your wireless interface to promiscuous mode.  If IPv6 magically starts working while the sniffer is capturing packets (and stops working shortly after you stop the sniffer and the card gets taken back out of promiscuous mode), then it's probably the same problem.

I don't use Windows enough to know what packet sniffers would work for this.  Wireshark would probably work.  It looks like there's a Windows port of tcpdump (WinDump), as well -- something like tcpdump -i wlan0 -s0 -n -p -v icmp6 is what I'd use on Unix.

If it looks like the card is dropping multicast frames after a resume, then it's not Windows's fault, it's the wireless card's driver's fault.  Try updating to a newer driver or complaining to whoever wrote the driver.

[jimb]

Yeah that seems a likely enough scenario.  I'll have to try that next time it happens.  I have wireshark on here.  I don't think you can use winpcap + wifi interface in promiscuous mode anyway.  Whenever I've tried it, it receives no traffic.

I'm pretty sure I have the latest drivers since this is a new laptop and I've updated everything when I did my install.  The NIC is an
"Intel(R) Centrino(R) Advanced-N 6200 AGN" connected to a 11N access point.

It's a fairly minor problem, but somewhat annoying.

[nicoschrootenDV]

you could try and play with the energy settings of the NIC. i have seen this happening before.

[tthhaa]

I experience the same or a similar issue with Windows 7: the IPv6 address on the wireless *and* lan interface stay in "discarded" state after resuming from standby. The IPv6 address is properly set and used while doing suspend/resume over a lunch break. The IPv6 addresses remain in discarded stae while doing suspend/resume over night.

I can see the icmp6 RA announcemens in Wirehshark in non-promiscious and proimiscous mode. The addresses did not recovered after switching to promiscous mode. I am not aware of any cure apart from reboot.

The router is running OpenWRT 10.03.1-rc4, radvd 1.6

radvdump reports:

AdvSendAdvert on;
AdvManagedFlag off;
AdvOtherConfigFlag off;
AdvReachableTime 0;
AdvRetransTimer 0;
AdvCurHopLimit 64;
AdvDefaultLifetime 1800;
AdvHomeAgentFlag off;
AdvDefaultPreference medium;
AdvSourceLLAddress on;

prefix 2001:470:***/64
{
   AdvValidLifetime 86400;
   AdvPreferredLifetime 14400;
   AdvOnLink on;
   AdvAutonomous on;
   AdvRouterAddr off;
};

RDNSS fe80::***
{
   AdvRDNSSPreference 8;
   AdvRDNSSOpen off;
   AdvRDNSSLifetime 600;
};

[jmv]

Right click the networking notification icon

Troubleshoot problems

Different problem

Specific adapter

Your adaper will get reset

this works

[tthhaa]

Thanks. It did not work. The two 2001:470:* addresses remain in discarded state even after going through troebleshooting the device.

Any idea of the cause?

[jmv]

Try this in radvd:


AdvValidLifetime 86400;
AdvPreferredLifetime 86400;

Working for me. (This time I promise)

[ChrisClyde]

Same thing happens to me,Even gone through the tutorial but it didn't help.

[cconn]

its a known bug.  Informal sources claim it will be fixed via regular hotfix sometime in august.

http://forums.whirlpool.net.au/forum-replies.cfm?t=1648260&p=28#r542

It has to do with the fact that when Win7 deprecates a prefix, even if it starts seeing RAs on the interface with that same prefix, it does not "un-"deprecate it.