Our IPv6 story continues. We removed our Asus RT-N66U router and showed that the problem (long periods of dropped IPv6 connectivity) was not in the Asus device. The problem continued when we went back to the Comcast/Cisco DPC 3941T router, alone. The Comcast device has very poor facilities for diagnosing network problems or anything that might confuse the general Comcast users. It gives a log that says there were some problems seen by the firewall and that's about it.
So we put the Asus device back in operation, switching the Cisco to bridge mode. The Asus demonstrated the same IPv6 problems as before, but now it was time to scrutinize the log a little better.
We noticed a lot of ICMPv6 checksum errors like the following:
Jan 20 10:20:35 kernel: nf_ct_icmpv6: ICMPv6 checksum failed
Jan 20 10:20:35 kernel: <0>nf_ct_icmpv6: ICMPv6 checksum failed
Jan 20 10:20:35 kernel: IN= OUT= <1>SRC=ff02:0000:0000:0000:0000:0001:ff6e:d2d3 DST=2601:0183:4002:0987:0000:0000:0000:0001 <1>LEN=64 TC=0 HOPLIMIT=255 FLOWLBL=0 PROTO=ICMPv6 TYPE=136 CODE=0 1>1>0>
They repeat up to once a second, when they start coming. All the erroneous packets originated from the ...d2d3 address. With a little work, we found...
The Guilty Party
The Amazon Fire tablet seemed like a good value at its ~$50 price. Unfortunately, it appears to be sending the malformed IPv6 packets. Powering off the Fire (or using airplane mode) cuts the errors, and seems to have stabilized the network.
Kindle's version of Android gives you very little to adjust, and you can't shut off v6. We tried unloading most of the non-Amazon apps just in case one of them was causing the problem, but that had no effect.
Maybe $50 is just too cheap? That would be one moral of this story.
Another moral: Don't expect a Comcast router to help you fix your network if something goes wrong.
No comments:
Post a Comment