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 coul
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
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
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?
-
> 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
> 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;
>
> 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
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.
> 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 th
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
> 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
> 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.
> 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
> `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 pre
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 l
> 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 t
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
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!
> 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
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 co
>> 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 re
> 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.
>> 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 pedant
>> 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 go
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 remo
> 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'.
>> 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
th
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.
> 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 ju
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-byt
> 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?
>> 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?
Meanin
> 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?
>> 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
> 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 connec
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 (d
> 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=00a0c
> 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 en
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 afte
>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
> > 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'
> 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
> 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 sh
> 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... "corr
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
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
> > 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 a
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 definit
> 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)
> 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'
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
51 matches
Mail list logo
