17

I have used exec 3<>/dev/tcp/192.168.0.101/6435 to establish a TCP connection with 192.168.0.101:6435. And I have received as well as sent a few messages with the pipe command.

Now, I want to terminate the TCP connection. But, with ss -anpet I can see that bash itself holds this connection, without forking a child process.

I tried to send signal 9 and 15 to the bash process, but as you know, bash cannot kill itself.

So, can I terminate the TCP connection I have established without terminating the pts I am using (neither killing it by root nor sending Ctrl+D)?

  • Could you get another shell & kill bash with that shell? – trysis Jun 12 '16 at 21:40
  • 3
    bash certainly can kill itself - though that's not actually what you want to do here! – psmears Jun 12 '16 at 22:50
  • @TJM to make this fascinating question more useful to others, could you please elaborate on the pipe command you're using and which I can't find on my system? Which package does pipe comes from? What (example) parameters can you pass to it to send/receive data over the /dev/tcp/... connection? Thanks. – arielf Jun 13 '16 at 21:50
  • @arielf Typically, I am a beginner of Computer Science, and I found this kind of usage from a bash shell script called sedbot, you can find it on Github. Yes, I cannot find any files in /dev/tcp, even cannot find /dev/tcp itself. But, it seems a special usage that you can send/receive data with pipe and this kind of files. It is said that use /dev/tcp/ip/port for tcp connections, and /dev/udp/ip/port for udp packages. For my English is not very good, I don not know how to explain it properly. Please feel free to edit the question and post an answer. – TJM Jun 14 '16 at 4:00
  • @TJM thanks. The question was about the pipe command that you mention. I looked at https://github.com/clsr/sedbot/blob/master/sedbot.bash. There's no pipe command there. It defines two functions: readmsg and sendmsg to read/write from/to the connection respectively. readmsg uses IFS= read -r -u 3 -t "$READ_TIMEOUT" line to read from file-descriptor 3 into the variable line, and sendmsg uses echo "$(date +%s.%N) >>> $line" >&4 to write into file descriptor 4. Anyway, this clarifies the full method. The "pipe command" mention still remains a mystery to readers. – arielf Jun 14 '16 at 5:23
18

That command opened the connection on file descriptor 3. So to close the connection, you need to close file descriptor 3. To do so:

exec 3<&-
| improve this answer | |
  • 1
    Will this do a proper shutdown(3) call, or just close(2) the file descriptor? – Kevin Jun 13 '16 at 3:23
  • Does a close, but shutdown is no more proper than close. shutdown's only real use is when you only want to close one side of a duplex socket. – Patrick Jun 13 '16 at 3:26
  • 4
    A shutdown sends a FIN, while a close sends a RST. These are materially different things. – Kevin Jun 13 '16 at 3:29
  • 2
    @Kevin RST is caused by closing the socket without reading all the data from it first. If you read to the end of the data and then do a close, the close will send a FIN. – kasperd Jun 13 '16 at 7:04
  • @kasperd: In the UNIX socket API, the only way to know whether there is data pending is to either try to read from a nonblocking socket, or call something like select(), and I don't believe bash provides for either option. – Kevin Jun 13 '16 at 7:08

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.