[9fans] telnet vs. godaddy whois - Plan9

This is a discussion on [9fans] telnet vs. godaddy whois - Plan9 ; 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...

+ Reply to Thread
Page 1 of 3 1 2 3 LastLast
Results 1 to 20 of 48

Thread: [9fans] telnet vs. godaddy whois

  1. [9fans] telnet vs. godaddy whois

    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



  2. Re: [9fans] telnet vs. godaddy whois

    > 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



  3. Re: [9fans] telnet vs. godaddy whois

    > Plan 9 ignores the zero length window and sends a single byte (2456ms),
    > causing godaddy to hang up (2493ms).


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



  4. Re: [9fans] telnet vs. godaddy whois

    On Wed, Apr 16, 2008 at 9:46 AM, Charles Forsyth wrote:
    > > Plan 9 ignores the zero length window and sends a single byte (2456ms),
    > > causing godaddy to hang up (2493ms).

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


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

    Captor embedded, QNX 4.X

    Ian


  5. Re: [9fans] telnet vs. godaddy whois

    > > Plan 9 ignores the zero length window and sends a single byte (2456ms),
    > > causing godaddy to hang up (2493ms).

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


    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


  6. Re: [9fans] telnet vs. godaddy whois

    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


  7. Re: [9fans] telnet vs. godaddy whois

    On Wed, 16 Apr 2008 12:04:23 PDT "ron minnich" wrote:
    > 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.


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

    Here is part of the plan9 trace Russ posted:
    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)

    See RFC793, page 4, last para:
    TCP provides a means for the receiver to govern the amount of data
    sent by the sender. This is achieved by returning a "window" with
    every ACK indicating a range of acceptable sequence numbers beyond
    the last segment successfully received. The window indicates an
    allowed number of octets that the sender may transmit before
    receiving further permission.


  8. Re: [9fans] telnet vs. godaddy whois

    > On Wed, 16 Apr 2008 12:04:23 PDT "ron minnich" wrote:
    >> 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.

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



  9. Re: [9fans] telnet vs. godaddy whois

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


    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.



  10. Re: [9fans] telnet vs. godaddy whois

    > read the section of the rfc i mentioned earlier. it probably ought to probe
    > only after a retransmission timeout period


    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/l...l_papers/lin.a


  11. Re: [9fans] telnet vs. godaddy whois

    > > read the section of the rfc i mentioned earlier. it probably ought to probe
    > > only after a retransmission timeout period

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


    That's the behaviour that's suggested in Stevens' TCP/IP Illustrated,
    Volume 1. The relevant section is post (legally?) here:
    http://www.uic.rsu.ru/doc/inet/tcp_stevens/tcp_pers.htm


  12. Re: [9fans] telnet vs. godaddy whois

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

    i cannot think of a sensible reason it should do that: it seems more work for the receiver,
    to run an extra timer to time the probes. even when the probes are based on the retransmission
    timer they could easily occur on the order of tens or hundreds of microseconds on some networks.
    you don't want something as big as 5 seconds because the window-opening packet might
    have been zapped, and who wants 5 second delays because of that?
    it's not for nothing that rfc793 and rfc1122 say what they do.


  13. Re: [9fans] telnet vs. godaddy whois

    On Wed, 16 Apr 2008 21:49:26 BST Charles Forsyth wrote:
    > > Er... "correct" seems a bit strong. Why is Plan9 sending one
    > > byte of data when it knows the receiver's window is closed?

    >
    > 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 va
    > lue,
    > and can be short. very short. and plan 9 is positively curt, so it's just
    > typical that others should then complain.


    RFC1122 page 92 says

    The transmitting host SHOULD send the first zero-window
    probe when a zero window has existed for the retransmission
    timeout period (see Section 4.2.2.15), and SHOULD increase
    exponentially the interval between successive probes.

    Implementations other than Plan 9's certainly seem to wait
    much longer than 19ms before the first probe. RFC1122
    suggests initializing RTO to 3 seconds and then adjusting it.

    Anyway, what I really wanted to say was that somehow
    "correctness" is not what comes to mind first when thinking
    about TCP! The important question is whether your
    implementation interoperates with the ones your users care
    about (or must deal with even if buggy).


  14. Re: [9fans] telnet vs. godaddy whois

    > The transmitting host SHOULD send the first zero-window
    > probe when a zero window has existed for the retransmission
    > timeout period (see Section 4.2.2.15), and SHOULD increase
    > exponentially the interval between successive probes.


    that first part requires an action in a given case, to ensure it is done (the
    context is given by some preceding text not quoted here). it doesn't specify
    all cases in which it might be done.

    having said that, i now suspect that sending one byte into a zero-window is not the problem.



  15. Re: [9fans] telnet vs. godaddy whois

    > having said that, i now suspect that sending one byte into a zero-window is not the problem.

    because the one-byte probe can only be done if there is data to send, and i already knew that
    a plain connection (dial only) to that port also failed:

    014045 ms
    ether(s=000e2e32f2a6 d=00a0cc3cd49b pr=0800 ln=62)
    ip(s=144.32.112.70 d=68.178.211.43 id=d002 frag=0000 ttl=255 pr=6 ln=48)
    tcp(s=59115 d=43 seq=3422370319 ack=0 fl=S win=65535 ck=7fb6 opt4=(mss 1460) opt3=(wscale 0) opt=NOOP)
    014201 ms
    ether(s=00a0cc3cd49b d=000e2e32f2a6 pr=0800 ln=60)
    ip(s=68.178.211.43 d=144.32.112.70 id=d002 frag=0000 ttl=223 pr=6 ln=40)
    tcp(s=43 d=59115 seq=2009405788 ack=3422370320 fl=AS win=0 ck=1948)
    014205 ms
    ether(s=000e2e32f2a6 d=00a0cc3cd49b pr=0800 ln=60)
    ip(s=144.32.112.70 d=68.178.211.43 id=d005 frag=0000 ttl=255 pr=6 ln=40)
    tcp(s=59115 d=43 seq=3422370320 ack=2009405789 fl=AP win=65535 ck=1941)
    014342 ms
    ether(s=00a0cc3cd49b d=000e2e32f2a6 pr=0800 ln=60)
    ip(s=68.178.211.43 d=144.32.112.70 id=d005 frag=0000 ttl=223 pr=6 ln=40)
    tcp(s=43 d=59115 seq=2009405789 ack=3422370320 fl=AR win=65535 ck=1945)



  16. Re: [9fans] telnet vs. godaddy whois

    On Thu, 17 Apr 2008 09:18:31 BST Charles Forsyth wrote:
    > > having said that, i now suspect that sending one byte into a zero-window is

    > not the problem.
    >
    > because the one-byte probe can only be done if there is data to send, and i
    > already knew that a plain connection (dial only) to that port also failed:


    Not setting the PSH bit on a pure ACK (== no data is being
    sent) seems to fix this (see ip/tcp.c around line 2530). May
    be it tickles a bug on the receiver (0 byte read?).


  17. Re: [9fans] telnet vs. godaddy whois

    > On Thu, 17 Apr 2008 09:18:31 BST Charles Forsyth wrote:
    >> > having said that, i now suspect that sending one byte into a zero-window is

    >> not the problem.
    >>
    >> because the one-byte probe can only be done if there is data to send, and i
    >> already knew that a plain connection (dial only) to that port also failed:

    >
    > Not setting the PSH bit on a pure ACK (== no data is being
    > sent) seems to fix this (see ip/tcp.c around line 2530). May
    > be it tickles a bug on the receiver (0 byte read?).


    this does work for me. is there some subtile reason *to* set the psh bit
    on a pure ack? in certain circumstances?

    good call. from rfc793, p 42:

    [...] If the the user signals a push function then the
    data must be sent even if it is a small segment.

    minooka; 9diff ip/tcp.c
    /n/sources/plan9//sys/src/9/ip/tcp.c:2529,2535 - ip/tcp.c:2529,2535
    }
    }

    - if(sent+dsize == sndcnt)
    + if(sent+dsize == sndcnt && dsize)
    seg.flags |= PSH;

    /* keep track of balance of resent data */

    - erik



  18. Re: [9fans] telnet vs. godaddy whois

    >> On Thu, 17 Apr 2008 09:18:31 BST Charles Forsyth wrote:
    >>> > having said that, i now suspect that sending one byte into a zero-window is
    >>> not the problem.
    >>>
    >>> because the one-byte probe can only be done if there is data to send, and i
    >>> already knew that a plain connection (dial only) to that port also failed:

    >>
    >> Not setting the PSH bit on a pure ACK (== no data is being
    >> sent) seems to fix this (see ip/tcp.c around line 2530). May
    >> be it tickles a bug on the receiver (0 byte read?).

    >
    > this does work for me. is there some subtile reason *to* set the psh bit
    > on a pure ack? in certain circumstances?
    >
    > good call. from rfc793, p 42:
    >
    > [...] If the the user signals a push function then the
    > data must be sent even if it is a small segment.
    >
    > minooka; 9diff ip/tcp.c
    > /n/sources/plan9//sys/src/9/ip/tcp.c:2529,2535 - ip/tcp.c:2529,2535
    > }
    > }
    >
    > - if(sent+dsize == sndcnt)
    > + if(sent+dsize == sndcnt && dsize)
    > seg.flags |= PSH;
    >
    > /* keep track of balance of resent data */
    >
    > - erik


    I noticed this some time ago when I was doing some work in the
    stack and thought it was very questionable. But I never got a
    chance to go back and do further research. Nevertheless I think
    it's the wrong behavior.



  19. Re: [9fans] telnet vs. godaddy whois

    > I noticed this some time ago when I was doing some work in the
    > stack and thought it was very questionable. But I never got a
    > chance to go back and do further research. Nevertheless I think
    > it's the wrong behavior.


    what's the definition of `wrong' here?



  20. Re: [9fans] telnet vs. godaddy whois

    >> I noticed this some time ago when I was doing some work in the
    >> stack and thought it was very questionable. But I never got a
    >> chance to go back and do further research. Nevertheless I think
    >> it's the wrong behavior.

    >
    > what's the definition of `wrong' here?


    Meaning that the patch Eric proposed is probably the better way to
    deal with ACKs. It wasn't meant to be taken too literally though,
    hence the "I think".



+ Reply to Thread
Page 1 of 3 1 2 3 LastLast