Nc Not Working As Advertised

Home » CentOS » Nc Not Working As Advertised
CentOS 5 Comments

I can’t get nc to do anything worthwhile. In fact I can’t even get the examples in the manpage to work. From either my C6 servers or my F17
notebooks. For example:

echo -n “GET / HTTP/1.0\r\n\r\n” | nc 80

Gets no response. And looking into the access.log of medon shows no access by my client.

I have tried the client/server on both -4 and -6 on a port I have enabled on my firewall. The server looks to be listening, but the client seems to never connect. what I typed in eventually gets played to the terminal session and of course bash says no such command.

Say I have port 5902 open (for VNCserver, and VNCserver is not running). So on server foo, in a su session (because of the port range)
I type:

nc -4l 5902

seems to be listening.

Then on bar, also in an su session:

nc -4 foo.domain 5902
hello world

After some time nc terminates and “hello world” gets sent to the su session and of course is not a valid command…

So what am I missing here?

Doesn’t matter if I use -4, -6, or neither. It does not work.

5 thoughts on - Nc Not Working As Advertised

  • Certainly works for me with the right echo options, and one of those old-style basic HTTP requests.


  • No. I did a simple copy from the manpage. check it out yourself. :(

    Now I have to figure out why the client/server example from the manpage does not work.

  • The man page may be incorrect. You need -e in order to get echo to print out the line feeds properly:

    $ echo -ne “GET / HTTP/1.0\n\n”
    GET / HTTP/1.0

    $ echo -n “GET / HTTP/1.0\n\n”
    GET / HTTP/1.0\n\n$

    (I left the $ prompt in the output, to show that there’s really no line feed.)

    Did you also try the client/server example in the man page (which looks correct to me)?


  • I did try with “echo -ne” and that worked. the man page IS incorrect.
    Guess I have to submit a bug report.

    The localhost loopback works.

    Ah, I just figured out my between systems problem. I was testing across subnets, and the port I was using is not allowed over ipv6, I only have an ipv4 rule for it. gumble. Corollary #2 of Murphy’s Law: “It is always something.”

    Now back to it. I think I figured out my HIP testing problems; it has to do with the HIPFW options… Always firewalls, it seems.