This option solves issue #142. It prevents Ncat from putting the connection in
If you'll merge this, please advise on how to regenerate docs and manpages.
This option solves issue #142. It prevents Ncat from putting the connection in half-duplex mode after seeing EOF on stdin. This emulates the behavior of OpenBSD-netcat's `-d` option. The `-d` option itself prevents a bug affecting some versions of that program in which the sender closes the connection prematurely upon receiving a FIN packet from a receiver.
I experienced the behavior described in issue #142 in Fedora 22, using ncat 6.47, while making a systemd service that uses ncat in listen mode.
My .service file calls ncat like the below:
ExecStart = /usr/bin/bash -c "/usr/bin/ncat --recv-only -v -i 4h --allow x.x.x.x -o /var/log/somelogfile.log --append-output y.y.y.y 1234
The above command works just fine when I execute it from the command line. I was able to connect to the listening port using telnet, send data, the data is saved in the specified file, and ncat terminated when I closed the connection.
However, when started via the systemd service, it behaves differently. ncat started ok. I was able to see the process was listening for a connection on the specified port. But, when I connected to the listening port, I was immediately disconnected (telnet said 'connection closed by foreign host'), and ncat terminated with return code 0.
Using strace, I was able to see that ncat was reading 1 byte from stdin when I connected to the listening port. (By default, stdin for systemd services is connected to /dev/null). ncat then immediately shuts down the port and, since I didn't start it with --keep-open, ncat terminates.
If I include the option '--keep-open' when starting the service, the first connection attempt is immediately disconnected but all subsequent connections are successful.
I would really like to see the --no-shutdown option included. Also, it might be a good idea to include a note about this behavior in the man page under the --listen option.
Yeah, that's right, sorry I missed that.
On Tue, Jun 30, 2015 at 1:08 PM, Jacek Wielemborek <email@example.com