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.

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

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

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

> 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

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.

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.

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

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

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

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.

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

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

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

> 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

> 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

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

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.