Intel wireless chipset + ipv6 = no google
I have a Intel(R) Centrino(R) Advanced-N 6235 AGN, REV=0xB0 freshly installed in an Intel nuc. I also have a dual-stack network with IPv4 and IPv6 running. The dual-stack has been problem-free for years.
All Google properties are slow to load and often fail. Everything else (IPv4) works fine, and simple stuff like pinging v6 addresses works fine. If I disable ipv6 with sysctl net.ipv6.conf.wlp2s0.disable_ipv6=1, Google properties work fine.
Circumstantially, it looks like this wireless chipset doesn't work well with the IPv6 traffic to Google. It's likely that Google is the only site with which I have a lot of v6 communication.
I don't see anything suspicious in the kernel logs, although my notion of "suspsicious" may not be very well-developed. I've tried setting the iwlwifi swcrypto=1 and 11n_disable=1 options, with no success. I've tried dialing back the interface MTU, also without effect.
I'm not sure how to continue debugging this.
If you disable IPv4 and use only IPv6 with your wireless card, does the problem with Google persist?
Well, I have a little more data. Running tcpdump to capture tra IPv6 traffic, I see that my host sometimes ignores the "Packet too big" ICMPv6 messages it gets. These are used to indicate that the sender should use a smaller packet size (1280 in my case, to fit in the GRE tunnel to Hurricane Electric).
I say "sometimes" because I managed to replicate this first with my browser, then with
dd if=/dev/zero | nc -v arin.net 80(sorry, arin.net!). Then the Intel firmware crashed and stopped sending any packets over a few hundred bytes. After a restart, I can't reproduce with thenccommand anymore.@bitwiseoperator, I don't see a sysctl to disable IPv4. Hints?
I was just thinking you'd remove the IPv4 configuration for the NIC and thereby force it to use IPv6 only, just to eliminate a variable in the problem. Looks like your tcpdump diagnostic activity has revealed the issue, though. Can you not simply adjust the MTU for your NIC to force it to send properly-sized packets?
No, because there might be network elements on down the line with a smaller MTU. I suspect that the ignored ICMPv6 messages are a symptom of a larger problem (presumably in the firmware, since it later crashed).