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 for Android: free password hash cracker in your pocket
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <710ab0ca79305c82013982d43250b0a1fd45824d@8b5064a13e22126c1b9329f0dc35b8915774b7c3.invalid>
Date:	Wed, 20 Jan 2010 12:59:16 -0000
From:	"Simon Arlott" <simon@...e.lp0.eu>
To:	"William Allen Simpson" <william.allen.simpson@...il.com>,
	"Patrick McHardy" <kaber@...sh.net>
Cc:	"netdev" <netdev@...r.kernel.org>,
	"Linux Kernel Mailing List" <linux-kernel@...r.kernel.org>,
	netfilter-devel@...r.kernel.org
Subject: Re: [PATCH] xt_TCPMSS: SYN packets are allowed to contain data

On Tue, January 19, 2010 15:44, William Allen Simpson wrote:
> Simon Arlott wrote:
>> On Tue, January 19, 2010 09:17, William Allen Simpson wrote:
>> I could change the comment too, but the same logic applies when
>> there is data and no MSS option - the packet can't be increased
>> in size if it would then exceed 576 bytes and/or the destination
>> MTU.
>>
> Please change the comment.

I've made a new version of the patch which I'll be able to test
tonight.

> If there is no MSS option, it should *not* be added, under *ANY*
> circumstances.  That violates the end-to-end arguments (some call
> them principles).

Agreed. The added MSS is likely to be larger than 536 too... I've
removed this code.

> MSS isn't about the _destination_ MTU, it's about the *source*.
> If you cannot guarantee you know the source MTU, there's no basis
> for deciding the MSS.

I was referring to the SYN packet itself. It wouldn't always be
possible to add an option without exceeding the MTU of that packet's
destination if it had data.


On 19/01/10 12:53, Patrick McHardy wrote:
> Simon Arlott wrote:
>> If this is 20 (IPv4 Header) + 20 (TCP Header) = 40 bytes, then
>> there is no data and the header offset is wrong so it hasn't been
>> checked.
>
> That's odd. If the packet is really only 40 bytes large, then there
> are no TCP options, so your patch shouldn't have any effect.

Except to remove the printk which fills up my serial console (because
the header offset is wrong).

-- 
Simon Arlott
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ