Theo de Raadt <[email protected]> writes:
>> If we cared more about compat with past openbsd releases, then it
>> would be -q 0, but if I'm not mistaken, we're leaning towards switching
>> behavior to be compatible with gnu netcat by default.
>
> Actually, OpenBSD nc is the incompatible one.
Just being a prick: netcat is not POSIX nor described in a RFC, afaik.
> hobbit nc did not do shutdown.
> gnu nc does not do shutdown.
GNU nc states: "Goals of this project are full compatibility with the
original nc 1.10 that is widely used, and portability." Sure it behaves
the same as hobbit nc. But hobbit nc didn't have -q nor -N to override
the default behaviour, so why would it be the reference on this
particular point?
> FreeBSD is considering not doing nc, either, or at least that is
> what their "-q" flag was for.
I don't know what FreeBSD does with or without -q, but they seem to
closely follow upstream and in the few mails I read from their hackers
mailing-list they don't seem to have cared about this detail.
> Debian people are upset about it too, and if we change this to
> no shutdown() by default, we'll do everyone a favor.
Looking at the bugreports for netcat-openbsd doesn't lead me to that
conclusion. They'd rather ask why upstream went on using -N instead
of -q -1.
* Quit immediately after EOF if -q is not given (i.e. make the default
equivalent to -q 0). This is the standard upstream behavior and what
other Linux distributions use. It is different from netcat-traditional,
but compatibility with other versions of OpenBSD netcat is more
important. (Closes: #502188)
> Look at it this way. Truncated output from some query is the worst
> case -- it is a mysterious "sometimes you get scewed" behaviour.
> By default, I want to get the maximum.
It all depends on the protocol / applications used, IMHO. What about
servers that expect the client to close their writing side of the
socket before processing a query? They'd use a timeout so that they
don't get hung, close the socket and netcat would have received zero
bytes. You get the minimum. Perhaps is that better than a random amount
of data, but who said using netcat to reliably get data was a good idea
in the first place?
About transferring data, if we go this way we'll have to change our
manpage: sections CLIENT/SERVER MODEL and DATA TRANSFER will be
incorrect. It's sad, because I can remember when I was using Debian,
I was shown how to transfer data using only nc, on a LAN. I could
receive data fine, but it seemed I couldn't send data, nc appeared to be
blocked. My friend was using OpenBSD netcat, I was using Hobbit's. We
both felt that OpenBSD was doing the right thing. That was the first
time I had heard about this OS. *tears*
> If I encounter a service that hangs at end of output, I can use the
> -N flag, and then I am satisfied.
Debian have already changed twice the default behaviour of their -q
switch, they'll gladly switch back if we do, right...? So I see no
reason to introduce -N here, I'd rather have -q.
> One of these situation has spurious data loss; the other has a
> visible "hang" that you can see happening, and then resolve using
> a flag.
IMHO data transferred using netcat should be less valuable than people's
time investigating why their network / daemon is behaving badly.
Who would first think that netcat may not behave like cat(1)?
BTW, I saw the comment added to last netcat.c revision, I think '-l'
should survive an accept(2) error if '-k' is provided and errno is
ECONNABORTED.
Thanks/sorry if you read my bikeshedding this far. :)
Ciao,
--
Jérémie Courrèges-Anglas
GPG Key fingerprint: 61DB D9A0 00A4 67CF 2A90 8961 6191 8FBF 06A1 1494
