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
Be Brave Be Like Ukraine
  • 721
  • 3
  • 14
  • 25
Amil
  • 251
  • 1
  • 3
  • 6
  • What happens when you say `cat file.txt | …`?  How about `nc -u 127.0.0.1 5144 < file.txt`? – Scott - Слава Україні Nov 05 '12 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 05 '12 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 05 '12 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 06 '12 at 00:38
  • @Scott: Thanks, I integrated my answers to your questions into the original question. Any ideas? – Amil Nov 06 '12 at 01:00
  • Well, I don’t understand.  First you say “using ‘`< file.txt`’ does the same as the `|` operator (netcat just hangs)”, but now you say “[with] `cat file.txt | ...` … I can continue to use the terminal” — which I interpret to mean that the command does _not_ hang.  And, you’re not _really_ typing “`cat file.txt | ...`”, are you?  So ***WHAT IS YOUR ERROR MESSAGE***?  Is it “`bash: nc -u 127.0.0.1 5144: command not found`”? – Scott - Слава Україні Nov 06 '12 at 01:26
  • @Scott I literally typed `cat file.txt | ...`. What did you mean to ask me to type? – Amil Nov 06 '12 at 19:13
  • I meant, what happens when you type “`cat file.txt | nc -u 127.0.0.1 5144` (Enter)” and what happens when you type “`nc -u 127.0.0.1 5144 < file.txt` (Enter)”? – Scott - Слава Україні Nov 06 '12 at 19:59
  • @Scott: The only thing that happens is netcat starts running (with no output on the console), but nothing I type gets sent to the server anymore. If I do `cat file.txt | nc -u 127.0.0.1 5555` and run `nc -u -l 5555', it works as normal. I think this may be something wrong in the server I am using. In this case, I do not know if anybody online can help debug this. Thanks for your help, though! – Amil Nov 06 '12 at 21:38
  • OK, I’m going to take one more crack at this.  (1) When you run `nc` with input from a pipe or directly from the file (`<`), do you _know_ that the server isn’t getting the data, or do you only know that you’re not getting your shell prompt back?  Can you run a sniffer to what is happening on the network?  (2) When you copy and paste into `nc` and type (Ctrl)+D, do you get your shell prompt back _then_, or do you have to (Ctrl)+C out?  (3) What happens if you add a `–w 1` option to your `nc` command (either before or immediately after the `–u`)? – Scott - Слава Україні Nov 07 '12 at 00:13
  • @Scott 1) I know the server is not getting the data. 2) I have to use Ctrl+C to get out, ctrl+d does nothing. 3) No data is sent to the server and netcat exits, giving me the shell prompt back – Amil Nov 09 '12 at 21:31
  • @Scott: Thanks for your help and no need to reply back. I do not plan to check back on this page. – Amil Nov 11 '12 at 05:28

3 Answers3

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.

Kaplaa
  • 146
  • 3
  • To distinguish: the original version is the one which requires to specify `-l -p ` for listening. The GNU version just takes `-l `. – tueftl Nov 15 '15 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
Bora M. Alper
  • 201
  • 2
  • 8
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)

Eugene Petrov
  • 101
  • 3