[9fans] telnet vs. godaddy whois - Plan9

This is a discussion on [9fans] telnet vs. godaddy whois - Plan9 ; On Thu, 17 Apr 2008 15:29:42 EDT erik quanstrom wrote: > > On Thu, 17 Apr 2008 09:18:31 BST Charles Forsyth w > rote: > >> > having said that, i now suspect that sending one byte into a zero-window ...

+ Reply to Thread
Page 2 of 3 FirstFirst 1 2 3 LastLast
Results 21 to 40 of 48

Thread: [9fans] telnet vs. godaddy whois

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

    On Thu, 17 Apr 2008 15:29:42 EDT erik quanstrom wrote:
    > > On Thu, 17 Apr 2008 09:18:31 BST Charles Forsyth 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.


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



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



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



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




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



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

    On Thu, 17 Apr 2008 22:49:02 BST Charles Forsyth 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.


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



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



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




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



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

    On Thu Apr 17 19:07:09 EDT 2008, forsyth@terzarima.net 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


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



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

    On Mon, 21 Apr 2008 10:56:42 EDT erik quanstrom 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.


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


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



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



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



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

    On Mon, 21 Apr 2008 21:19:33 BST Charles Forsyth 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).


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



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