Linux – How to wait for a response on the inbound side of the socket using NC command under BusyBox

busyboxlinuxnetcat

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

Best Answer

Try this:

(echo "GET / HTTP/1.0"; sleep 1) | nc HOST 80

Related Solutions

Linux – Netcat stops listening for UDP traffic

So there are multiple things called netcat; ubuntu even has /etc/alternatives symbolic-link-hackery for it.

I think part of your problem is that UDP doesn't do sessions; I've copied in part of the file /usr/share/doc/netcat-traditional/README.gz below which does a pretty good job of explaining.

UDP connections are opened instead of TCP when -u is specified. These aren't really "connections" per se since UDP is a connectionless protocol, although netcat does internally use the "connected UDP socket" mechanism that most kernels support. Although netcat claims that an outgoing UDP connection is "open" immediately, no data is sent until something is read from standard input. Only thereafter is it possible to determine whether there really is a UDP server on the other end, and often you just can't tell. Most UDP protocols use timeouts and retries to do their thing and in many cases won't bother answering at all, so you should specify a timeout and hope for the best. You will get more out of UDP connections if standard input is fed from a source of data that looks like various kinds of server requests.

OK so maybe that's not all that great of an explanation but it's what I could find.

If you haven't yet, you might want to experiment with any netcat options you can find that would have to do with waiting... have you experimented with:

using -l as well as -u to ensure you're in "listening" mode
-vv to see exactly what's happening
-q -1 ...which should "wait forever" even after receiving EOF (hopefully, listening again?)

Linux utility to execute HTTP requests and examine raw responses

Many people will recommend telnet for this, and it works, but I prefer to use netcat. The reason is that telnet was designed to work with a particular protocol, the TELNET protocol (which I'm not even sure anyone uses anymore...), so it's got all sorts of bells and whistles (i.e. it recognizes a whole bunch of options and commands and escape characters) that are completely irrelevant for HTTP. On the other hand, netcat simply takes its standard input and sends it out, byte-for-byte, over the network. Nothing more. That's exactly what you need to send a raw HTTP request.

There are various versions of netcat but generally their usage is the same as telnet:

netcat host port < my_http_request.txt

(on my computer the program name is nc6 rather than netcat, so substitute as appropriate)

Related Question