I have a pair on boxes running 7.2-RELEASE/i386 and have found that it is generating stray RST packets. As an example, ssh server echo hello will generate a sequence like the following (as seen on the server): 10:03:29.277427 IP client.55871 > server.22: S 1808736437:1808736437(0) win 49640 <mss 1460,nop,wscale 0,nop,nop,sackOK> 10:03:29.277674 IP server.22 > client.55871: S 3948204651:3948204651(0) ack 1808736438 win 65535 <mss 1460,nop,wscale 3,sackOK,eol> 10:03:29.278202 IP client.55871 > server.22: . ack 3948204652 win 49640 ... 10:03:30.078227 IP client.55871 > server.22: . ack 3948207204 win 49640 10:03:30.078637 IP client.55871 > server.22: P 1808738140:1808738172(32) ack 3948207204 win 49640 10:03:30.078732 IP client.55871 > server.22: F 1808738172:1808738172(0) ack 3948207204 win 49640 10:03:30.078751 IP server.22 > client.55871: . ack 1808738173 win 8212 10:03:30.079135 IP server.22 > client.55871: F 3948207204:3948207204(0) ack 1808738173 win 8212 10:03:30.079528 IP client.55871 > server.22: . ack 3948207205 win 49640 10:03:32.798071 IP server.22 > client.55871: R 3948207204:3948207204(0) win 0 10:03:32.798086 IP server.22 > client.55871: . ack 1808738173 win 0 10:03:32.798518 IP client.55871 > server.22: . ack 3948207205 win 49640 10:03:32.798608 IP server.22 > client.55871: R 3948207205:3948207205(0) win 0 The delay between the FIN/ACK and subsequent RST is normally about a second but varies between about 150msec and 3 seconds (and occasionally it doesn't generate a RST at all). When there are two sessions close together, RSTs for both sessions may be generated together: 10:37:25.345622 IP client.58124 > server.22: S 2602521411:2602521411(0) win 49640 <mss 1460,nop,wscale 0,nop,nop,sackOK> 10:37:25.345818 IP server.22 > client.58124: S 954205035:954205035(0) ack 2602521412 win 65535 <mss 1460,nop,wscale 3,sackOK,eol> 10:37:25.346400 IP client.58124 > server.22: . ack 954205036 win 49640 ... 10:37:26.012584 IP client.58124 > server.22: . ack 954207508 win 49640 10:37:26.013295 IP client.58124 > server.22: P 2602523114:2602523146(32) ack 954207604 win 49640 10:37:26.013391 IP client.58124 > server.22: F 2602523146:2602523146(0) ack 954207604 win 49640 10:37:26.013421 IP server.22 > client.58124: . ack 2602523147 win 8208 10:37:26.014119 IP server.22 > client.58124: F 954207604:954207604(0) ack 2602523147 win 8208 10:37:26.014493 IP client.58124 > server.22: . ack 954207605 win 49640 10:37:27.264149 IP client.58128 > server.22: S 2603683222:2603683222(0) win 49640 <mss 1460,nop,wscale 0,nop,nop,sackOK> 10:37:27.264229 IP server.22 > client.58128: S 2795742829:2795742829(0) ack 2603683223 win 65535 <mss 1460,nop,wscale 3,sackOK,eol> 10:37:27.264630 IP client.58128 > server.22: . ack 2795742830 win 49640 ... 10:37:27.889755 IP client.58128 > server.22: . ack 2795745382 win 49640 10:37:27.890051 IP client.58128 > server.22: P 2603684941:2603684973(32) ack 2795745382 win 49640 10:37:27.890146 IP client.58128 > server.22: F 2603684973:2603684973(0) ack 2795745382 win 49640 10:37:27.890203 IP server.22 > client.58128: . ack 2603684974 win 8212 10:37:27.890924 IP server.22 > client.58128: F 2795745382:2795745382(0) ack 2603684974 win 8212 10:37:27.891353 IP client.58128 > server.22: . ack 2795745383 win 49640 10:37:28.038288 IP server.22 > client.58124: R 954207604:954207604(0) win 0 10:37:28.038353 IP server.22 > client.58124: . ack 2602523147 win 0 10:37:28.038543 IP server.22 > client.58128: R 2795745382:2795745382(0) win 0 10:37:28.038556 IP server.22 > client.58128: . ack 2603684974 win 0 10:37:28.038754 IP client.58124 > server.22: . ack 954207605 win 49640 10:37:28.038869 IP server.22 > client.58124: R 954207605:954207605(0) win 0 10:37:28.038887 IP client.58128 > server.22: . ack 2795745383 win 49640 10:37:28.038984 IP server.22 > client.58128: R 2795745383:2795745383(0) win 0 The systems are using ipfw and have dummynet in the kernel but it isn't used. The type of client doesn't seem to matter (same behaviour with FreeBSD or Solaris clients) and it's not limited to ssh (that was just where I first noticed it). In conjection with the stray RST packets, I am also seeing TCP error messages in syslog: Jul 29 10:03:32 aalp05 kernel: TCP: [client]:55871 to [server]:22 tcpflags 0x10<ACK>; syncache_expand: Segment failed SYNCOOKIE authentication, segment rejected (probably spoofed) Jul 29 10:03:32 aalp05 kernel: TCP: [client]:55871 to [server]:22 tcpflags 0x10<ACK>; syncache_expand: Segment failed SYNCOOKIE authentication, segment rejected (probably spoofed) Jul 29 10:37:28 aalp05 kernel: TCP: [client]:58124 to [server]:22 tcpflags 0x10<ACK>; syncache_expand: Segment failed SYNCOOKIE authentication, segment rejected (probably spoofed) Jul 29 10:37:28 aalp05 kernel: TCP: [client]:58128 to [server]:22 tcpflags 0x10<ACK>; syncache_expand: Segment failed SYNCOOKIE authentication, segment rejected (probably spoofed) Jul 29 10:37:28 aalp05 kernel: TCP: [client]:58124 to [server]:22 tcpflags 0x10<ACK>; syncache_expand: Segment failed SYNCOOKIE authentication, segment rejected (probably spoofed) Jul 29 10:37:28 aalp05 kernel: TCP: [client]:58128 to [server]:22 tcpflags 0x10<ACK>; syncache_expand: Segment failed SYNCOOKIE authentication, segment rejected (probably spoofed) Note that the syslog message implies there is an incoming packet but tcpdump doesn't show one. Does anyone have any suggestions? -- Peter Jeremy -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 196 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20090729/d40e32b2/attachment.pgp