When 6to4 ipv6 is enabled, facebook mobile does not fully load all videos and pictures (IOS and Android)
-
Hm any idea? Don't know where to look at. Ping from WAN interface is ok, Ping from LAN interface gets the packetloss.
-
Ok I’m home now. On my WiFi connected iPhone I have an ipv6 address. I pass online ipv6 tests just like before. So far the Facebook mobile app is responsive and everything is loading (videos and pictures when clicking on them to make them full size).
I’ve only browsed for a few minutes and I didn’t break out the android yet, but so far so good! We may be onto something that lets me have my ipv6 and Facebook mobile at the same time!
Thanks for your contribution. I would be curious as to the technical reason why, and if Netgate plans to make this fix permanent without a patch. If I update pfsense do I need to reapply? There is a 2.4.3-1 update available that I did not do yet.
-
Spoke too soon, not fixed. Maybe a little better but I just found a bunch of videos in the Facebook mobile app that will not play. I got one to play 10 seconds than it froze indefinitely. Now I’m encountering many videos where I see the first frame and it just spins and spins. If I turn off WiFi and go out AT&T it works fine, so it’s not the phone.
Is the 1280 we put in counting overhead, or should I try entering 1232?
-
Without the patch the advertised MTU is that of the underlying interface, usually 1500. IPv6 is supposed to then figure out the true MTU on its own, but in reality this doesn't seem to work in all cases, especially if the IPv6 is tunneled like it is with 6to4 and 6rd. I don't know where the problem really lies.
So the patch tells the clients just to use the smallest allowable IPv6 MTU of 1280, which I believe is the default MTU of 6rd, and based your ping tests of 6to4 too.
If you select Auto Apply your patch will survive updates, unless the file in question changes too much for the patch to be applied cleanly.
It would be convenient if we could set the MTU ourselves in the Router Advertisements settings.
As I was writing this I see you wrote that your problem might not be fixed, which is too bad. 1280 is the smallest allowable MTU for IPv6, and I think is correct for you since a ping payload of 1232 + 8 bytes of ping packet overhead + 40 bytes of IPv6 addressing overhead is 1280.
-
Having written that, I find MTU and MSS confusing and am not an expert, so I could be completely wrong.
-
Ok I changed it to 1232 in your patch and applied it. In the RA tab under DHCPv6 area I set it to disabled, applied then back to assisted. Still have the problem. I then tried stateless dhcp as the RA mode, everything else is default on that screen.
Turned off WiFi and turned it back on. Tried same video that was stuck and now it’s playing. So I think I need to do more testing and play with the various settings. I have two ipv6 addresses on my phone, a link local and the public one that my ISP assigns.
-
I spoke too soon. That video plays now but I scrolled down and the next one was stalled. I disabled ipv6 on wan and lan, went back to Facebook mobile app and the video began playing instantly.
I’m at a loss. If I get time later maybe I will log a putty session running tcpdump on ipv6 traffic when trying to replicate the problem.
-
I think the RA mode you probably want is Unmanaged.
-
@kjstech I think we've the same issues. Try a IPv6 ping. After heavy using IPv6 (Google maps, Youtube, Facebook) my IPv6 connection gets worse and worse. Reboot pfSense oder restart the WAN interface helps and the connection is fine for some moments again.
-
Hi Just an update. Updated pfSense to 2.4.4 and I'm trying ipv6 again. I'm hoping that in this new version that ipv6 issues have been resolved.
So far so good, but time will tell.
-
I know this is old but even on 2.4.4-p2 ipv6 only works for about 1 to 2 days and then all Facebook videos stop loading until I turn ipv6 off. I guess I will just have to give up on ipv6 with my ISP.
