From mboxrd@z Thu Jan 1 00:00:00 1970 Message-ID: To: 9fans@9fans.net From: Charles Forsyth Date: Mon, 21 Apr 2008 16:24:32 +0100 In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Subject: Re: [9fans] telnet vs. godaddy whois Topicbox-Message-UUID: 9665ab86-ead3-11e9-9d60-3106f5b1d025 > 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.