CODEWITHSUNDEEP
socketspipenetcat
Aeonos
Aeonos

Reputation: 387

netcat closes connection after 8192 bytes

when sending a request over netcat to a program and listen for the response to that request, netcat only receives the first 8192 bytes and than terminates.

Here are the details: if something is send using netcat and a pipe

echo "something" | netcat -q 10 -i 3 -w 10 localhost myport

My software generates a response which is definitly larger than 8192 bytes and sends it back to netcat. I verifiyed that all bytes are actually send from my programm back to netcat, so there is no problem. If the command line version is used:

netcat -q 10 -i 3 -w 10 localhost myport
something

all bytes send from the application are received. I tried various combinations for the -q -i and -w flags to change the amount of received bytes but in the pipe command version it is always 8192.

How can that be fixed?

Upvotes: 2

Views: 2161

Answers (1)

Gil Hamilton
Gil Hamilton

Reputation: 12357

This is happening because netcat is receiving end-of-file from its standard input. That is, the command echo "something" causes the string something\n to be sent to the pipe connected to netcat's standard input; then the pipe is closed (because the echo command terminated). So, on the first read of the pipe, netcat will receive that string, but on its next read, it will receive EOF. This causes it to break its connection to the peer even though the peer may not be finished sending.

Essentially, after being started as above, netcat will keep sending its standard input to the socket, and the socket to its standard output until one of them is closed. Then it exits.

So you simply need to do something to ensure that netcat doesn't receive EOF on its standard input before it gets EOF on the socket. Something like this will likely do it:

(echo "something" ; sleep 1) | netcat localhost $myport

Now the output of echo "something" is sent to the pipe connected to netcat's input, but the pipe won't actually be closed until the sleep 1 also completes since both commands are started in a sub-shell which is connected to the write end of the pipe. (You might need to tinker with the number of seconds slept if the amount to be sent by the peer is large.)

Upvotes: 2

Related Questions