Hello,

In the past, some people reported problems connecting to the main FPC website or the main SVN repository. Typical symptoms were empty HTML pages, but pinging to the server working fine.

The reason for this - which has been given often - was the atypical window size of the router in front of the server: Some ISP's routers or network configuration could not cope with this atypical window size.

Thanks to sustained testing and investigation of Jonas Maebe, a workaround has now been found and applied, and the website should now be accessible for everyone. It may not be as fast as it could be, but at least it should work in all cases.

Michael.

Michael Van Canneyt wrote

The reason for this - which has been given often - was the atypical window size of the router in front of the server: Some ISP's routers or network configuration could not cope with this atypical window size.

To nitpick: it's not the window size, but the maximum segment size :)

And for the people interested in the details: the problems are that router in front of server
a) blocks incoming ICMP packets that are necessary for automatic MTU detection. As a result, the server cannot detect problems in case a network connection down the line requires a smaller TCP segment size. b) set the TCP maximum segment size of all *incoming* packets to 1472. This means that setting the MTU on your computer to a low value (which would then also be used by the server when replying) won't help, since the server always sees an MTU of 1472 bytes.
c) sets the "don't fragment" flag on outgoing IP packets. This means that even if the server is configured to not add the "don't fragment" flag to packets so they can be fragmented by other routers when sending them over a connection with a smaller MTU, the end result won't change since by the time the packets arrive at those routers, they'll again have a DF flag set.

In the end, what did work was to enable TCP MTU detection on the server.

I don't know what kind of router is being used, but I would advise everyone to stay away from it as far as possible. The number of ways in which that thing tries to prevent connectivity with low-MTU endpoints is really astounding.

Jonas

It's a very common CISCO router :-)

The problem is not really the router itself, but the instructions we got from the ISP on how to configure it :(

(totally braindead instructions in my opinion, but arguing didn't really help)

Michael.

Hi and sorry for bumping in,

Over here (isp) we have to use a lower mtu to be able to pass both mpls and vlan tags around, it's not that braindead if you need that. Why they need that for 'simple' access is indeed a bit strange.

Kind regards,

Axel Scheepers

The server is connected via adsl, probably using PPPoE. I guess the mss on incoming packets is set to the maximum mss that can be handled by the PPPoE connection (so that servers that reply won't use a higher mss). What does seem braindead to me is that the mss of incoming packets with a lower mss is increased to this maximum. And of course also that they drop ICMP type 3 code 4 messages ("fragmentation needed but don't-fragment bit set") and that they always set the "Don't Fragment" bit to outgoing packages.

Jonas