From: Alan Davey
Date: Tue, 12 Jul 2016 12:34:07 +
> - all future applications have to continue to implement their own
> fragmentation code, duplicating that which already exists in the kernel
They have to do this anyways, don't you see this?
Otherwise they don't support %99 of the kernel
>> On Wed, 15 Jun 2016, Alan Davey wrote:
>>
>>> The only case that would break is that where an application relies on
>>> the existing (documented as a bug) feature of getting an EMSGSIZE
>>> return code in the case of an over-sized packet. Applications that
>>> perform their own fragmentatio
Hello!
I can tell why it has not been done initially.
Main problem was in IP options, which can be present in raw packet.
They have to be properly fragmented, some options are to be deleted
on fragments. Not that it is too complicated, it is just boring and ugly
and inconsistent with IP_HDRINCL l
From: Paul Jakma
Date: Fri, 8 Jul 2016 13:55:11 +0100 (BST)
> On Wed, 15 Jun 2016, Alan Davey wrote:
>
>> The only case that would break is that where an application relies on
>> the existing (documented as a bug) feature of getting an EMSGSIZE
>> return code in the case of an over-sized packet.
On Wed, 15 Jun 2016, Alan Davey wrote:
The only case that would break is that where an application relies on
the existing (documented as a bug) feature of getting an EMSGSIZE
return code in the case of an over-sized packet. Applications that
perform their own fragmentation would be unaffected
On 31.05.2016 20:39, David Miller wrote:
> From: Alan Davey
> Date: Mon, 23 May 2016 15:23:45 +0100
>
>> One of the bugs documented in the raw(7) man page is as follows: When the
>> IP_HDRINCL option is set, datagrams will not be fragmented and are limited to
>> the interface MTU.
>>
>> This patc
From: David Miller [mailto:da...@davemloft.net]
Sent: 08 June 2016 18:26
>> - The current behaviour is counter-intuitive (fragmentation takes
>> - place in all other cases) and therefore different to what
>> - everyone expects.
>
> But it's what all existing applications must expect, and as
From: Alan Davey
Date: Wed, 8 Jun 2016 08:41:31 +
> - The current behaviour is counter-intuitive (fragmentation takes
> - place in all other cases) and therefore different to what
> - everyone expects.
But it's what all existing applications must expect, and as you have
seen in these repl
viour.
Regards
Alan
-Original Message-
From: David Miller [mailto:da...@davemloft.net]
Sent: 31 May 2016 19:39
To: Alan Davey
Cc: netdev@vger.kernel.org; kuz...@ms2.inr.ac.ru; jmor...@namei.org;
yoshf...@linux-ipv6.org; ka...@trash.net
Subject: Re: [PATCH] net: Fragment large datagrams
Hi
Please do not use "top-posting" here.
Alan Davey wrote:
> Hi David
>
> Thank you for your email. I understand raw IP sockets have worked this way
> for a long time, but I think that there is real benefit in this patch for
> little risk. Please take a look at the following and let me know
.
Regards
Alan
-Original Message-
From: David Miller [mailto:da...@davemloft.net]
Sent: 31 May 2016 19:39
To: Alan Davey
Cc: netdev@vger.kernel.org; kuz...@ms2.inr.ac.ru; jmor...@namei.org;
yoshf...@linux-ipv6.org; ka...@trash.net
Subject: Re: [PATCH] net: Fragment large datagrams even when
From: Alan Davey
Date: Mon, 23 May 2016 15:23:45 +0100
> One of the bugs documented in the raw(7) man page is as follows: When the
> IP_HDRINCL option is set, datagrams will not be fragmented and are limited to
> the interface MTU.
>
> This patch fixes the bug by removing the check for "length >
One of the bugs documented in the raw(7) man page is as follows: When the
IP_HDRINCL option is set, datagrams will not be fragmented and are limited to
the interface MTU.
This patch fixes the bug by removing the check for "length > rt->dst.dev->mtu"
in raw_send_hdrinc() (net/ipv4/raw.c). Datagram
13 matches
Mail list logo
