Date: Mon, 24 Jun 2002 11:02:41 -0500 (CDT) From: Jonathan Lemon <jlemon@flugsvamp.com> To: dhuang@qobra.com, bugs@freebsd.org Subject: Re: misc/39787: T/TCP support Message-ID: <200206241602.g5OG2f481877@prism.flugsvamp.com> In-Reply-To: <local.mail.freebsd-bugs/200206241538.g5OFci6O085927@www.freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
In article <local.mail.freebsd-bugs/200206241538.g5OFci6O085927@www.freebsd.org> you write: >>Description: >I tested the T/TCP by using the source code in <T/TCP Illustrated Volume >3> on FreeBsd 4.5. The tcpdump result as below: > >09:49:10.957632 dhcp189.tor.qobra.net.1026 > dhcp189.tor.qobra.net.1028: >SFP 3873691517:3873691817(300) win 65535 <mss 16344,nop,nop,ccnew 7> (DF) > >09:49:10.957748 dhcp189.tor.qobra.net.1028 > dhcp189.tor.qobra.net.1026: >S 2495134045:2495134045(0) ack 3873691518 win 65535 <mss 16344, nop, >nop, cc 8, nop,nop,ccecho 7> > >09:49:10.957782 dhcp189.tor.qobra.net.1026 > dhcp189.tor.qobra.net.1028: >F 301:301(0) ack 1 win 65535 <nop,nop,cc 7> (DF) > >09:49:10.957834 dhcp189.tor.qobra.net.1028 > dhcp189.tor.qobra.net.1026: >ack 1 win 65535 <nop,nop,cc 8> (DF) > >09:49:11.950539 dhcp189.tor.qobra.net.1026 > dhcp189.tor.qobra.net.1028: >FP 1:301(300) ack 1 win 65535 <nop,nop,cc 7> (DF) > >09:49:11.950578 dhcp189.tor.qobra.net.1028 > dhcp189.tor.qobra.net.1026: >ack 302 win 65535 <nop,nop,cc 8> (DF) > >09:49:11.950750 dhcp189.tor.qobra.net.1028 > dhcp189.tor.qobra.net.1026: >FP 1:401(400) ack 302 win 65535 <nop,nop,cc 8> (DF) > >09:49:11.950768 dhcp189.tor.qobra.net.1026 > dhcp189.tor.qobra.net.1028: >ack 402 win 65535 <nop,nop,cc 7> (DF) > >The client sent 300 bytes to server, and server reply 400 bytes to >client. It seems that step 4 and 5 are wrong, but I don't know why. I >set rfc1644 on(1) and rfc1323 off(0), why step 4 sends wrong ACK and >step 5 resend the message to server. I'm not sure why step 3 (sending a bare FIN) is present. However, otherwise, the transaction above looks correct; the syncache will only ACK the SYN, and not the rest of the data in the packet, so the data needs to be retransferred. TCP Accelerated Open only applies to the second connection seen from a machine; the first connection will always undergo the standard 3way handshake, since it needs to cache the connection count. You can see this in the first connection because 'ccnew' is present, not 'cc'. Do further connections fome the machine still exhibit this behavior? -- Jonathan To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-bugs" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200206241602.g5OG2f481877>