2

I started a tcp listener using nc -l 127.0.0.1 900 and then attempted to connect to it using nc 127.0.0.1 900 when I got the connection refused error. The same happens when connecting using telnet. ufw is disabled. I don't understand how this could happen. Please throw some light onto this issue. Thanks in advance.

pathfinder
  • 25
  • 1
  • 4

1 Answers1

3

Some versions of nc has strange behavior, related with specifying of listening port and listening address. Try to run nc with -v (verbosity) option:

~# nc -v -l 127.0.0.1 900
listening on 0.0.0.0:36915 ...
^C

~# nc -v -l 127.0.0.1 -p 900
listening on 0.0.0.0:900 ...
^C

Other way to troubleshoot similar issues is checking of the listened sockets:

~# ss -tlnp | grep nc
LISTEN     0      1            *:43395   *:*      (("nc",pid=2210,fd=3))
Anton Danilov
  • 4,874
  • 2
  • 11
  • 20
  • You're welcome. So, try use the `nc -l -p ` command to . Also accept the answer if it helped. – Anton Danilov Jun 19 '19 at 16:26
  • Hi, thanks for your reply. `~# ss -tlnp | grep nc` gave the following output: `~LISTEN 0 1 0.0.0.0:39373 0.0.0.0:* users (("nc",pid=2708,fd=3))` Is the wildcard IP something to be worried about? Why is netcat behaving like this? Using plain old C socket server solved the issue. Also, `ip link` shows the state of `lo` as `UNKNOWN`, does this relate in anyway to the strange behaviour? – pathfinder Jun 19 '19 at 16:27
  • When you bind nc to `127.0.0.1`, connections can be established only from same host. In case of binding to `0.0.0.0` connection will be accepted from everywhere, so you need use the firewall to limit the access. Your issue with `nc` doesn't related with state `UNKNOWN` of `lo` interface in the `ip link` output. I don't know why `nc` behaves like this. – Anton Danilov Jun 19 '19 at 16:53