How to stop tcpdump remotely using expect from a new telnet session - tcl

Question

I am trying to stop the tcpdump command from running on a remote terminal. If I telnet to the terminal, start tcpdump, and then send a ^c, tcpdump stops with no issues. However if I telnet to the same terminal, start tcpdump, and then exit the telnet session, when I reconnect to the same telnet session I am unable to stop tcpdump via a ^c. When I do this instead of stopping tcpdump it seems that it just quits the telnet session and tcpdump continues to run on the remote terminal. I provided my script below. Any help is greatly appreciated.
#!/usr/local/bin/expect -f
exp_internal 1
set timeout 30
spawn /bin/bash
expect "] "
send "telnet 192.168.62.133 10006\r"
expect "Escape character is '^]'."
send "\r"
expect "# "
set now [clock format [clock seconds] -format {%d_%b_%Y_%H%M%S}]
set command "tcpdump -vv -i trf400 ip proto 89 -s 65535 -w /tmp/test_term420_${now}.pcp "
send "$command\r"
expect "tcpdump: listening on"
# This works correctly. tcpdump quits and I am returned to the expected prompt
send "\x03"
expect "# "
send "$command\r"
expect "tcpdump: listening on"
# Exit telnet session
send -- "\x1d"
expect "telnet> "
send -- "q\r"
expect "] "
# Reconnect to telnet session
send "telnet 192.168.62.133 10006\r"
expect "Escape character is '^]'."
send "\r"
# This does not work as intended. The ^c quits the telnet session instead of stopping tcpdump
send "\x03"
expect "] "
send "ls\r"
expect "] "

Answer 1

To send a Ctrl+C to a subordinate process with Expect, do this:
send "\x03"
(Ctrl+#=0, Ctrl+A=1, Ctrl+B=2, Ctrl+C=3, etc.)
The correct handling of the Ctrl+C depends on the virtual terminal engine intercepting it and converting a character into a request to send a signal. This only happens when the terminal is in cooked mode. You've probably got the terminal cooked — it's the default after all — but if this doesn't work, that's the first thing to check.

Answer 2

It sounds to me that the tcpdump process has fallen to the background after the first telnet session disconnected.
Maybe what you need to do when you connect over your second telnet session is find the process id using ps and then signal it via the kill command?
Or better yet, launch it in the background in the first place ("&" at the end):
tcpdump -vv -i trf400 ip proto 89 -s 65535 -w /tmp/test_term420_${now}.pcp &
and the shell will give you the pid of the tcpdump process before it returns the prompt... you can read it via expect -re and later on when you re-connect, issue a kill -HUP <pid> (or -INT or whatever).
You should get something like the following (using sleep 5 as command, just as an example):
$ sleep 5 &
[1] 29344
$
Just my 2c.