13

There is a daemon process listening on port 5144, which I cannot to modify.

I want to use netcat to send the contents of a text file to the server, but this causes netcat to hang the terminal until I press Ctrl+C:

cat file.txt | nc -u 127.0.0.1 5144

The only way I am able to get it to work is by running nc -u 127.0.0.1 5144 and copy/pasting the contents of the file manually.

Any ideas?

Also note:

  1. cat file.txt | ... leads to bash: ...: command not found and I can continue to use the terminal
  2. using nc -u 127.0.0.1 5144 < file.txt leads to the same behavior as using | above
Improve this question
12
  • What happens when you say cat file.txt | …? How about nc -u 127.0.0.1 5144 < file.txt?
    – Scott - Слава Україні
    Nov 5, 2012 at 22:07
  • do you need to use -u? Also, did you do try for the other side, nc -l -p? and did you try nc -p ? (there is one nc that uses -l -p , and one I think that uses -p without -l). You've only shown one side, the client/initiating side. What are you doing for the server side? Try as a test, making nc listen on port 1234 and see if cat...| nc... works to it. I've never seen it before, so this is a weak maybe, but maybe it's something peculiar to this particular daemon that isn't accepting things catted.
    – barlop
    Nov 5, 2012 at 22:27
  • I can't modify the daemon. @Scott: bash: ...: command not found and using "< file.txt" does the same as the | operator (netcat just hangs)
    – Amil
    Nov 5, 2012 at 22:42
  • Can you please be more precise? Does it say “bash: ...: command not found”? Or does it say “bash: cat: command not found” or “bash: nc: command not found”? And then does it then exit to a shell prompt, or does it hang? (I encourage you to edit the question to add these details, so people in Australia who are just now waking up don’t have to read through all these comments to find out what your symptoms are.)
    – Scott - Слава Україні
    Nov 6, 2012 at 0:38
  • @Scott: Thanks, I integrated my answers to your questions into the original question. Any ideas?
    – Amil
    Nov 6, 2012 at 1:00

3 Answers 3

Reset to default
7

If you are using the GNU version of netcat then you can use the -c flag to close the connection on EOF.

-c, --close close connection on EOF from stdin

If you are using the original version of the tool then you can use the -q flag.

-q secs quit after EOF on stdin and delay of secs

An example for the original version is:

cat file.txt | nc -u -q 0 127.0.0.1 5144

I have add "-q 0" to your original command. This closes the connection after the file has been sent.

Improve this answer
1
  • To distinguish: the original version is the one which requires to specify -l -p <port> for listening. The GNU version just takes -l <port>.
    – tueftl
    Nov 15, 2015 at 10:06
1

Assuming that after sending EOF connection will stay idle, you can use -w timeout option, which works for timeout being equal to zero (unlike stupid -q option...)

cat file.text | nc -u localhost 4300 -w0
Improve this answer
0

If you are transferring from FreeBSD to Windows:

FreeBSD: cat file.txt | nc -N 10.0.0.5 5144

-N will shutdown the network socket after EOF

Windows: nc -l -p 5144 > output.txt

-l will stop listening on connection closed (unlike -L)

Improve this answer

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .