can't open Facebook

Forums › 2degrees (including Slingshot, Orcon, Flip, Stuff Fibre, MyRepublic, 2talk and Vocus) › can't open Facebook

livealittle

75 posts

Master Geek

#204897 21-Oct-2016 18:59

Have just noticed that on my wifi network (2 degress UFB with friztbox 7360) that on both my macbook using safari and on the samsung galaxy ph I can't seem to open Facebook.com.

Noticed this first on my ph last night and didn't think much of it until I tried on my macbook and same issue. Tried on google chrome and same issue.

On my ph if I use data I can access so it has to be something to do with my 2 degrees connection/setting

Does anyone have any suggestions?

Thanks

cynnicallemon

370 posts

Ultimate Geek

#1655946 21-Oct-2016 19:24

Not being able to open Facebook... seems like a win.

tdgeek

29753 posts

Uber Geek

Trusted

Lifetime subscriber

#1655966 21-Oct-2016 20:40

cynnicallemon:

Not being able to open Facebook... seems like a win.

You got that right! Cant access Facebook or there American election, bugger!

richms

28198 posts

Uber Geek

Trusted

Lifetime subscriber

#1655975 21-Oct-2016 21:29

Turn off IPv6 if its on. Used to get erratic facebook all the time before I gave up on it.

Richard rich.ms

SCM

459 posts

Ultimate Geek

#1656441 23-Oct-2016 08:23

richms:

Turn off IPv6 if its on. Used to get erratic facebook all the time before I gave up on it.

This.

2degrees have an ongoing issue with IPv6 and Facebook/Google, an issue that's been around from the snap days and an issue they seem not to be doing anything to resolve in a hurry.

fe31nz

1233 posts

Uber Geek

#1656772 24-Oct-2016 00:56

The issue is not with just Facebook - it is an IPv6 MTU problem and will affect any IPv6 connection where full size packets get sent. Facebook just happens to be a popular site that is fully IPv6 compatible and uses long packets just about as soon as you access it, so it makes a good test for this problem. I had this same problem with my EdgeRouter Lite, before I worked out how to fix it. What happens with IPv6 is that the protocol requires that MTU path discovery works. In IPv4 MTU path discovery is optional as packets can be automatically fragmented if they are too big to fit down one part of the path between the ends of an IP connection. In IPv6, no fragmentation is possible. See here for an explanation of MTU path discovery:

https://en.wikipedia.org/wiki/Path_MTU_Discovery

If MTU path discovery is not working, then packets get sent that are too long to pass through one segment of the path to the other end. Such packets get dropped when they reach that point in their journey. If MTU path discovery was working properly, the maximum length of the packets would have been set lower at the point of transmission, so they would fit down that narrower bit of the path. But for some reason, the router that is running that bit of the path is not responding to the MTU discovery packets that were sent before the connection was made, and normally that also means that when that router drops the packets, it does so silently instead of sending an ICMPv6 reply saying it dropped the packets. So the sending end never knows the packets were dropped, and thinks they just were damaged or missing for some other reason, and keeps resending them, without altering their size. And they keep getting dropped, until the connection times out.

The next part of the puzzle is that the connection from the FritzBox (or whatever router you are using to connect to 2Degrees) is via a PPPoE connection on VLAN 10. Note the PPPoE. PPPoE is a protocol (used here for authentication), and it has its own headers in the packets, which get added on to the size of the exisiting packets. So if your connection to 2Degrees is MTU 1500, and you are sending MTU 1500 packets, the PPPoE headers increase the size of the packet on that connection to 1508 bytes, which is bigger than can be sent over the physical connection of MTU 1500. So those packets get dropped (IPv6) or fragmented (IPv4).

See here for more about PPPoE:

https://en.wikipedia.org/wiki/Point-to-point_protocol_over_Ethernet

Now, if the 2Degrees routers had a proper implementation of PPPoE, when overlong packets got dropped, or when MTU discovery packets were seen, the PPPoE firmware should actually reply and tell your router the maximum safe MTU value it should be using. But they do not do this! Overlong IPv6 packets are dropped silently by the PPPoE firmware, and MTU discovery packets are ignored.

There are two fixes for this problem. The first is to change the IPv6 MTU value being used on your network to reduce it by 8 bytes. That is initially what I did with my ERLite. The normal way that is done is to get the router to send out its Router Advertisment (RA) packets with an optional section telling any IPv6 device connecting to the network about the reduced MTU value. I do not know if the FritzBox can be set to do this or not. This fix also has the problem that the reduced MTU value is not just used for Internet connections (where it is necessary), but also for traffic internal to your local network. That reduces the maximum throughput of your internal network IPv6 connections a little.

The second fix is the much better. Chorus (and I presume all the other fibre network operators) have the fibre network set up "overprovisioned", in order to fix this problem. The actual MTU available on the fibre is 1508, not 1500. So if your router is able to use a extention of the PPPoE protocol it can ask for the full 1508 byte MTU when it connects. Then the PPPoE overhead just uses the extra 8 bytes, and the standard 1500 byte IPv6 packets are passed through without any problems.

When I first met this problem with my ERLite, I tried to set up the 1508 byte PPPoE connection, but it did not work. So I used the reduced IPv6 MTU option for a while, until one day I saw that the router had been disconnected and had automatically reconnected again. That normally does not happen with my 2Degrees fibre connection - it only happens when they do some serious maintenance that they can not do any other way. So I checked the PPPoE log from my ERLite, and noticed that the MAC address of the 2Degrees router I was connecting to had changed. Including a change in the top bytes that tell which manufacturer assigned the MAC address from their assigned MAC address blocks. So 2Degrees had replaced that router with a new one, of a different brand. Ever hopeful, I changed my PPPoE settings to use a 1508 MTU again, and it worked!

My understanding is that if you are using a FritzBox with reasonably up to date firmware, then it will automatically do the PPPoE overprovisioning request. It is possible that the FritzBox has an option somewhere to allow or prevent that, but if you have not been fiddling with the settings and 2Degrees set it up in the first place, it should work correctly and allow 1508 byte PPPoE packets if the router you are connected to allows that option.

So, if you are using a 2Degrees configured FritzBox, and are having this IPv6 problem, then it is 2Degrees causing it - either they have not configured your FritzBox correctly, or the router on their network your FritzBox is connecting to is not allowing the overprovisioning and is also not responding to MTU path discovery. Hence, you need to call them and get them to fix it. Please feel free to reference this post to them, to explain the problem.

The above applies to fibre connections, but I believe PPPoE is also used on VDSL connections, and the same scenario could well apply there also.

scottjpalmer

5973 posts

Uber Geek

Moderator

ID Verified

Trusted

Lifetime subscriber

#1656787 24-Oct-2016 08:28

Great explanation thanks.

I'm not having any issues FYI, supplied Fritz 7490.

Lorenceo

904 posts

Ultimate Geek

Trusted

#1656820 24-Oct-2016 10:27

I've run into the IPv6 MTU issue as well. Have set it to 1492 (after working with the CFW devs to pinpoint the issue, still defaulted to 1500 for quite a while due to a bug), along with TCP MSS. Haven't had any trouble with IPv6 since.

Not using the Fritzbox to terminate the PPP, for what it's worth. It's just acting as an ATA.

Would really like it if there was no need for PPPoE at all and 2Degrees allowed lines to auth over DHCP/IPoE as well.

Quic Broadband

Move to New Zealand's best fibre broadband service (affiliate link). Free setup code: R587125ERQ6VE. Note that to use Quic Broadband you must be comfortable with configuring your own router.

2degreesCare

1537 posts

Uber Geek

Trusted

2degrees

#1657588 25-Oct-2016 17:34

Hi Everyone,

We have had a look in to this, and haven't found any apparent issues on our side.

If you are affected by this, instead of disabling IPv6, please message us with details, including your broadband customer number, the behaviour you are experiencing, your connection type and your location, so that we can collate information to aid further investigation.

Disabling IPv6 can cause other issues in the longer run, so it's better to investigate and remedy than to just disable.

Thanks,

Ralph ^JOB

SCM

459 posts

Ultimate Geek

#1657913 26-Oct-2016 09:13

2degreesCare:

Hi Everyone,

We have had a look in to this, and haven't found any apparent issues on our side.

If you are affected by this, instead of disabling IPv6, please message us with details, including your broadband customer number, the behaviour you are experiencing, your connection type and your location, so that we can collate information to aid further investigation.

Disabling IPv6 can cause other issues in the longer run, so it's better to investigate and remedy than to just disable.

Thanks,

Ralph ^JOB

I have provided this info several times over the last 3 years with no fix or apparent action on a fix in sight..

This issue is ongoing from your Snap days..

Your front line staff, several times now, blame Facebook/Google and just brush the issue off.

2degreesCare

1537 posts

Uber Geek

Trusted

2degrees

#1657981 26-Oct-2016 10:01

SCM:

I have provided this info several times over the last 3 years with no fix or apparent action on a fix in sight..

This issue is ongoing from your Snap days..

Your front line staff, several times now, blame Facebook/Google and just brush the issue off.

Hio SCM,

There have been a number of improvements to our IPv6 implementation over that period of time, and we have not been aware of any wide spread issues with it for quite some time. In fact, the vast majority of our customers are currently online with IPv6 and report no problems with accessing IPv6 content.

If you are experiencing issues, they need to be investigated and isolated.

Thanks,

Ralph ^JOB