With a normal netcat: server: nc -l 6000 123 teawater@teawater-virtual-machine:~$ client: nc 127.0.0.1 6000 <<END > 123 > END teawater@teawater-virtual-machine:~$ With current upstream netcat: server: $ ./nc -l -p 12345 123 Hang... client: $ ./nc 127.0.0.1 12345 <<END > 123 > END hang... And I reproduced the issue with busybox netcat server with normal netcat client but not normal netcat server with busybox netcat client. So I think the bug is inside the busybox netcat server.
Update product to busybox
(In reply to teawater from comment #0) > With a normal netcat: > server: > nc -l 6000 What is "normal netcat"? Unfortunately, after original nc-1.10, a number of clones were made over the years, and often the authers did not bother to keep them command-line compatible. For one, the "nc" above evidently listens on port 6000. This is not how nc-1.10 worked: it used -p PORT to set the port. > With current upstream netcat: > server: > $ ./nc -l -p 12345 > 123 > Hang... > client: > $ ./nc 127.0.0.1 12345 <<END > > 123 > > END > hang... It is not hung - it's waiting for data to showel from server side to client. Type something on the server side and press Enter. You'll see. You should use this to let server know there will be no input: $ ./nc -l -p 12345 </dev/null The "normal netcat" is evidently a badly copied clone: it thinks that getting EOF on network side should stop the entire process.