netdev - Re: [net-next-2.6 PATCH v6 4/7 RFC] TCPCT part 1d: define TCP cookie option, extend existing struct's

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]

Date:	Tue, 17 Nov 2009 14:07:08 +0200 (EET)
From:	"Ilpo Järvinen" <ilpo.jarvinen@...sinki.fi>
To:	Eric Dumazet <eric.dumazet@...il.com>
cc:	William Allen Simpson <william.allen.simpson@...il.com>,
	Linux Kernel Network Developers <netdev@...r.kernel.org>,
	Joe Perches <joe@...ches.com>
Subject: Re: [net-next-2.6 PATCH v6 4/7 RFC] TCPCT part 1d: define TCP cookie
 option, extend existing struct's

On Mon, 16 Nov 2009, Eric Dumazet wrote:

> William Allen Simpson a écrit :
> > Eric Dumazet wrote:
> > 
> >> I remember a previous remark from David that our skb queues would not
> >> contain
> >> DATA on SYN packets...
> >>
> > I haven't seen anything by David, but there's an existing comment in
> > tcp_input.c at the place where SYN data will be added later:
> > 
> 
> Yep, David comment was about another netdev thread, while tracking an 
> obscure bug 
> 
> http://www.spinics.net/lists/netdev/msg110759.html
> 
> http://www.spinics.net/lists/netdev/msg110764.html
> 
> 
> So adding DATA to SYN packets might be problematic for part of our tcp 
> stack. 

You both are right (and that's what is causing confusion)... What DaveM 
said is this:

"And we're only dealing with data packets once we enter established
state, and when we enter established by definition we have unlinked
and freed up any SYN and SYN+ACK SKBs in the write queue."

We certainly can have SYN/SYNACKs in write queue but not in certain 
states, and consequently, not in certain functions.


-- 
 i.