2

Why is the following not working?

I have a freshly installed Debian 9 system. iptables is wide-open:

[···]# iptables -L
Chain INPUT (policy ACCEPT)
target     prot opt source               destination         

Chain FORWARD (policy ACCEPT)
target     prot opt source               destination         

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination

I log in on two separate consoles (well, two separate ssh logins). In one of them, I run:

[···]# nc -l 11115

Then, I go to the other console, and run:

[···]# nc localhost 11115

and I get a Connection refused error:

[···]# nc localhost 11115
localhost [127.0.0.1] 11115 (?) : Connection refused

I also tried nc 127.0.0.1 11115, tried with telnet --- always Connection refused.

On the "listening" side, I also tried nc -l localhost 11115 --- no difference.

What am I missing or doing wrong?

[EDIT]: On a CentOS 6.9 machine, the exact same commands above work as expected. Same thing on my Ubuntu 14.04 at home. I thought it may be that running as root makes nc disallow some functionality. But no, I just tried as a regular user on the Debian 9 machine, and it fails all the same. Any ideas why?

Cal-linux
  • 175
  • 1
  • 8

2 Answers2

3

There are actually four (or more?) distinct programs called nc (netcat) which are forks or rewrites of the same basic program from long ago and far away.

The default in Debian seems to be what it calls netcat-traditional, the ancient original version. I was able to reproduce this problem with netcat-traditional; listening seems very broken. It did not actually bind to a port; I could not see it listening in ss output, nor did I see it attempt to bind when running it under strace.

The other available Debian package is called netcat-openbsd, which is a currently maintained fork of the original netcat by OpenBSD developers. You should find that it works if you install this package (and you can then remove netcat-traditional).

There is yet another netcat package, which is used by Red Hat based systems, developed and maintained by Fyodor of nmap and insecure.org and other developers. It is a complete rewrite from the ground up and uses no traditional netcat or BSD netcat code. It also works properly. Its package name (on Red Hat systems) is nmap-ncat.

I've recently learned of a fourth netcat, GNU netcat, which was also a ground-up rewrite, but was abandoned in 2007. Strangely, one or two Linux distributions (such as Arch) still ship it.

Michael Hampton
  • 237,123
  • 42
  • 477
  • 940
  • Is it considered good etiquette to propose a cry of "shame to the developers/maintainers of netcat-traditional"??!!! :-) Really, people, one thing is that the original implementation was broken, and another thing is reproducing the unintended / non-specified behaviour due to whatever bugs that implementation had! Shame on you, guys!!! (and sorry, Debian, but shame on you as well for choosing an embarrassingly broken package as part of your default!). Bitterly ranting aside, thanks Michael Hampton! – Cal-linux Mar 31 '19 at 12:05
  • 1
    @Cal-linux You can try but it probably won't work. It hasn't been maintained in many years, which is why it has been tagged traditional. It was first released in 1995 and the last release 1.10 was from 2007. The developer, who only used a pseudonym, may well be dead. Who knows? – Michael Hampton Mar 31 '19 at 13:23
2

On Debian 2 packages netcat and a transitional package , that will refer to netcat-traditional

root@debian9:~# apt-cache search ^netcat
netcat - TCP/IP swiss army knife -- transitional package
netcat-traditional - TCP/IP swiss army knife
netcat-openbsd - TCP/IP swiss army knife
[../..]

When you run multiple times nc -l 11115 , nc is listening but on a random port ( seem to be random ) .

root@debian9:~# lsof -p $(pidof nc ) | grep LISTEN
nc      12734 root    3u  IPv4 11892054      0t0   TCP *:44907 (LISTEN)

In fact you can run nc -l instead of nc -l 11115 , and you will have the same behavior .

YES netcat-traditional is a old software and some simple bug are not fixed ( in your case example, missing the parameter -p PORT for listening .

You can prefer netcat-openbsd , and it will work as you expected .

root@debian9:/# lsof -p $( pidof nc ) | grep LISTEN
nc      2140 root    3u  IPv4  29855      0t0     TCP *:11115 (LISTEN)
EchoMike444
  • 449
  • 1
  • 3
  • 6
  • "_in your case example, missing the parameter **-p PORT** for listening_"; Hahahaha, one mystery solved!! In fact, the man page does explicitly say that (it lists two lines under synopsis, one shows `nc [options] host port`, one shows `nc -l -p port [options] ···`. However, I must have opened a separate terminal, which then opened on my local Ubuntu 14 machine, which has `netcat-openbsd` and not the traditional one, and the man page _explicitly states_ that "_It is an error to use this option [[the **-l** option]] in conjunction with the -p, -s, or -z options_" – Cal-linux Apr 01 '19 at 01:17