3 ms·
That could be an old BSD bug. When there is no ARP entry the first fragment is dropped before the ARP entry is cached. That made it into many BDS based network
by mzs 3y ago
That could be an old BSD bug. When there is no ARP entry the first fragment is dropped before the ARP entry is cached. That made it into many BDS based network software stacks before it was fixed.
I just use 1024 since nobody seems to use SLIP anymore. It should fit under 1200 with headers and the logic is similar to DEC 512+64 limit arrived at initially. All the PMTU detection algos suffer from something lowering the MTU along a route for a long lasting connection.
- toast0 3y agoThis was chargen servers on random Windows boxes. Hitting me with tons of 64k UDP packets, so they would would get fragmented, but I almost never got the first fragment. This is, of course, nonsense on so many levels, but it was very effective, because my servers at the time had a ridiculous IP fragment reassembly buffer (autoscaled based on system ram size, with a formula written decades ago) and reassembly did a linear search of the buffer. No big deal in normal conditions when we got one or two fragmented packets a minute; immensely terrible when getting a couple GBps of fragmented chargen reflection that could never be reassembled. Setting the reassembly buffer to the minimum solved the problem; during DDoS attacks, legitimate fragments wouldn't be reassembled, but oh well, so many other services don't ever assemble fragments, we did the best we could.