Ncat "bad file descriptor" error upon client connection

Question

Problem

I have been trying to use Ncat to view some TCP traffic on a CentOS virtual box. However, on this particular machine I can't even establish a simple server/client communication.

I open a TCP socket as a "server" or listener (forgive me if I'm mistaken on the correct terminology"

Terminal 1:

$ ncat -l 12345

Then, in a separate terminal I initiate the client connection and attempt to send a random string:

Terminal 2:

$ ncat my_hostname 13245
 <Random string to send>

This initiates the following error from my TCP "server"

Terminal 1:

close: Bad file descriptor

Terminal 2:

Ncat: Broken pipe.

I've run this exact sequence of commands via cygwin and they work fine. I'm not sure what could be causing this (unless it's the lack of root permissions? see below). Looking for something to debug. If it is root permissions or could be how can I verify that without having root permissions?

Extra (Relevant?) Information

I have run

$ Ncat my_hostname <port that I know has a TCP connection>

and it has output a lot of gibberish. Meanwhile, when I attempt to listen to the same port with tcpflow it tells me I don't have permission. So, is this perhaps just a permissions issue that Ncat isn't explicitly telling me about? I don't have root permissions on this machine so I can't test that hypothesis

Ballentine

I'm having the same issue, but running nc instead seems to work fine. Can you give that a try? – Diannediannne

@lorenzog, I tried that but still no dice. – Ballentine

Answer 1

I had the same issue. I solved the problem by specifing the protocol family version.

nc -4  // using ipv4

you can try it

Pilgarlic

that worked for me as well, using ncat instead of nc (which maybe is exactly the same thing?) Not sure, but anyway, thanks! – Ballentine

Can confirm the connection works for linux rhel 7. The command I use is: nc -l -4 <port_number> and then in the other terminal window: nc <host> <same_port_number> – Ewart

It's wired that the server failed to run nc -l also failed to run service iptables restart, which says another app is holding xtables, now nc -l -4 solved the nc problem but still I have no idea what app is holding xtables... – Economically

Answer 2

usually when this happens it means that ipv6 is disabled in the kernel. when both ipv4 and ipv6 are enabled the -4 switch isn't needed.

Monteria