Nmap Development mailing list archives

Re: ncat 5.10BETA handling of -l -p is not compatible with nc-1.10


From: Fyodor <fyodor () insecure org>
Date: Tue, 12 Jan 2010 10:38:48 -0800

On Mon, Jan 11, 2010 at 07:15:21AM +0100, Denys Vlasenko wrote:
On Monday 11 January 2010 06:22, Kris Katterjohn wrote:

If netcat clones will agree to not break compat gratuitously,
that would be a start. My netcat clone, for one, does. Yours does not.

Ncat isn't and was never intended to be a netcat clone.  It has a very
different set of features and we made the design early on not to
constrain ourselves to any particular nc baggage.  After all, if you
want the exact syntax of Hobbit's (or OpenBSD or so-called GNU) nc,
then you can use that exact version.  I understand that it can be
confusing if you expect "nc" to act one way, and it doesn't.  That is
why we decided not to even install a symlink from nc to ncat.  We
chose the name Ncat because the tool is inspired by the original
Netcat, but we weren't trying to clone Netcat.  That being said, we
didn't make gratuitous changes either.

However, it seems that many users of the Hobbit's original Netcat want
to use Ncat instead because it is maintained and portable to many
platforms, and/or because it supports modern networking features like
SSL, IPv6, and proxies.  We should certainly welcome those users, and
I'm all for adding command-line compatibility for major "nc" use cases
where we can easily do so.  We already added the "-l -p" compatibility
option you asked for, and we're open to other suggestions.  But such
users should be willing to meet us half way and learn a bit about Ncat
too.  Don't complain about every minor deviation from the syntax of
Hobbit's original nc, as cloning nc was never our intent.

I think our syntax for listening on port 123 
("ncat -l 123") is preferable to the longer "nc -l -p 123".

Because it is shorter by 3 chars? Such insignificant advantage is
not going to amuse people who would need to jump through hoops in
their scripts (checking "nc --version" and such) just in order to
open a listening socket.

I think our syntax is more intuitive to new users, and I believe it is
also common to some versions of nc.  The "-p" thing just seems obvious
to you because you learned it long ago.  But I think we have solved
this issue by documenting the new syntax while still supporting the
old one.

I heard that Fedora plans to ditch openbsd's implementation of nc
and use ncat. They are going to rename it to nc (otherwise scripts
which use nc would break).

I had not heard this.  Do you have a link?  I'm not opposed to the
idea (it is their distribution and thus their decision), but we don't
currently install an "nc -> ncat" symlink for the
compatibility-with-older-netcats reason already discussed.  But I
suppose we could consider it if nc users consider Ncat to be "close
enough", and if we wouldn't be overwriting an existing "nc".  Now that
"-l -p" is supported, I'd be interested in hearing from the
traditional nc contingent if there are other command-line or
functionality incompatibilities you find frustrating.

Cheers,
Fyodor

_______________________________________________
Sent through the nmap-dev mailing list
http://cgi.insecure.org/mailman/listinfo/nmap-dev
Archived at http://seclists.org/nmap-dev/


Current thread: