Re: [9fans] telnet vs. godaddy whois

[Charles Forsyth <forsyth@terzarima.net>]

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