From mboxrd@z Thu Jan 1 00:00:00 1970 To: 9fans@9fans.net From: "Russ Cox" Date: Wed, 16 Apr 2008 09:31:13 -0400 In-Reply-To: <638b0c1689eb3e5fc5e1dcac5a1fdff5@quanstro.net> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Message-Id: <20080416133300.E90521E8C3A@holo.morphisms.net> Subject: Re: [9fans] telnet vs. godaddy whois Topicbox-Message-UUID: 8ee31e02-ead3-11e9-9d60-3106f5b1d025 > does anyone know why telnet has trouble with this? > > ; echo godaddy.com|telnet -nr /net.alt/tcp!whois.godaddy.com!43 > connected to /net.alt/tcp!whois.godaddy.com!43 on /net.alt/tcp/12 > ; > > from a similarly-connected linux machine, linux telnet returns a > lengthy answer. It's not telnet's fault. It's a TCP bug. Here's a trace on Linux. Notice that godaddy's SYN|ACK packet (34822ms) advertises a zero-length receive window, so Linux has to wait until it gets an ACK to its ACK to open the window (34899ms) before it sends (34900ms). # /usr/local/plan9/bin/snoopy -f 'tcp(sd=43)' eth0 after optimize: ether(ip(tcp(sd = 43))) 034744 ms ether(s=000feafc0dbe d=00095bdb3254 pr=0800 ln=74) ip(s=192.168.0.99 d=68.178.211.43 id=9ca5 frag=4000 ttl= 64 pr=6 ln=60) tcp(s=42805 d=43 seq=1897121382 ack=0 fl=S win=5840 ck=d993 opt4=(mss 1460) opt2=(4 ) opt10=(8 45155AC300000000) opt=NOOP opt3=(wscale 7)) 034822 ms ether(s=00095bdb3254 d=000feafc0dbe pr=0800 ln=60) ip(s=68.178.211.43 d=192.168.0.99 id=9ca5 frag=0000 ttl= 31 pr=6 ln=40) tcp(s=43 d=42805 seq=3642134677 ack=1897121383 fl=AS win=0 ck=8e61) 034822 ms ether(s=000feafc0dbe d=00095bdb3254 pr=0800 ln=54) ip(s=192.168.0.99 d=68.178.211.43 id=9ca6 frag=4000 ttl= 64 pr=6 ln=40) tcp(s=42805 d=43 seq=1897121383 ack=3642134678 fl=A win=5840 ck=7792) 034899 ms ether(s=00095bdb3254 d=000feafc0dbe pr=0800 ln=60) ip(s=68.178.211.43 d=192.168.0.99 id=34a4 frag=0000 ttl=111 pr=6 ln=40) tcp(s=43 d=42805 seq=3642134678 ack=1897121383 fl=A win=16384 ck=4e62) 034900 ms ether(s=000feafc0dbe d=00095bdb3254 pr=0800 ln=66) ip(s=192.168.0.99 d=68.178.211.43 id=9ca7 frag=4000 ttl= 64 pr=6 ln=52) tcp(s=42805 d=43 seq=1897121383 ack=3642134678 fl=AP win=5840 ck=d90f) dump(godaddy.com\n) 035195 ms ether(s=00095bdb3254 d=000feafc0dbe pr=0800 ln=60) ip(s=68.178.211.43 d=192.168.0.99 id=34d7 frag=0000 ttl=111 pr=6 ln=40) tcp(s=43 d=42805 seq=3642134678 ack=1897121395 fl=A win=65523 ck=8e62) 035265 ms ether(s=00095bdb3254 d=000feafc0dbe pr=0800 ln=1434) ip(s=68.178.211.43 d=192.168.0.99 id=3504 frag=0000 ttl=111 pr=6 ln=1420) tcp(s=43 d=42805 seq=3642134678 ack=1897121395 fl=A win=65523 ck=a8b6) dump(The data contained in GoDaddy.co) Plan 9 ignores the zero length window and sends a single byte (2456ms), causing godaddy to hang up (2493ms). cpu% snoopy -N 1500 -f 'tcp(sd=43)' /net/ether1 after optimize: ether(ip(tcp(sd = 43))) 002343 ms ether(s=0004238ecb1a d=0007b3f12c00 pr=0800 ln=62) ip(s=18.26.4.98 d=68.178.211.43 id=9330 frag=0000 ttl=255 pr=6 ln=48) tcp(s=32619 d=43 seq=1578393267 ack=0 fl=S win=65535 ck=1767 opt4=(mss 1460) opt3=(wscale 3) opt=NOOP) 002418 ms ether(s=0007b3f12c00 d=0004238ecb1a pr=0800 ln=64) ip(s=68.178.211.43 d=18.26.4.98 id=9330 frag=0000 ttl=223 pr=6 ln=40) tcp(s=43 d=32619 seq=2734158449 ack=1578393268 fl=AS win=0 ck=afb0) 002437 ms ether(s=0004238ecb1a d=0007b3f12c00 pr=0800 ln=60) ip(s=18.26.4.98 d=68.178.211.43 id=9339 frag=0000 ttl=255 pr=6 ln=40) tcp(s=32619 d=43 seq=1578393268 ack=2734158450 fl=AP win=65535 ck=afa9) 002456 ms ether(s=0004238ecb1a d=0007b3f12c00 pr=0800 ln=60) ip(s=18.26.4.98 d=68.178.211.43 id=933a frag=0000 ttl=255 pr=6 ln=41) tcp(s=32619 d=43 seq=1578393268 ack=2734158450 fl=A win=65535 ck=48b0) dump(g) 002493 ms ether(s=0007b3f12c00 d=0004238ecb1a pr=0800 ln=64) ip(s=68.178.211.43 d=18.26.4.98 id=9339 frag=0000 ttl=223 pr=6 ln=40) tcp(s=43 d=32619 seq=2734158450 ack=1578393268 fl=AR win=65535 ck=afad) The source is in /sys/src/9/ip/tcp.c. Have fun. Russ