Ask Your Question

Intel wireless chipset + ipv6 = no google

asked 2015-01-02 12:08:19 -0500

dustin gravatar image

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.

edit retag flag offensive close merge delete


If you disable IPv4 and use only IPv6 with your wireless card, does the problem with Google persist?

bitwiseoperator gravatar imagebitwiseoperator ( 2015-01-03 15:07:16 -0500 )edit

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 80 (sorry,!). Then the Intel firmware crashed and stopped sending any packets over a few hundred bytes. After a restart, I can't reproduce with the nc command anymore.

dustin gravatar imagedustin ( 2015-01-03 15:34:35 -0500 )edit

@bitwiseoperator, I don't see a sysctl to disable IPv4. Hints?

dustin gravatar imagedustin ( 2015-01-03 15:36:42 -0500 )edit

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?

bitwiseoperator gravatar imagebitwiseoperator ( 2015-01-03 16:36:26 -0500 )edit

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).

dustin gravatar imagedustin ( 2015-01-03 18:19:35 -0500 )edit

1 Answer

Sort by ยป oldest newest most voted

answered 2015-01-03 18:29:21 -0500

updated 2015-01-03 18:30:18 -0500

According to RFC 2460, IPv6 requires that every link on the Internet be capable of supporting a minimum MTU of 1280, so you should be able to safely set that as your MTU and resolve the matter.

edit flag offensive delete link more


Setting MTU and disabling IPv6 are workarounds, not solutions, so I haven't accepted this answer.

dustin gravatar imagedustin ( 2015-01-04 17:14:17 -0500 )edit

Well, I promoted it to the answer status 'cause I figured this MTU adjustment based on IPv6 standards is a reasonable resolution as far as the Fedora community is concerned since the maintenance of the driver bothering you is an Intel/kernel issue. You should definitely report your problems at the kernel Bugzilla, but in the meanwhile, this seems to me a reasonable conclusion on the board. I'm open to disagreement, so the answer is here for your acceptance if you choose to do so. If not, no worries.

bitwiseoperator gravatar imagebitwiseoperator ( 2015-01-05 13:47:39 -0500 )edit

It's a good answer, just not to this problem (it's based on a misunderstanding as discussed in comments on the question)

dustin gravatar imagedustin ( 2015-01-05 15:26:20 -0500 )edit

Question Tools

1 follower


Asked: 2015-01-02 12:08:19 -0500

Seen: 220 times

Last updated: Jan 02 '15