On Fri, Feb 14, 2003 at 08:15:35PM +0100, Nick Nauwelaerts wrote: > non ecn: > 18:41:25.069229 192.168.0.3.1293 > 195.130.132.40.25: S [tcp sum ok] > 879782618:879782618(0) win 16384 <mss 1460,nop,nop,sackOK,nop,wscale > 0,nop,nop,timestamp 1954566973 0> (DF) [tos 0x10] (ttl 64, id 43699) > 18:41:25.069409 195.130.132.40.25 > 192.168.0.3.1293: R [tcp sum ok] > 0:0(0) ack 879782619 win 0 (DF) (ttl 64, id 18346) > > with ecn: > 18:35:22.746040 192.168.0.3.3807 > 195.130.132.45.25: SWE [tcp sum ok] > 2052596769:2052596769(0) win 16384 <mss 1460,nop,nop,sackOK,nop,wscale > 0,nop,nop,timestamp 1954566249 0> (DF) [tos 0x10] (ttl 64, id 50046) > 18:35:22.746227 195.130.132.45.25 > 192.168.0.3.3807: R [tcp sum ok] > 0:0(0) ack 2052596770 win 0 (DF) (ttl 64, id 601)
That looks equally fine in both cases, I don't see why the ecn case should be interpreted differently on the client. > They also arive at 192.168.0.3, I can give you the tcpdump -s 1500 > output of that if needed. Yes, just to check whether both cases are correct RSTs. > Well, I did notice something abnormal in it. I'm getting flooded with > messages that say: > Feb 14 18:39:04 zombie /bsd: pf_map_addr: selected address: 192.168.0.1 Those are harmless, you can safely ignore them. You mention that you see the RSTs arrive at the client in both cases. Are you maybe running pf on the client as well? Is it maybe filtering statefully with 'flags S', so the outgoing SYN+ECN is not creating state and the RST is blocked on the client? If the RST arrives at the client, and is valid, it looks like the problem is on the client, not the gateway. Daniel
