From volf@oasis.IAEhv.nl Wed Jan 8 02:14:41 2003 Return-path: Received: (from root@localhost) by darren2.lnk.telstra.net (8.11.0/8.11.0) id h07BhVh22912 for ; Tue, 7 Jan 2003 22:43:31 +1100 (EST) Received: from a177167.upc-a.chello.nl(62.163.177.167) by firewall.reed.wattle.id.au via smap (V2.1) id xma022910; Tue, 7 Jan 03 22:43:23 +1100 Received: by mail.voor.deze.org (Postfix, from userid 226) id EE8E73E08; Tue, 7 Jan 2003 12:43:14 +0100 (CET) Subject: Resend S packet ACK problem To: Darren Reed Date: Tue, 7 Jan 2003 12:43:14 +0100 (CET) cc: devet@devet.org, Frank Volf , guido@gvr.org X-Mailer: ELM [version 2.4ME+ PL99b (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII Message-ID: <20030107114314.EE8E73E08@mail.voor.deze.org> From: volf@oasis.IAEhv.nl (Frank Volf) X-UIDL: '1G!!F=c"!Z@a"!eI2"! Status: ORrU Darren, Finally, I seem to have some time to play with the TCP debugging code that I wrote a month ago. The first thing that I noticed, is errors for the following problem: 1) A TCP connection is setup (S send) 2) Before a SA has been received, the first S packet is resubmittend. 3) The remote site will ACK the receipt of packet 2) with a single A 4) The remote site will then SA the S packet, to complete teh three way handshake. I noticed, that packet 3) is blocked by IP Filter (by fr_tcp_age). I do not know, if this is normal behaviour, or this is some thing new (e.g. introduced by syn caches) IPMON output: 22:56:00.662705 STATE:NEW [4829] 62.163.177.167,1702 -> 212.61.15.130,995 PR tcp 22:56:03.691183 xl0 @0:21 b 212.61.15.130,995 -> 62.163.177.167,1702 PR tcp len 20 40 -A 1460863014 3531839912 17520 IN state [4829] bad:A 23:00:07.345066 STATE:CLOSE [4829] 62.163.177.167,1702 -> 212.61.15.130,995 PR tcp Pkts 29 Bytes 3377 And the TCP dump: Syn: 22:56:00.662746 62.163.177.167.1702 > 212.61.15.130.995: S [tcp sum ok] 3531839911:3531839911(0) win 57344 (DF) (ttl 64, id 62338, len 60, bad cksum 0!) Retransmitted syn: 22:56:03.658843 62.163.177.167.1702 > 212.61.15.130.995: S [tcp sum ok] 3531839911:3531839911(0) win 57344 (DF) (ttl 64, id 61923, len 60, bad cksum 0!) Ack of the retransmit: 22:56:03.691133 212.61.15.130.995 > 62.163.177.167.1702: . [tcp sum ok] ack 3531839912 win 17520 (DF) (ttl 53, id 45611, len 40) SA to complete three way handshake: 22:56:03.697528 212.61.15.130.995 > 62.163.177.167.1702: S [tcp sum ok] 1460863013:1460863013(0) ack 3531839912 win 17520 (DF) (ttl 53, id 45612, len 44) 22:56:03.697625 62.163.177.167.1702 > 212.61.15.130.995: . [tcp sum ok] ack 1 win 58400 (DF) (ttl 64, id 41608, len 40, bad cksum 0!) The followin patch should address this. I have't seen the behaviour since this patch is in place (but it is only in place for 12 hours), so it is not really very conclusive: --- ip_state.c.save Mon Jan 6 23:12:47 2003 +++ ip_state.c Mon Jan 6 23:39:39 2003 @@ -1865,6 +1865,25 @@ state[dir] = TCPS_SYN_SENT; newage = fr_tcptimeout; } + + /* + * It is apparently possible that a hosts sends two syncs + * before the remote party is able to respond with a SA. In + * such a case the remote server sometimes ACK's the second + * sync, and then responds with a SA. The following code + * is used to prevent this ack from being blocked. + * + * We do not reset the timeout here to fr_tcptimeout because + * a connection connect timeout does not renew after every + * packet that is sent. We need to set newage to something + * to indicate the packet has passed the check for its flags + * being valid in the TCP FSM. + */ + else if ((ostate == TCPS_SYN_SENT) && + ((flags & (TH_FIN|TH_SYN|TH_RST|TH_ACK)) == TH_ACK)) { + newage = *age; + } + /* * The next piece of code makes it possible to get * already established connections into the state table @@ -1872,7 +1891,7 @@ * does not work when a strict 'flags S keep state' is * used for tcp connections of course */ - if (!fsm && (flags & (TH_FIN|TH_SYN|TH_RST|TH_ACK)) == TH_ACK) { + else if (!fsm && (flags & (TH_FIN|TH_SYN|TH_RST|TH_ACK)) == TH_ACK) { /* we saw an A, guess 'dir' is in ESTABLISHED mode */ if (state[1 - dir] == TCPS_CLOSED || state[1 - dir] == TCPS_ESTABLISHED) { What do you think? Frank Cc: Arjan de Vet .