On Monday 01 December 2014 08:49:34 Sven Eckelmann wrote:
Hi,
I've just noticed that the padding by the underlying network protocol seems not to be handled by the fragmentation. Maybe Martin can correct me. I will now use following assumptions:
- the fragmentation code is sending first the last part of the packet and tries to fill the complete skb (max 1400 byte)
- the mtu of the underlying device is 1400
- the minimum packet size (user data + eth header) of the underlying device
is 70
- the packet send by the user would end up to be 1401 bytes before fragmentation
Ok, then I would guess that the fragmentation code would try to generate fragments with the max_fragment_size 1366 (+headers of course, not sure why the code assumes that the ethernet header is part of the MTU). This would mean that the 1401 byte packet is split into a 1366 byte fragment (+header) and a 35 byte fragment (+header).
But the 35 byte fragment containing the first part of the packet is (even with the headers) still smaller than the required packet size of the underlying device. Now some extra bytes are added as padding to the last fragment (containing the first part of the original packet).
The calculation of the fragment sizes was unified in patch https://lists.open-mesh.org/pipermail/b.a.t.m.a.n/2014-December/012620.html
My knowledge about the fragmentation code is now a little bit better and I have to correct the numbers above. The max_fragment_size is now 1380 (after the patch). The split of the 1401 bytes packet would be 1380 bytes and 21 bytes. The size with all headers would be: 1414 bytes and 55 bytes. 55 is even smaller than 60 (minimal 802.3 frame size). Therefore, splitting packets into fragments for 802.3 devices with MTU <= 1400 bytes is problematic when the batman-adv packet to split is larger than the MTU but less than 6 bytes larger than the MTU. For devices with 1400 < MTU <= 1405 it is problematic for batman-adv packets larger than the MTU but smaller than 1406 bytes.
There are even more problematic situations possible when the batman-adv packet has to be split into more than two packets.
Just for reference: An unicast ethernet frame (with ethernet header) of 1514 bytes would end up as batman-adv unicast packet of 1538 bytes. The underlying device must have at least the MTU of 1524 bytes (The 14 byte ethernet header is not part of the MTU) to allow batman-adv to transport the packet without fragmentation.
Kind regards, Sven