Work around possible incorrect path MTU size establishment due to VPN compression

[dktapps]

There have been a lot of intermittent reports for a long time about connection problems to PM servers when using a VPN.

In the process of attempting to debug this issue, I noted that ID_OPEN_CONNECTION_REQUEST_1 has a payload padded with 0 bytes. This is a potential problem if used over a VPN using compression which also has a lower path MTU than the usual 1492 bytes. The reason is that the usual RakNet assumption (if this is too big, we won't get a reply) is broken in the case of compressed VPN since the connection request itself will be compressed.

A possible solution to this is to append a padding of randomly-generated bytes to the end of ID_OPEN_CONNECTION_REPLY_1 which will not be possible to compress. This will prevent the client receiving the response if the MTU size is bullshit due to compression.

To be clear, this bug/oversight is a problem with a RakNet client so it can't be directly fixed by us, only worked around.

[dktapps]

This workaround cannot currently be implemented in PHP due to the lack of ability to set the DONTFRAGMENT bit on outgoing packets.