5

I am having problems using the Netcat that comes with BusyBox 1.1.3 to make an HTTP request and then receive the response. The NC command seems to quit out as soon as it reaches the end of the request file I am sending. The -w option seems to be designed for this case, but looking at the source code, it does not seem possible that the -w option can have any effect on the receiving behavior.

The source code for this version NC on BusyBox is here...

http://git.busybox.net/busybox/tree/networking/nc.c?id=5cbe2519d8776bc15e0bc4dc7aeb6adc53e50b81

What am I doing wrong? Is there any way to send a file to a server via this version of NC and then wait to receive a response? Any creative ideas for other possible ways to do this in a script?

Note that this is an embedded system and I do not have the ability to upgrade the BusyBox version or upload new executable- I can only use script files and the BusyBox executable already available. Also note that there is no WGET available on the system.

Thanks!

-josh

Improve this question
0

2 Answers 2

Reset to default
6

Try this:

(echo "GET / HTTP/1.0"; sleep 1) | nc HOST 80
Improve this answer
1
  • 2
    To avoid using a subshell you can do { ...; } in place of (...). Note that you need spaces before/after the braces and a trailing semicolon after the last command.
    – augurar
    Sep 15, 2017 at 19:32
1

Are you sure you are not confused about nc? The BusyBox man page states:

nc
nc [OPTIONS] HOST PORT - connect nc [OPTIONS] -l -p PORT [HOST] [PORT] - listen

Options:

    -e PROG         Run PROG after connect (must be last)
    -l              Listen mode, for inbound connects
    -n              Don't do DNS resolution
    -s ADDR         Local address
    -p PORT         Local port
    -u              UDP mode
    -v              Verbose
    -w SEC          Timeout for connects and final net reads
    -i SEC          Delay interval for lines sent
    -o FILE         Hex dump traffic
    -z              Zero-I/O mode (scanning)

so it appears the option to listen on a port is (the traditional) -l, while -w is the timeout for connects and final net reads.

If your problem is to keep listening even after a connection has bene closed, you may use an eternal loop, while true nc -l ....

Edit:

After reading the messages, I realize I did not understand what the OP was asking. The reason why I did not understand is that you cannot use a nc instance for both sending and receiving. You need a separate port, and a separate instance of nc for that. There is no pint in keeping a transmit instance of nc open, if you cannot receive on the same port.

Improve this answer
2
  • Psst! Xe is trying to make an HTTP client not an HTTP server.
    – JdeBP
    Jan 2, 2014 at 8:47
  • Correct, I am connecting into a listening server so don't think -l is appropriate. The connection works find and even sends the data that I supply via STDIN, problem is that nc command quits out immediately upon sending outbound data and does not wait for the response to come in on the inbound side of the socket connection. Thanks!
    – bigjosh
    Jan 3, 2014 at 17:36

You must log in to answer this question.

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