Re: Trimming TCP options

Hi, Mihai--

I'd meant to reply to this earlier, but holiday travel interfered.  

On Dec 30, 2010, at 7:06 AM, Mihai Chelaru wrote:
> On 12/30/10 00:45, Greg Troxel wrote:
>> Could you explain
>>  how long you've been running this
> 
> This is my workstation, up since yesterday with normal tasks - browsing,
> mail, radio, torrents, ssh/telnet/rdp client etc.

It's important to note that (most?) TCP stacks will resend SYN packets with fewer TCP options set if the
initial SYN request doesn't get answered in some fashion.  To validate that your changes are working as
expected, you should tcpdump filtering for SYN packets and watch out for duplicate SYNs being sent.

>>  how other implementations behave?  (Specifically, does this make us
>>  like the rest, or different?)
> 
> Bytes requested by each option:
> 
>           SACKP WScale Timestamps Use_EOL
> 
> NetBSD      4      4        12      N
> FreeBSD*    2-3    3-4    10-13     Y     
> Linux-2627  2      4        10      Y  
> Win2003     4      4        12      N(?)
> Cisco IOS   4      4        10      Y
> WinXP       4      4        12      N(?)
> Win7        4      4        ?       N(?)

Re: Trimming TCP options

Pe 04.01.2011 00:04, Chuck Swiger a scris:
> It's important to note that (most?) TCP stacks will resend SYN packets with fewer TCP options set if the
initial SYN request doesn't get answered in some fashion.  To validate that your changes are working as
expected, you should tcpdump filtering for SYN packets and watch out for duplicate SYNs being sent.
>

Hi Chuck !

It's not NetBSD case, where by default all 3 retransmits will use the 
same options.

I modified this morning a little bit that code, and let initial syn and 
first retransmit with full options, the second retransmit with MSS 
option only and the last one with no options at all, and added some 
stats. Until now results look good:

         1072 connection requests
         1654 connection accepts
         2196 connections established (including accepts)
         2721 connections closed (including 47 drops)
         145 embryonic connections dropped
         400 SYN options degraded -> incremented at second syn re-xmit
         2 connected with no options -> connection established after 
second syn re-xmit

I'll keep an eye on the last counter in the following days.

> Hmm, I find it more useful to describe TCP options by strings representing the options in the sequence they
appear, which is the mechanism various OS fingerprinting tools like NMAP, p0f, etc use.
>

Re: Trimming TCP options

Hi, Mihai--

On Jan 4, 2011, at 1:48 AM, Mihai Chelaru wrote:
> It's not NetBSD case, where by default all 3 retransmits will use the same options.
> 
> I modified this morning a little bit that code, and let initial syn and first retransmit with full options,
the second retransmit with MSS option only and the last one with no options at all, and added some stats.
Until now results look good:
> 
>        1072 connection requests
>        1654 connection accepts
>        2196 connections established (including accepts)
>        2721 connections closed (including 47 drops)
>        145 embryonic connections dropped
>        400 SYN options degraded -> incremented at second syn re-xmit
>        2 connected with no options -> connection established after second syn re-xmit
> 
> I'll keep an eye on the last counter in the following days.

Excellent.  While TCP stacks are required to implement NOP, EOL, and MSS, and should also be written to
simply pass over options which they do not understand, some don't, and some folks use firewalls which drop
various options, so falling back to M only is a good procedure.

>> Hmm, I find it more useful to describe TCP options by strings representing the options in the sequence
they appear, which is the mechanism various OS fingerprinting tools like NMAP, p0f, etc use.
>> 
>> NetBSD: MNWSNNNT
> 
> It's even MNWSNNNNT (one more N).

Re: Accept filter semantics (Re: Handling of DOS attacks in NetBSD 5)

On Tue, Jan 04, 2011 at 11:28:32PM +0000, Sad Clouds wrote:
> Does using accept filters offer a dramatic performance improvement? It
> seems to me that using accept filters opens up more avenues for DOS
> attacks.

Yes, they do.

> Web servers that handle many connections use kernel event notification,
> i.e. kqueue, epoll, etc., which don't really need accept filters, do
> they? Apache is probably the only web server that might benefit from
> them.

You are mixing up two completely separate issues. Accept filters for
HTTP allow ensuring serving traffic with four syscalls per request
(ignoring keep alive): accept, read, write, close. The accept filter
ensures that the read doesn't have to loop.

Joerg

dhcp classless routes

I can see how to write the equivalent of

  route add -net w.x.y.z/m g.a.t.e

in /etc/dhcpd.conf using the base system's dhcpd and dhcpcd a la
rfc3442. Am I right in thinking that there is no way of doing the
equivalent of

  route add -net w.x.y.z/m g.a.t.e -iface

?

Cheers,

Patrick

Re: dhcp classless routes

Hi Patrick

On 06/01/2011 13:37, Patrick Welche wrote:
> I can see how to write the equivalent of
>
>    route add -net w.x.y.z/m g.a.t.e
>
> in /etc/dhcpd.conf using the base system's dhcpd and dhcpcd a la
> rfc3442. Am I right in thinking that there is no way of doing the
> equivalent of
>
>    route add -net w.x.y.z/m g.a.t.e -iface

You can do this :)
You need this in dhcpd.conf

option classless-static-routes code 121 = array of unsigned integer 8;

option classless-static-routes m,w,x,y,z,g,a,t,e ... ;

Like so, adding a default route
option classless-static-routes 0,192,168,0,1;

Something more complex
option classless-static-routes 0,10,73,1,1,24,10,73,0,10,73,1,1,24,10,73,2,
10,73,1,1,32,10,0,0,1,10,73,1,1;

Thanks

Roy

Re: Trimming TCP options

On 01/04/11 11:48, Mihai Chelaru wrote:
> I'll keep an eye on the last counter in the following days.

I need to reboot this one so I attached the latest stats and the
sys/netinet diff. I haven't seen anything strange during usage until now.

-- 
Mihai

tcp:
	46317610 packets sent
		36988340 data packets (27717538314 bytes)
		195387 data packets (159339998 bytes) retransmitted
		6355078 ack-only packets (7820889 delayed)
		0 URG only packets
		1396 window probe packets
		2420913 window update packets
		356502 control packets
		0 send attempts resulted in self-quench
	40556719 packets received
		27918469 acks (for 27628909944 bytes)
		0 duplicate acks
		229 acks for unsent data
		11497073 packets (10555150094 bytes) received in-sequence
		677061 completely duplicate packets (36428938 bytes)
		473 old duplicate packets
		33390 packets with some dup. data (22800833 bytes duped)
		673787 out-of-order packets (194682332 bytes)
		3 packets (1 byte) of data after window

Re: dhcp classless routes

On Thu, Jan 06, 2011 at 05:12:29PM +0000, Roy Marples wrote:
> Hi Patrick
> 
> On 06/01/2011 13:37, Patrick Welche wrote:
> >I can see how to write the equivalent of
> >
> >   route add -net w.x.y.z/m g.a.t.e
> >
> >in /etc/dhcpd.conf using the base system's dhcpd and dhcpcd a la
> >rfc3442. Am I right in thinking that there is no way of doing the
> >equivalent of
> >
> >   route add -net w.x.y.z/m g.a.t.e -iface
> 
> You can do this :)
> You need this in dhcpd.conf
> 
> option classless-static-routes code 121 = array of unsigned integer 8;
> 
> option classless-static-routes m,w,x,y,z,g,a,t,e ... ;
> 
> Like so, adding a default route
> option classless-static-routes 0,192,168,0,1;
> 
> Something more complex
> option classless-static-routes 0,10,73,1,1,24,10,73,0,10,73,1,1,24,10,73,2,
> 10,73,1,1,32,10,0,0,1,10,73,1,1;

Decoding:
route add default 10.73.1.1

Re: dhcp classless routes

On Thu, 2011-01-06 at 19:01 +0000, Patrick Welche wrote:
> That looks exactly like what I did to do the equivalent of
> 
> > >   route add -net w.x.y.z/m g.a.t.e
> 
> I don't see what you did differently for the equivalent of
> 
> > >   route add -net w.x.y.z/m g.a.t.e -iface
> 
> eg
> route add -net 10.73.2/24 10.99.99.99 -iface
> (I know that doesn't look pretty, but they are all on the same switch)
> 
> Have I missed something in your explanation?

You missed nothing.

However, dhcpcd will automatically route via the correct interface. Or
rather, the interface dhcpcd received the DHCP packet from.

With conflicting route information, dhcpcd will prefer interfaces on
metric as documented in dhcpcd.conf(5)

Thanks

Roy

Bufferbloat

Very interesting blog article from Jim Gettys (apologies to those who
have already read it) regarding the size of network buffers breaking
TCP.

http://gettys.wordpress.com/2010/12/03/introducing-the-criminal-mastermind-bufferbloat/

I wonder how many people out there are running RED in ALTQ to
effectively mitigate this on their DSL links?