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.

- erik

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...

it is probing the zero window (rfc793, section 3.7)

On Wed, Apr 16, 2008 at 9:46 AM, Charles Forsyth terzarima.net> wrote:

Not that I think that fingerprinting is definitive but nmap thinks
whois at godaddy is running:

Captor embedded, QNX 4.X

Ian

for those, like me, who have not committed 793 to memory:

"When the receiving TCP has a zero window and a segment arrives it must
still send n acknowledgment show its next expected sequence number
and current window (zero).

p. 41 near the bottom. looks like godaddy's tcp has the bug.

- erik

This is really an interesting discussion -- anybody think it could go
on the wiki? I enjoyed it anyway :-)

A good example of how correct behaviour (in this case Plan 9) can get
you spanked.

ron

On Wed, 16 Apr 2008 12:04:23 PDT "ron minnich" gmail.com> wrote:

Er... "correct" seems a bit strong. Why is Plan9 sending one
byte of data when it knows the receiver's window is closed?

Lookup TCP persist timer and window probes.

read the section of the rfc i mentioned earlier. it probably ought to probe
only after a retransmission timeout period, but that's not a predetermined value,
and can be short. very short. and plan 9 is positively curt, so it's just
typical that others should then complain.

i believe bsd-based tcp stacks also send 1-byte zero-window probes
but use a persist timer that starts at approx. 5 seconds (*)

i wonder if godaddy's tcp does not reset in that case - anyone care to verify?

(*) section 4 of
http://www.usenix.org/publications/library/proceedings/bos94/full_papers/lin.a