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 Mon, 21 Apr 2008 17:49:35 EDT erik quanstrom <[EMAIL PROTECTED]> wrote: > > I meant this: > > /* Pull out data to send */ > > bp = nil; > > if(dsize != 0) { > > bp = qcopy(s->wq, dsize, sent); > > if(BLEN(bp) != dsize) { > > seg.flags |= FIN; > > dsize--; > > } > > if(sent+dsize == sndcnt) > > seg.flags |= PSH; > > } > > > > Seems clearer to me. And equivalent! I have been running > > with this change since last Thursday. I don't stress my plan9 > > machine all that much but replica pulls, ftp, web browsing, > > nfs etc. have worked fine. > > i think they are not equivalent with these values > > BLEN(bp) != dsize > dsize == 1 > sent+0 == sndcnt I don't think all three conditions can be true. dsize is set to ssize, ssize is initialized to sndcnt - sent and after that it can only decrease. So if dsize is 1, sndcnt - send must be at least 1.
Re: [9fans] telnet vs. godaddy whois
On Mon, 21 Apr 2008 22:24:35 BST Charles Forsyth <[EMAIL PROTECTED]> wrote: > > must not buffer data indefinitely, and (2) MUST set the > > PSH bit in the last buffered segment (i.e., when there > > is no more queued data to be sent). > > > > The implication is that the "preceding segment" to a pkt with > > no data *will have* PSH set. > > so does the implementation do that? Do you mean plan9 after the change? The traces I looked at seem to do that. Others certainly seem to do that. > can you prove it in all cases? Not in the formal sense. Not enough free time or incentive. > what will break if we just change it without knowing? > after all, it has been 15 years to come across a botched receiver's implement > ation > of PSH (ie, godaddy's) which is the only reason to change it. > that's what i was pointing out. i could do the work myself, i suppose, but i > haven't got the incentive. I understand your concern about possibly breaking things with this change. It should certainly be tested more thoroughly but since the change brings Plan9 behavior more in line with what *BSD/Linux/Windows do I am not as apprehensive as you are. > >here you have to be compatible with existing > >implementations as far as possible (in order to maximize > >interoperability). > > i suspect arguments like that caused the current situation with HTML, CSS and > Javascript. > computing is needlessly regressing. May be. Somehow this makes me think of E W Dijkstra :-)
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
> 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
> I meant this: > /* Pull out data to send */ > bp = nil; > if(dsize != 0) { > bp = qcopy(s->wq, dsize, sent); > if(BLEN(bp) != dsize) { > seg.flags |= FIN; > dsize--; > } > if(sent+dsize == sndcnt) > seg.flags |= PSH; > } > > Seems clearer to me. And equivalent! I have been running > with this change since last Thursday. I don't stress my plan9 > machine all that much but replica pulls, ftp, web browsing, > nfs etc. have worked fine. i think they are not equivalent with these values BLEN(bp) != dsize dsize == 1 sent+0 == sndcnt - erik
Re: [9fans] telnet vs. godaddy whois
> 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
Re: [9fans] telnet vs. godaddy whois
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.
Re: [9fans] telnet vs. godaddy whois
> must not buffer data indefinitely, and (2) MUST set the > PSH bit in the last buffered segment (i.e., when there > is no more queued data to be sent). > > The implication is that the "preceding segment" to a pkt with > no data *will have* PSH set. so does the implementation do that? can you prove it in all cases? what will break if we just change it without knowing? after all, it has been 15 years to come across a botched receiver's implementation of PSH (ie, godaddy's) which is the only reason to change it. that's what i was pointing out. i could do the work myself, i suppose, but i haven't got the incentive. >here you have to be compatible with existing >implementations as far as possible (in order to maximize >interoperability). i suspect arguments like that caused the current situation with HTML, CSS and Javascript. computing is needlessly regressing.
Re: [9fans] telnet vs. godaddy whois
On Mon, 21 Apr 2008 21:19:33 BST Charles Forsyth <[EMAIL PROTECTED]> wrote: > > But in any case setting PSH on a > > packet with no data serves no real purpose. > > i think that's incorrect: it ensures a push of any data that is already buffe > red but un-pushed > (ie, the immediately preceding segment had no PSH, and the receiver's impleme > ntation buffers > accordingly). Other major implementations don't set PSH on a pkt with no data so clearly they don't agree with you. Here's why: According to rfc1122 page 83, The PSH bit is not a record marker and is independent of segment boundaries. The transmitter SHOULD collapse successive PSH bits when it packetizes data, to send the largest possible segment. A TCP MAY implement PUSH flags on SEND calls. If PUSH flags are not implemented, then the sending TCP: (1) must not buffer data indefinitely, and (2) MUST set the PSH bit in the last buffered segment (i.e., when there is no more queued data to be sent). The implication is that the "preceding segment" to a pkt with no data *will have* PSH set. > part of the problem with the continued specification of protocols, even 30 > years on, as `formal' english text is that it can appear to be ambiguous when > it's just subtly precise. that's why i had to say `i think' as opposed to QED Indeed. One point to note is that RFCs (at least used to) document existing implementations but some times not everything is documented clearly and precisely. Unlike programming language implementations where things left undefined by the specification can be implemented however you wish, here you have to be compatible with existing implementations as far as possible (in order to maximize interoperability).
Re: [9fans] telnet vs. godaddy whois
> But in any case setting PSH on a > packet with no data serves no real purpose. i think that's incorrect: it ensures a push of any data that is already buffered but un-pushed (ie, the immediately preceding segment had no PSH, and the receiver's implementation buffers accordingly). part of the problem with the continued specification of protocols, even 30 years on, as `formal' english text is that it can appear to be ambiguous when it's just subtly precise. that's why i had to say `i think' as opposed to QED
Re: [9fans] telnet vs. godaddy whois
> psh might be harder to understand than preserving message boundaries, but, > hey, > it's less useful and easier to get wrong. absolutely! worrying, isn't it.
Re: [9fans] telnet vs. godaddy whois
> But in any case setting PSH on a > packet with no data serves no real purpose. i think that's incorrect: it ensures a push of any data that is already buffered but un-pushed (ie, the immediately preceding segment had no PSH, and the receiver's implementation buffers accordingly). part of the problem with the continued specification of protocols, even 30 years on, as `formal' english text is that it can appear to be ambiguous when it's just subtly precise. that's why i had to say `i think' as opposed to QED
Re: [9fans] telnet vs. godaddy whois
> `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. psh might be harder to understand than preserving message boundaries, but, hey, it's less useful and easier to get wrong. - erik
Re: [9fans] telnet vs. godaddy whois
On Mon, 21 Apr 2008 10:56:42 EDT erik quanstrom <[EMAIL PROTECTED]> wrote: ... > bwc points out that godaddy's behavior is very likely a violation of the rfc. I am not convinced any rfc covers this situation - it may be that their tcp layer does the right thing and the bug is at the application level. But in any case setting PSH on a packet with no data serves no real purpose. *BSD, Linux and Windows don't set PSH on such packets either. > it was suggested that the } was prehaps misplaced. i think this is not > correct as the preceeding if modifieds dsize so i believe the ifs need to be > seperate. I meant this: /* Pull out data to send */ bp = nil; if(dsize != 0) { bp = qcopy(s->wq, dsize, sent); if(BLEN(bp) != dsize) { seg.flags |= FIN; dsize--; } if(sent+dsize == sndcnt) seg.flags |= PSH; } Seems clearer to me. And equivalent! I have been running with this change since last Thursday. I don't stress my plan9 machine all that much but replica pulls, ftp, web browsing, nfs etc. have worked fine.
Re: [9fans] telnet vs. godaddy whois
> i can only assume that they are trying to > defend against some sort of dos attack. perhaps someone has a better > suggestion? it depends what they actually are running on that machine. i've seen several broken tcp/ip implementations in embedded systems. fairly often they mess up handling of the sequence number space, including one that's (apparently) commonly used in consumer devices. a stream of back-to-back acks would cause systems enough work with or without the PSH so it's hard to see what DOS could be involved. i think it's more likely whoever wrote it misread the spec, or simply made a mistake when coding it. >is there something in particular that you suspect to misbehave? to answer an earlier question, i think not setting PSH on a forced ACK will make no difference provided the previous segment is (always) guaranteed to have PSH set, and no intervening node removes that PSH (for instance by having failed to read the TCP/IP compression spec carefully enough). otherwise you might need the PSH to nudge a remote receiver that implements PSH as part of its buffering scheme. there isn't much to be done about the second case (since it involves other systems) but you'd need to check that plan 9's implementation will always set PSH on the last-sent segment in the case(s) where one of those forced ACKs would occur. PSH isn't interpreted by (most) unix-like systems because their buffering scheme doesn't need it (they typically queue data as it's received). if someone were to implement rfc793's suggestion then they would need it, or the data will sit unread, which can mess up higher-level protocols. it's an old contentious topic: the tcp/ip compression rfc1144 grumbles `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
On Thu Apr 17 19:07:09 EDT 2008, [EMAIL PROTECTED] wrote: > anyway, perhaps the more important question, at least for erik, is: will > his change cause trouble elsewhere? unfortunately, we don't know, but we'll > see how he gets along! > not setting the PSH bit when there's no data does fix the problem and has run for several days on some well-used machines without causing any issues with telnet, http, smtp, srv, cpu, import -E ssl &c. i would be surprised if the change caused any problem between plan 9 machines as the PSH bit may be set but is never tested. bwc points out that godaddy's behavior is very likely a violation of the rfc. while the PSH bit may be mistaken, compliant implementations are supposed to be liberal with what they accept. i can only assume that they are trying to defend against some sort of dos attack. perhaps someone has a better suggestion? it was suggested that the } was prehaps misplaced. i think this is not correct as the preceeding if modifieds dsize so i believe the ifs need to be seperate. /n/sources/plan9//sys/src/9/ip/tcp.c:2529,2535 - tcp.c:2529,2535 } } - if(sent+dsize == sndcnt) + if(sent+dsize == sndcnt && dsize) seg.flags |= PSH; /* keep track of balance of resent data */ - erik
Re: [9fans] telnet vs. godaddy whois
anyway, perhaps the more important question, at least for erik, is: will his change cause trouble elsewhere? unfortunately, we don't know, but we'll see how he gets along!
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
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
>> 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
> 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
>> 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.) My rationale was the section of the rfc that Eric quoted with his patch, which seemed to address my earlier suspicions. But I just went back over that section and realize that I misinterperted that quote a little. So I don't believe that P9's behavior is "wrong" in the sense that's it's violating any assumptions in the rfc. It is (I think) the first time I've seen PSH being set on a plain ACK, but I do understand your argument.
Re: [9fans] telnet vs. godaddy whois
>> if we've sent an illegal packet, can we say any behaviour on >> the remote end is incorrect? > > that packet is by no means `illegal'. 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. - erik
Re: [9fans] telnet vs. godaddy whois
On Thu, 17 Apr 2008 22:49:02 BST Charles Forsyth <[EMAIL PROTECTED]> wrote: > > 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? First, I am just speculating -- I have no idea what they are running -- but if this is what happens, it is about as sensible as setting PSH on a pure ACK. In a later email you say: > 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.) I think you are referring to An application program is logically required to set the PUSH flag in a SEND call whenever it needs to force delivery of the data to avoid a communication deadlock. Note the phrase "to force delivery of the data". There is no data to be sent in the case we are discussing. If you were to set PSH when you send 1 byte (or more) to probe a closed window that'd be fine but not with a pure ACK. So I read it differently.
Re: [9fans] telnet vs. godaddy whois
> if we've sent an illegal packet, can we say any behaviour on > the remote end is incorrect? that packet is by no means `illegal'.
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? if we've sent an illegal packet, can we say any behaviour on the remote end is incorrect? - erik
Re: [9fans] telnet vs. godaddy whois
FreeBSD 5.0-CURRENT (which is old, but one i've got) didn't work with echo | telnet godaddy either, although i haven't traced that yet. it's the same on my powerpc mac, though. there's another tcp subtlety that could cause that though, assuming it's not just telnet getting in the way.
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
On Thu, 17 Apr 2008 15:29:42 EDT erik quanstrom <[EMAIL PROTECTED]> wrote: > > On Thu, 17 Apr 2008 09:18:31 BST Charles Forsyth <[EMAIL PROTECTED]> w > rote: > >> > 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? While I wouldn't call it "wrong" it seems silly to set the PSH bit when no data is being sent. See rfc1122 section 4.2.2.2. Among other things it says: At the receiver, the PSH bit forces buffered data to be delivered to the application (even if less than a full buffer has been received). 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! May be this behavior in plan9 is due to a misplaced right brace? Move the closing brace on line 2530 to below the PSH bit logic and all is fine.
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
>> 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".
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?
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?). > > 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.
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?). 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
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
> 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= 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= 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= 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= ttl=223 pr=6 ln=40) tcp(s=43 d=59115 seq=2009405789 ack=3422370320 fl=AR win=65535 ck=1945)
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.
Re: [9fans] telnet vs. godaddy whois
On Wed, 16 Apr 2008 21:49:26 BST Charles Forsyth <[EMAIL PROTECTED]> 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).
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.
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
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/library/proceedings/bos94/full_papers/lin.a
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.
Re: [9fans] telnet vs. godaddy whois
> On Wed, 16 Apr 2008 12:04:23 PDT "ron minnich" <[EMAIL PROTECTED]> 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.
Re: [9fans] telnet vs. godaddy whois
On Wed, 16 Apr 2008 12:04:23 PDT "ron minnich" <[EMAIL PROTECTED]> 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= 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) 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.
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
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
Re: [9fans] telnet vs. godaddy whois
On Wed, Apr 16, 2008 at 9:46 AM, Charles Forsyth <[EMAIL PROTECTED]> 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
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)
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
[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