Re: [9fans] telnet vs. godaddy whois
And it will continue to regress until one knowledgeable and independent human being serves as final arbiter of standards. i think some of it eventually will be formalised, much as we do with programming languages (even Javascript, which i mentioned, at least has a plausible grammar), but it seems we still haven't got a suitable tool to do it (or at least, not one that enough people use without fuss). even then a formalised version of something can still have (more formal) bugs, that fail to express an intention correctly. anyway, just to be helpful: Bakul is right that as in Erik's case, for networked applications particularly, you end up having to be pragmatic when talking to other implementations. for example, the (old) Mac POP3 client demanded a space at a certain point, even when there was no argument (required by the POP3 RFC). most other server implementations included something chatty there, and the POP3 client implementation had followed the servers, not the RFC.
Re: [9fans] telnet vs. godaddy whois
erik quanstrom wrote: Charles Forsyth wrote: computing is needlessly regressing. And it will continue to regress until one knowledgeable and independent human being serves as final arbiter of standards. good idea. why don't you ask ken? - erik We'll ask someone, if and when osmio.org becomes osmio.int.
Re: [9fans] telnet vs. godaddy whois
having looked again at ip/tcp.c i think the code wasn't really intending to resolve one of the stalled receiver cases i had in mind, although it happens to do so, so changing it probably doesn't mess up some original intent. mind you, one lesson i take from all this is that in retrospect one could expect just about anything from a server run by a company like godaddy that completely misses the point about black leather jackets. (they look cool only if you don't scribble adverts all over them.)
Re: [9fans] telnet vs. godaddy whois
On Thu, 17 Apr 2008 09:18:31 BST Charles Forsyth [EMAIL PROTECTED] 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?).
Re: [9fans] telnet vs. godaddy whois
Because of this what is likely happening is that on receiving the PSH bit read() completes and returns to the caller app with a count = 0 which the app must think indicates EOF! that behaviour (by the remote) is correct?
Re: [9fans] telnet vs. godaddy whois
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. what's the definition of `better' here? well, i won't persist in pedantry. i was just curious about the rationale for the adjectives. i'd say it isn't really to do with ACKs: the protocol definition rightly has ACK and PSH interpreted by different sides at the destination: input for ACK and output for PSH. in fact, the Plan 9 behaviour is rational for a sluggish or zero window: the receiving side might delay delivering data to the application until a PSH, but won't open the window if that queue is full. (thus rfc1122 mutters about deadlock in the absence of PSH, in 4.2.2.2.)
Re: [9fans] telnet vs. godaddy whois
rfc 742 p. 42 says [...] If the the user signals a push function then the data must be sent even if it is a small segment. by illegal i mean goes contrary to an rfc must. perhaps i'm missing something. i don't see how what was sent is contrary to that requirement. sensible as setting PSH on a pure ACK. i don't understand this reference to a `pure' ACK. it's an ACK! in TCP/IP every packet after SYN must have an ACK (or that really is -- explicitly -- illegal). the ACK and PSH have nothing to do with each other. in fact, the receiver isn't handling the PSH oddly because it's associated with an ACK, but because it misinterpreted the standard, or the standard isn't clear.
Re: [9fans] telnet vs. godaddy whois
rfc 742 p. 42 says [...] If the the user signals a push function then the data must be sent even if it is a small segment. by illegal i mean goes contrary to an rfc must. perhaps i'm missing something. i don't see how what was sent is contrary to that requirement. sensible as setting PSH on a pure ACK. i don't understand this reference to a `pure' ACK. it's an ACK! in TCP/IP every packet after SYN must have an ACK (or that really is -- explicitly -- illegal). the ACK and PSH have nothing to do with each other. in fact, the receiver isn't handling the PSH oddly because it's associated with an ACK, but because it misinterpreted the standard, or the standard isn't clear. By pure I assume he meant an ACK with no data, which is what I also meant by plain ACK. But I agree with Charles here. After going back over the related sections of the RFC I don't see how this behavior violates anything in the standard. It's just not very common, and obviously not interpreted very well by this particular endpoint. Has anybody ever experienced this problem before with any of there P9 systems? I haven't.
Re: [9fans] telnet vs. godaddy whois
to be fair, this is one reason a few programming languages have non-trivial validation suites, much of which check probable or historical misunderstandings, and those suites are usually too small. it takes a fair amount of back-and-forth through the natural language text to build a supposedly complete specification. the TCP/IP specification is tricky, partly because it suggests a programming interface as well, which isn't quite the one that most people use today. it's not just us: RFC1144 notes `PUSH' is a curious anachronism considered indispensable by certain members of the Internet community. Since PUSH can (and does) change in any datagram, an information preserving compression scheme must pass it explicitly.
Re: [9fans] telnet vs. godaddy whois
Has anybody ever experienced this problem before with any of there P9 systems? I haven't. not this particular problem, but years ago i had problems with plan 9 or perhaps it was inferno (originally) not implementing the window test correctly (leading to a RST storm with an incorrect AIX implementation), and difficulty talking to implementations that completely screwed up the handling of the wrap-around sequence number space, leading to needless disconnects depending on initial sequence number. one was a tcp/ip implementation that's still popular in the embedded space.
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 45155AC3) 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= 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= 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= 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= 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= 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= 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= 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= 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= 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
