From mboxrd@z Thu Jan  1 00:00:00 1970
From: Thomas Monjalon <thomas.monjalon@6wind.com>
Subject: Re: ipv4 fragmentation bug?
Date: Mon, 22 Aug 2016 13:31:12 +0200
Message-ID: <13658731.5PNXAK9RiV@xps13>
References: <CAMKNYbx3g1Ft+ZuTtwu7ai_dYyHhs6pPWjd5B=Pv0qSB0zG-Mg@mail.gmail.com>
 <CAMKNYby4g_Oi68E7x1=G1+3nLMfpVkZ_UMkZdWf5GiRQHApaAA@mail.gmail.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
Cc: dev@dpdk.org
To: =?utf-8?B?0JDQu9C10LrRgdCw0L3QtNGAINCa0LjRgdC10LvQtdCy?=
 <kiselev99@gmail.com>
Return-path: <dev-bounces@dpdk.org>
Received: from mail-wm0-f42.google.com (mail-wm0-f42.google.com [74.125.82.42])
 by dpdk.org (Postfix) with ESMTP id 00A682B88
 for <dev@dpdk.org>; Mon, 22 Aug 2016 13:31:15 +0200 (CEST)
Received: by mail-wm0-f42.google.com with SMTP id i5so138855711wmg.0
 for <dev@dpdk.org>; Mon, 22 Aug 2016 04:31:15 -0700 (PDT)
In-Reply-To: <CAMKNYby4g_Oi68E7x1=G1+3nLMfpVkZ_UMkZdWf5GiRQHApaAA@mail.gmail.com>
List-Id: patches and discussions about DPDK <dev.dpdk.org>
List-Unsubscribe: <http://dpdk.org/ml/options/dev>,
 <mailto:dev-request@dpdk.org?subject=unsubscribe>
List-Archive: <http://dpdk.org/ml/archives/dev/>
List-Post: <mailto:dev@dpdk.org>
List-Help: <mailto:dev-request@dpdk.org?subject=help>
List-Subscribe: <http://dpdk.org/ml/listinfo/dev>,
 <mailto:dev-request@dpdk.org?subject=subscribe>
Errors-To: dev-bounces@dpdk.org
Sender: "dev" <dev-bounces@dpdk.org>

Hi,

> 2016-08-15 20:30 GMT+03:00 =D0=90=D0=BB=D0=B5=D0=BA=D1=81=D0=B0=D0=BD=
=D0=B4=D1=80 =D0=9A=D0=B8=D1=81=D0=B5=D0=BB=D0=B5=D0=B2 <kiselev99@gmai=
l.com>:
> > While playing with function rte_ipv4_fragment_packet I found that i=
t
> > incorrectly fragments packets.
> > For example if the function takes 1200 bytes packet and mtu size 10=
00 it
> > will produces two fragments. And when those fragments are reassembl=
ed 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 tru=
ncated.
> >     1204 bytes from 192.168.125.1: icmp_seq=3D1 ttl=3D64 (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) =3D=3D 0);
> >
> > The problem is that this assert doesn=E2=80=99t make any sense. It'=
s true that
> > fragment size should be a multiply of 8, but what this line real ch=
ecks is
> > that
> > the size of mtu minus 20 bytes should be multiply of 8. In other wo=
rds
> > it constrains the size of the mtu. So, if I take valid mtu value, s=
ay
> > 1504,
> > it will produce incorrect fragments when asserts are off.

Thanks for reporting.

2016-08-15 20:48, =D0=90=D0=BB=D0=B5=D0=BA=D1=81=D0=B0=D0=BD=D0=B4=D1=80=
 =D0=9A=D0=B8=D1=81=D0=B5=D0=BB=D0=B5=D0=B2:
> I'am sorry. Looks like having an mtu value multiply of 8 is a good pr=
actice.
>=20
> But mtu value 1504 is also widely used in qinq linux interfaces.

Please, would like to write a patch for master branch?
Or do you prefer to delegate it to someone reading this thread?