Date: Sat, 22 Jan 2000 08:52:38 -0700 From: Brett Glass <brett@lariat.org> To: Don Lewis <Don.Lewis@tsc.tdk.com>, Vladimir Dubrovin <vlad@sandy.ru>, Tim Yardley <yardley@uiuc.edu> Cc: freebsd-security@FreeBSD.ORG Subject: Re: Re[2]: explanation and code for stream.c issues Message-ID: <4.2.2.20000122083929.01a5aa90@localhost> In-Reply-To: <200001221058.CAA16745@salsa.gv.tsc.tdk.com> References: <Vladimir Dubrovin <vlad@sandy.ru>
next in thread | previous in thread | raw e-mail | index | archive | help
At 03:58 AM 1/22/2000 , Don Lewis wrote: >} By the way - published stream.c doesn't use ACK bit at all. >} packet.tcp.th_flags = 0; > >There was a correction published that changed this to set the ACK bit. True. But y'know, he does have a point. Shouldn't tcp_input() drop or reject anything with certain combinations of flags really early on? About 15 years ago (has it been that long?) I wrote part of a TCP/IP stack for a class at Stanford. The first statement in the routine which was the equivalent of tcp_input() checksummed the packet. The second one was a "case" (this was Pascal) that broke out cases for every combination of the TCP option flags. (The compiler implemented case statements as jump tables, so this was fast.) Do you think it's worth doing that here, both for clarity and for speed? It would probably help to catch all the issues involving option flags, and it would be more efficient than the current structure (which does lots of tests one at a time and is harder to follow). --Brett To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4.2.2.20000122083929.01a5aa90>