netdev - Re: ppp_generic: fix multilink fragment MTU calculation (again)

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <4E78EF78.7060106@stuffedcow.net>
Date:	Tue, 20 Sep 2011 15:54:32 -0400
From:	Henry Wong <v4l@...ffedcow.net>
To:	David Miller <davem@...hat.com>
CC:	netdev@...r.kernel.org
Subject: Re: ppp_generic: fix multilink fragment MTU calculation (again)

On 9/20/2011 3:21 PM, David Miller wrote:
> From: Henry Wong<v4l@...ffedcow.net>
> Date: Sun, 18 Sep 2011 19:41:49 -0400
>
>> When using MLPPP, the maximum size of a fragment is incorrectly
>> calculated with an offset of -2.
>> This patch reverses the changes in the patch found here:
>> http://marc.info/?l=linux-netdev&m=123541324010539&w=2
>>
>> The value of hdrlen includes the size of both the 2-byte PPP protocol
>> field and the 2- or 4-byte multilink header (2+4=6 for long sequence
>> numbers, 2+2=4 for short sequence numbers). Section 2 of RFC1661 says
>> that the MRU that is negotiated (i.e., the MTU of the sending system)
>> includes only the PPP payload but not the protocol field, thus the
>> correct MTU should be the link's MTU minus the multilink header (mtu -
>> (hdrlen-2)).
>>
>> The incorrect calculation causes Linux to fragment packets to a size
>> two bytes smaller than the allowed MTU. While not technically illegal,
>> this behaviour confounds MRU-tuning to avoid PPP-layer fragmentation.
>>
>> Signed-off-by: Henry Wong<henry@...ffedcow.net>
> Applied, thanks.
>
> There were several cases of trailing whitespace in your patch which I
> needed to fix up.  Please don't be so careless in the future.
>
> Thanks.
>

Thanks.

Out of curiosity, were the trailing whitespaces on Lines 10 and 11? Or 
was there a problem with file attachments that cause some whitespace I 
don't see? I'll be more careful next time :)
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html