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