I fixed a MTU bug this week. The bug description was very interesting and confusing.
1) PPPoE works well, if other than TLS authentication method was selected;
2) PPTP works well if only EAP-TLS is selected for authentication method;
3) PPPoE connection failed, if only EAP-TLS is selected for authentication method;
PPPoE is ok according to 1), TLS is ok according to 2). So, the 3) failure should be cause by some special feature, which is different between PPPOE and PPTP. First, I checked on which step the pppoe connection failed.
As you can see in the picture, a lot of repeating EAP request packets were sent out from the PPPOE server. No Response packets were sent out since frame 282. So something must be wrong with TLS authentication. I found the expected packet contain certificates of client. The failure happened in PPPoE, not TLS.
At last, I found the size of the expected packet is 1502, two bytes larger than ethernet's MTU. So, it might be a MTU issue. After further investigation, the root cause of this bug was found:
1) MTU - Maximum Transmissible Unit, it means the maximum size of packet that will be send on a special network;
2) MTU for Ethernet is 1500 bytes;
3) PPP and PPPoE header contains another 8 bytes based on ethernet frame, so the MTU for PPPoE is 1492 bytes;
4) TLS send certificate using MTU of 1500, which increased to 1508 after being encapsulted by PPPoE.
6) Certificate packets were dropped by NDIS because it could not be sent out on ethernet.
Portion | Bytes |
Payload | 1492 |
PPP Headers | +2 |
PPPoE Headers | +6 |
Ethernet Headers | +18 |
Total Frame Size | 1518 |
The bug was fixed by changing the MTU of TLS from 1500 to 1492.
By the way, in all the network modules, only IP and TLS include support for fragmentation and reassembly.