Hi Theo,
On 06/23/11 18:30, Theo de Raadt wrote:
...
I've noticed that some daemons behave
differently because of this, i.e., they won't return any data although
they are still allowed to send data.
Yes, those daemons are broken. Their select/poll loops are unaware
that writeability and readability of a socket is independent.
One of the reasons that netcat should do be doing this, is so that
such bugs can be triggered. It is a good thing for them to be
triggered. The half-open socket semantics are "the real world" and
they happen all the time.
yes, you're right.
I've noticed that the behavior is different while doing some work
related stuff with some server software which is proprietary and buggy
-- and it probably will never get fixed...
The irony is that testing buggy software worked only with buggy software
in this particular case.
I think both variants are allowed in RFC 793. Would it make sense to add
a further option to nc(1) which allows to toggle between both variants?
There is no variation. Sockets can be half-closed. Sure, a particular
client or server could leave it open until completely, but now you are
testing less. You are saying it is a variation when you use less than
full functionality of a socket? That's not a variation. It's called a
subset.
But I think your real problem is that GNU netcat is incompatible. Typical.
My "problem" was related to the server side. I needed GNU netcat in
order to trigger (possibly even more buggy) responses from the (buggy)
server side. My particular use case was not about right or wrong but
about triggering some stuff on the server side.
I'm aware that the current behavior of nc(1) is the intended way to
handle TCP sessions according to RFC 793. I was not sure if the GNU
variant is actually non-compliant.
Regards
Andreas
