Posted Jul 16, 2009 22:10 UTC (Thu) by fyodor (guest, #3481)
[Link]
Good question. I have always loved Hobbit's original netcat, but it hasn't been maintained in more than a decade and it is missing modern features. Our Ncat is cross-platform (even us Linux devotees need to use or debug something on Windows or Mac once in a while) and offers things like SSL encryption, IPv6, a neat "connection brokering" feature for connecting machines behind NAT gateways, socks/http proxy (and proxy chaining) support, and many other goodies. We wrote a details Ncat Users' Guide detailing common tasks that are easier with Ncat.
Nmap 5.00 released
Posted Jul 16, 2009 22:58 UTC (Thu) by foom (subscriber, #14868)
[Link]
Hm, two things I use that seems to be missing in ncat vs. the nc available on debian:
-q secs quit after EOF on stdin and delay of secs
-k set keepalive option on socket
The -q argument is somewhat like ncat's --send-only, except that it allows receiving data too, as
long as you haven't closed stdin yet. I use that one a fair bit. Generally as -q0. I want the client to
be able to send and receive data, but to be in control of closing the connection.
The -k option is pretty self-explanatory -- it's useful when you're going through firewalls.
Although really, I don't know why SO_KEEPALIVE isn't just on by default in the network
stack with a timeout of 8 minutes, these days...
Nmap 5.00 released
Posted Jul 17, 2009 8:26 UTC (Fri) by tialaramex (subscriber, #21167)
[Link]
On the SO_KEEPALIVE issue, some of us don't have broken networks, and the constant pressure to give in and put every node on the Internet the other side of two layers of amateur hour NAT and have it only ever sort-of work with HTTP and nothing else is exactly the sort of thing that gives us a headache.
One of the things we should have learned from the "browser wars" era web experience is that meekly going along with whatever craziness is currently dominant doesn't get you progress, just more pain. The standard says your TCP connection doesn't need keep alive packets, so there's no reason to send them by default.
More practically, if I have a quiescent connection, and I pull the rug out from under it, then put the rug back before using it, I expect it not to notice. With SO_KEEPALIVE the OS will notice and drop the connection. So forcing SO_KEEPALIVE throws away a feature I use. No thanks.
Nmap 5.00 released
Posted Jul 17, 2009 9:08 UTC (Fri) by tzafrir (subscriber, #11501)
[Link]
netcat and similar tools are one of those things that should also be usable on broken networks, if possible.
Nmap 5.00 released
Posted Jul 21, 2009 9:49 UTC (Tue) by tialaramex (subscriber, #21167)
[Link]
and so netcat has a flag to set this socket option. I'm happy with that. What I was reacting adversely to was the suggestion that keepalive should be the default.
Nmap 5.00 released
Posted Jul 17, 2009 15:05 UTC (Fri) by foom (subscriber, #14868)
[Link]
I dearly wish the majority of NAT gateways and firewalls out there didn't drop TCP connections after
10 minutes of inactivity. But they do. It sucks, yes. But that's what's out there...
My home NAT (linksys) did this. (until I replaced it with a linux box). And a non-natting
firewall (Cisco, I think) at my workplace does this between certain internal networks!
I'm sure glad you have a non-broken network, but a great many people don't.
Nmap 5.00 released
Posted Jul 17, 2009 17:30 UTC (Fri) by dlang (✭ supporter ✭, #313)
[Link]
if firewalls (including NAT devices) didn't drop info about the connection after some period of inactivity you would have the equivalent of a memory leak because a system crash or reboot would leave the device 'tracking' a connection that the endpoint no longer knows about, and will never close.
routers and firewalls don't have infinite resources, so if you never timeout 'idle' connections you will eventually crash instead and take out everything
Nmap 5.00 released
Posted Jul 19, 2009 9:21 UTC (Sun) by dankamongmen (subscriber, #35141)
[Link]