[dpdk-dev] ipv4 fragmentation bug?

Александр Киселев kiselev99 at gmail.com
Mon Aug 15 19:48:04 CEST 2016


I'am sorry. Looks like having an mtu value multiply of 8 is a good practice.

But mtu value 1504 is also widely used in qinq linux interfaces.

2016-08-15 20:30 GMT+03:00 Александр Киселев <kiselev99 at gmail.com>:

> While playing with function rte_ipv4_fragment_packet I found that it
> incorrectly fragments packets.
> For example if the function takes 1200 bytes packet and mtu size 1000 it
> will produces two fragments. And when those fragments are reassembled back
> the resulting packet will be 4 bytes shorter than it should be.
>
> I played with linux ping program and it reports that a reply is truncated.
>     1204 bytes from 192.168.125.1: icmp_seq=1 ttl=64 (truncated)
>
> Looking at the source of rte_ipv4_fragment_packet I discovered the cause
> of the above behavior.
>
> Function makes the following assumption and the whole calculations are
> bases on that assumption.
>
> /* Fragment size should be a multiply of 8. */
> IP_FRAG_ASSERT((frag_size & IPV4_HDR_FO_MASK) == 0);
>
> The problem is that this assert doesn’t make any sense. It's true that
> fragment size should be a multiply of 8, but what this line real checks is
> that
> the size of mtu minus 20 bytes should be multiply of 8. In other words
> it constrains the size of the mtu. So, if I take valid mtu value, say
> 1504,
> it will produce incorrect fragments when asserts are off.
>
> P.S.
> I am using DPDK v 2.2.0
>
> --
> --
> Kiselev Alexander
>



-- 
--
Kiselev Alexander


More information about the dev mailing list