Stop CTRL+C Exiting Local Script Which is Running tcpdump in Remote Machine
Clash Royale CLAN TAG#URR8PPP
I have setup a simple script like the below:
sshpass -p $password ssh -T $username@$ip_address -p 30007 <<- EOF > $save_file.pcap
sh
tcpdump -i eth5.1 -s 0 -n -v -U -w -
EOF
sed -i '1d' $save_file.pcap
The purpose of this script is so that I can run a tcpdump on a remote device, yet save the output into a file on my local machine (the remote device has very limited storage capacity, so this would allow me to obtain much large captures, as well as, of course, allowing me to setup captures on demand much more quickly).
The purpose of the sh
and the heredoc is because by default, I am not dropped into the appropriate shell of this remote device. Issuing sh
in the remote device gets me to the proper shell to be able to run my tcpdump, and this heredoc is the only method I've found to accomplish this task and still port the information back into my local file.
The issue that I'm running into is that once the script gets to the tcpdump section of this script, my terminal is given output like the below, and like I would expect to see when running a tcpdump into a file:
drew@drew-Ubuntu-18:~/Desktop$ ./Script.sh
tcpdump: listening on eth5.1, link-type EN10MB (Ethernet), capture size 65535 bytes
Got 665
And of course that "Got" counter increases as more packets are captured and piped into my local file. Unfortunately, the only method I have found thus far to stop this and return my terminal is to initiate a CTRL
+C
.
The issue here is that this doesn't only stop the tcpdump on the remote machine, but it ends the script that is running on my local machine.
This of course means that nothing further in my script is run, and there are many tasks that I need to perform with this data past just the sed
that I included here.
I've tried to instead set things up like follows instead:
tcpdump -i eth5.1 -s 0 -n -v -U -w - &
read -n 1 -s; kill $!
The thought process here is that my raw tcpdump information would still be posting to stdout, and therefor still be populating in my local capture file. However, it seems like when I tried to run a capture in this manner, with the &
, it didn't actually let me post anything else into the terminal (not sure if just too much junk flying at all times or what). I even tried this locally and it seems like trying to run a raw tcpdump posting to stdout doesn't let anything else happen.
Based on this information, the only thing I can think of at this point is if there is some manner in which I can use the CTRL
+C
in order to close out of the tcpdump on the remote machine, but keep my script still running. Any suggestions I can try? Or other methods of going about this that would be far more logical?
tcpdump here-document sshpass sigint
add a comment |
I have setup a simple script like the below:
sshpass -p $password ssh -T $username@$ip_address -p 30007 <<- EOF > $save_file.pcap
sh
tcpdump -i eth5.1 -s 0 -n -v -U -w -
EOF
sed -i '1d' $save_file.pcap
The purpose of this script is so that I can run a tcpdump on a remote device, yet save the output into a file on my local machine (the remote device has very limited storage capacity, so this would allow me to obtain much large captures, as well as, of course, allowing me to setup captures on demand much more quickly).
The purpose of the sh
and the heredoc is because by default, I am not dropped into the appropriate shell of this remote device. Issuing sh
in the remote device gets me to the proper shell to be able to run my tcpdump, and this heredoc is the only method I've found to accomplish this task and still port the information back into my local file.
The issue that I'm running into is that once the script gets to the tcpdump section of this script, my terminal is given output like the below, and like I would expect to see when running a tcpdump into a file:
drew@drew-Ubuntu-18:~/Desktop$ ./Script.sh
tcpdump: listening on eth5.1, link-type EN10MB (Ethernet), capture size 65535 bytes
Got 665
And of course that "Got" counter increases as more packets are captured and piped into my local file. Unfortunately, the only method I have found thus far to stop this and return my terminal is to initiate a CTRL
+C
.
The issue here is that this doesn't only stop the tcpdump on the remote machine, but it ends the script that is running on my local machine.
This of course means that nothing further in my script is run, and there are many tasks that I need to perform with this data past just the sed
that I included here.
I've tried to instead set things up like follows instead:
tcpdump -i eth5.1 -s 0 -n -v -U -w - &
read -n 1 -s; kill $!
The thought process here is that my raw tcpdump information would still be posting to stdout, and therefor still be populating in my local capture file. However, it seems like when I tried to run a capture in this manner, with the &
, it didn't actually let me post anything else into the terminal (not sure if just too much junk flying at all times or what). I even tried this locally and it seems like trying to run a raw tcpdump posting to stdout doesn't let anything else happen.
Based on this information, the only thing I can think of at this point is if there is some manner in which I can use the CTRL
+C
in order to close out of the tcpdump on the remote machine, but keep my script still running. Any suggestions I can try? Or other methods of going about this that would be far more logical?
tcpdump here-document sshpass sigint
add a comment |
I have setup a simple script like the below:
sshpass -p $password ssh -T $username@$ip_address -p 30007 <<- EOF > $save_file.pcap
sh
tcpdump -i eth5.1 -s 0 -n -v -U -w -
EOF
sed -i '1d' $save_file.pcap
The purpose of this script is so that I can run a tcpdump on a remote device, yet save the output into a file on my local machine (the remote device has very limited storage capacity, so this would allow me to obtain much large captures, as well as, of course, allowing me to setup captures on demand much more quickly).
The purpose of the sh
and the heredoc is because by default, I am not dropped into the appropriate shell of this remote device. Issuing sh
in the remote device gets me to the proper shell to be able to run my tcpdump, and this heredoc is the only method I've found to accomplish this task and still port the information back into my local file.
The issue that I'm running into is that once the script gets to the tcpdump section of this script, my terminal is given output like the below, and like I would expect to see when running a tcpdump into a file:
drew@drew-Ubuntu-18:~/Desktop$ ./Script.sh
tcpdump: listening on eth5.1, link-type EN10MB (Ethernet), capture size 65535 bytes
Got 665
And of course that "Got" counter increases as more packets are captured and piped into my local file. Unfortunately, the only method I have found thus far to stop this and return my terminal is to initiate a CTRL
+C
.
The issue here is that this doesn't only stop the tcpdump on the remote machine, but it ends the script that is running on my local machine.
This of course means that nothing further in my script is run, and there are many tasks that I need to perform with this data past just the sed
that I included here.
I've tried to instead set things up like follows instead:
tcpdump -i eth5.1 -s 0 -n -v -U -w - &
read -n 1 -s; kill $!
The thought process here is that my raw tcpdump information would still be posting to stdout, and therefor still be populating in my local capture file. However, it seems like when I tried to run a capture in this manner, with the &
, it didn't actually let me post anything else into the terminal (not sure if just too much junk flying at all times or what). I even tried this locally and it seems like trying to run a raw tcpdump posting to stdout doesn't let anything else happen.
Based on this information, the only thing I can think of at this point is if there is some manner in which I can use the CTRL
+C
in order to close out of the tcpdump on the remote machine, but keep my script still running. Any suggestions I can try? Or other methods of going about this that would be far more logical?
tcpdump here-document sshpass sigint
I have setup a simple script like the below:
sshpass -p $password ssh -T $username@$ip_address -p 30007 <<- EOF > $save_file.pcap
sh
tcpdump -i eth5.1 -s 0 -n -v -U -w -
EOF
sed -i '1d' $save_file.pcap
The purpose of this script is so that I can run a tcpdump on a remote device, yet save the output into a file on my local machine (the remote device has very limited storage capacity, so this would allow me to obtain much large captures, as well as, of course, allowing me to setup captures on demand much more quickly).
The purpose of the sh
and the heredoc is because by default, I am not dropped into the appropriate shell of this remote device. Issuing sh
in the remote device gets me to the proper shell to be able to run my tcpdump, and this heredoc is the only method I've found to accomplish this task and still port the information back into my local file.
The issue that I'm running into is that once the script gets to the tcpdump section of this script, my terminal is given output like the below, and like I would expect to see when running a tcpdump into a file:
drew@drew-Ubuntu-18:~/Desktop$ ./Script.sh
tcpdump: listening on eth5.1, link-type EN10MB (Ethernet), capture size 65535 bytes
Got 665
And of course that "Got" counter increases as more packets are captured and piped into my local file. Unfortunately, the only method I have found thus far to stop this and return my terminal is to initiate a CTRL
+C
.
The issue here is that this doesn't only stop the tcpdump on the remote machine, but it ends the script that is running on my local machine.
This of course means that nothing further in my script is run, and there are many tasks that I need to perform with this data past just the sed
that I included here.
I've tried to instead set things up like follows instead:
tcpdump -i eth5.1 -s 0 -n -v -U -w - &
read -n 1 -s; kill $!
The thought process here is that my raw tcpdump information would still be posting to stdout, and therefor still be populating in my local capture file. However, it seems like when I tried to run a capture in this manner, with the &
, it didn't actually let me post anything else into the terminal (not sure if just too much junk flying at all times or what). I even tried this locally and it seems like trying to run a raw tcpdump posting to stdout doesn't let anything else happen.
Based on this information, the only thing I can think of at this point is if there is some manner in which I can use the CTRL
+C
in order to close out of the tcpdump on the remote machine, but keep my script still running. Any suggestions I can try? Or other methods of going about this that would be far more logical?
tcpdump here-document sshpass sigint
tcpdump here-document sshpass sigint
edited Feb 3 at 6:02
Rui F Ribeiro
40.5k1479137
40.5k1479137
asked Feb 3 at 4:11
DrewDrew
84
84
add a comment |
add a comment |
1 Answer
1
active
oldest
votes
I suggest some improvements for your remote capturing traffic script:
preventing CTRC+C from killing your script:
This can be done using a trap to capture
SIGINT
. You usually place it at the beginning of your script. See this example:trap "pkill ssh" INT
Obviously, the filter to get the only the ssh you want can be improved.
Filtering out the communication with the remote machine from that
tcpdump
You telling us your system is not reacting well to the capture, might be a recursive data capture overloading the system. Depending on the interface you are listening to, you might be creating a recursive situation where in each connection you have with the remote machine, the controlling connection data will be added to the capture, which in turn will generate more packets to feed
tcpdump
.So your
tcpdump
might needs to filter out the communication between the local and remote machine. Use something similar to:/usr/bin/tcpdump -i eth5.1 -s 0 -n -v -U -w - "not port 22"
or:
/usr/bin/tcpdump -i eth5.1 -s 0 -n -v -U -w - "not my_local_host"
This might alleviate the slowness and instability, so the script will behave better. See also later on, the point about using
nc
.Limiting the number of packets in
tcpdump
to avoid having to use CTRC+C all the time.If you only want to capture a small set of traffic, you should limit the number of
tcpdump
packets captured bytcpdump
.For instance for capturing 100 packets and returning:
tcpdump -c 100 -w -
Limiting
tcpdump
in time to avoid using CTRC+C all the time.If you want to capture 5 minutes (300 seconds) of traffic, use the
timeout
command on the remote side. As in:ssh "timeout 300 tcpdump -w -"
Dropping that shell
You are using the shell because you need $PATH to invoke
tcpdump
. Invoke the fulltcpdump
path instead.As in:
sshpass -p $password ssh -T $username@$ip_address -p 30007 "/usr/bin/tcpdump -i eth5.1 -s 0 -n -v -U -w -"
unbuffering
tcpdump
tcpdump
output totcpdump
tostdout
is buffered. To unbuffer it to get data faster from the remote host, and lose less data when interrupting it, use-l
:/usr/bin/tcpdump -i eth5.1 -s 0 -n -v -U -l -w -
This might or might not be useful on your case, make some tests. It will sure left you more data on your side when you interrupt it with CTRL-C.
not using SSH for getting the traffic dumps. Use
netcat
instead.If you do not have so strict security requirements e.g. a capture inside your own network, and not have firewall(s) blocking ports in the way between the two hosts, drop that SSH for getting
tcpdump
output back. It is a computationally heavy protocol, and will get in the way if you need to capture more volume of remote traffic. Usenc
instead to get thetcpdump
data.As in local machine:
nc -l -p 20000 > capture.dump &
Remote machine:
ssh remote "/usr/bin/tcpdump -w - | nc IP_local_machine 20000" > /dev/null
Dropping that
sshpass
Use ssh keys to authenticate instead of a password.
Lastly, if doing it more professionally, considering the possibility of using an agent + a professional service.
You can do it using
cshark
.
Capture traffic and upload it directly to CloudShark for analysis. Use
the CloudShark service at https://www.cloudshark.org or your own
CloudShark appliance.
when did control+c start sending aSIGTERM
?
– thrig
Feb 3 at 15:30
@thrig indeed, it is a SIGINT, thanks
– Rui F Ribeiro
Feb 3 at 15:33
Thanks for the feedback. Some of your suggestions are not able to be implemented in my environment, but #1 above is exactly what I needed to get things working for me. I created a separate function for the "cleanup" operations that I needed to have done, and then wrotetrap "cleanup" SIGINT SIGTERM
right above my main code as shown above. I also threw in some echo statements just for debugging purposes, but when I initiate aCTRL
+C
in my console, it ends my tcpdump and performs what I need it to.
– Drew
Feb 6 at 4:55
add a comment |
Your Answer
StackExchange.ready(function()
var channelOptions =
tags: "".split(" "),
id: "106"
;
initTagRenderer("".split(" "), "".split(" "), channelOptions);
StackExchange.using("externalEditor", function()
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled)
StackExchange.using("snippets", function()
createEditor();
);
else
createEditor();
);
function createEditor()
StackExchange.prepareEditor(
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: false,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: null,
bindNavPrevention: true,
postfix: "",
imageUploader:
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
,
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
);
);
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function ()
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2funix.stackexchange.com%2fquestions%2f498382%2fstop-ctrlc-exiting-local-script-which-is-running-tcpdump-in-remote-machine%23new-answer', 'question_page');
);
Post as a guest
Required, but never shown
1 Answer
1
active
oldest
votes
1 Answer
1
active
oldest
votes
active
oldest
votes
active
oldest
votes
I suggest some improvements for your remote capturing traffic script:
preventing CTRC+C from killing your script:
This can be done using a trap to capture
SIGINT
. You usually place it at the beginning of your script. See this example:trap "pkill ssh" INT
Obviously, the filter to get the only the ssh you want can be improved.
Filtering out the communication with the remote machine from that
tcpdump
You telling us your system is not reacting well to the capture, might be a recursive data capture overloading the system. Depending on the interface you are listening to, you might be creating a recursive situation where in each connection you have with the remote machine, the controlling connection data will be added to the capture, which in turn will generate more packets to feed
tcpdump
.So your
tcpdump
might needs to filter out the communication between the local and remote machine. Use something similar to:/usr/bin/tcpdump -i eth5.1 -s 0 -n -v -U -w - "not port 22"
or:
/usr/bin/tcpdump -i eth5.1 -s 0 -n -v -U -w - "not my_local_host"
This might alleviate the slowness and instability, so the script will behave better. See also later on, the point about using
nc
.Limiting the number of packets in
tcpdump
to avoid having to use CTRC+C all the time.If you only want to capture a small set of traffic, you should limit the number of
tcpdump
packets captured bytcpdump
.For instance for capturing 100 packets and returning:
tcpdump -c 100 -w -
Limiting
tcpdump
in time to avoid using CTRC+C all the time.If you want to capture 5 minutes (300 seconds) of traffic, use the
timeout
command on the remote side. As in:ssh "timeout 300 tcpdump -w -"
Dropping that shell
You are using the shell because you need $PATH to invoke
tcpdump
. Invoke the fulltcpdump
path instead.As in:
sshpass -p $password ssh -T $username@$ip_address -p 30007 "/usr/bin/tcpdump -i eth5.1 -s 0 -n -v -U -w -"
unbuffering
tcpdump
tcpdump
output totcpdump
tostdout
is buffered. To unbuffer it to get data faster from the remote host, and lose less data when interrupting it, use-l
:/usr/bin/tcpdump -i eth5.1 -s 0 -n -v -U -l -w -
This might or might not be useful on your case, make some tests. It will sure left you more data on your side when you interrupt it with CTRL-C.
not using SSH for getting the traffic dumps. Use
netcat
instead.If you do not have so strict security requirements e.g. a capture inside your own network, and not have firewall(s) blocking ports in the way between the two hosts, drop that SSH for getting
tcpdump
output back. It is a computationally heavy protocol, and will get in the way if you need to capture more volume of remote traffic. Usenc
instead to get thetcpdump
data.As in local machine:
nc -l -p 20000 > capture.dump &
Remote machine:
ssh remote "/usr/bin/tcpdump -w - | nc IP_local_machine 20000" > /dev/null
Dropping that
sshpass
Use ssh keys to authenticate instead of a password.
Lastly, if doing it more professionally, considering the possibility of using an agent + a professional service.
You can do it using
cshark
.
Capture traffic and upload it directly to CloudShark for analysis. Use
the CloudShark service at https://www.cloudshark.org or your own
CloudShark appliance.
when did control+c start sending aSIGTERM
?
– thrig
Feb 3 at 15:30
@thrig indeed, it is a SIGINT, thanks
– Rui F Ribeiro
Feb 3 at 15:33
Thanks for the feedback. Some of your suggestions are not able to be implemented in my environment, but #1 above is exactly what I needed to get things working for me. I created a separate function for the "cleanup" operations that I needed to have done, and then wrotetrap "cleanup" SIGINT SIGTERM
right above my main code as shown above. I also threw in some echo statements just for debugging purposes, but when I initiate aCTRL
+C
in my console, it ends my tcpdump and performs what I need it to.
– Drew
Feb 6 at 4:55
add a comment |
I suggest some improvements for your remote capturing traffic script:
preventing CTRC+C from killing your script:
This can be done using a trap to capture
SIGINT
. You usually place it at the beginning of your script. See this example:trap "pkill ssh" INT
Obviously, the filter to get the only the ssh you want can be improved.
Filtering out the communication with the remote machine from that
tcpdump
You telling us your system is not reacting well to the capture, might be a recursive data capture overloading the system. Depending on the interface you are listening to, you might be creating a recursive situation where in each connection you have with the remote machine, the controlling connection data will be added to the capture, which in turn will generate more packets to feed
tcpdump
.So your
tcpdump
might needs to filter out the communication between the local and remote machine. Use something similar to:/usr/bin/tcpdump -i eth5.1 -s 0 -n -v -U -w - "not port 22"
or:
/usr/bin/tcpdump -i eth5.1 -s 0 -n -v -U -w - "not my_local_host"
This might alleviate the slowness and instability, so the script will behave better. See also later on, the point about using
nc
.Limiting the number of packets in
tcpdump
to avoid having to use CTRC+C all the time.If you only want to capture a small set of traffic, you should limit the number of
tcpdump
packets captured bytcpdump
.For instance for capturing 100 packets and returning:
tcpdump -c 100 -w -
Limiting
tcpdump
in time to avoid using CTRC+C all the time.If you want to capture 5 minutes (300 seconds) of traffic, use the
timeout
command on the remote side. As in:ssh "timeout 300 tcpdump -w -"
Dropping that shell
You are using the shell because you need $PATH to invoke
tcpdump
. Invoke the fulltcpdump
path instead.As in:
sshpass -p $password ssh -T $username@$ip_address -p 30007 "/usr/bin/tcpdump -i eth5.1 -s 0 -n -v -U -w -"
unbuffering
tcpdump
tcpdump
output totcpdump
tostdout
is buffered. To unbuffer it to get data faster from the remote host, and lose less data when interrupting it, use-l
:/usr/bin/tcpdump -i eth5.1 -s 0 -n -v -U -l -w -
This might or might not be useful on your case, make some tests. It will sure left you more data on your side when you interrupt it with CTRL-C.
not using SSH for getting the traffic dumps. Use
netcat
instead.If you do not have so strict security requirements e.g. a capture inside your own network, and not have firewall(s) blocking ports in the way between the two hosts, drop that SSH for getting
tcpdump
output back. It is a computationally heavy protocol, and will get in the way if you need to capture more volume of remote traffic. Usenc
instead to get thetcpdump
data.As in local machine:
nc -l -p 20000 > capture.dump &
Remote machine:
ssh remote "/usr/bin/tcpdump -w - | nc IP_local_machine 20000" > /dev/null
Dropping that
sshpass
Use ssh keys to authenticate instead of a password.
Lastly, if doing it more professionally, considering the possibility of using an agent + a professional service.
You can do it using
cshark
.
Capture traffic and upload it directly to CloudShark for analysis. Use
the CloudShark service at https://www.cloudshark.org or your own
CloudShark appliance.
when did control+c start sending aSIGTERM
?
– thrig
Feb 3 at 15:30
@thrig indeed, it is a SIGINT, thanks
– Rui F Ribeiro
Feb 3 at 15:33
Thanks for the feedback. Some of your suggestions are not able to be implemented in my environment, but #1 above is exactly what I needed to get things working for me. I created a separate function for the "cleanup" operations that I needed to have done, and then wrotetrap "cleanup" SIGINT SIGTERM
right above my main code as shown above. I also threw in some echo statements just for debugging purposes, but when I initiate aCTRL
+C
in my console, it ends my tcpdump and performs what I need it to.
– Drew
Feb 6 at 4:55
add a comment |
I suggest some improvements for your remote capturing traffic script:
preventing CTRC+C from killing your script:
This can be done using a trap to capture
SIGINT
. You usually place it at the beginning of your script. See this example:trap "pkill ssh" INT
Obviously, the filter to get the only the ssh you want can be improved.
Filtering out the communication with the remote machine from that
tcpdump
You telling us your system is not reacting well to the capture, might be a recursive data capture overloading the system. Depending on the interface you are listening to, you might be creating a recursive situation where in each connection you have with the remote machine, the controlling connection data will be added to the capture, which in turn will generate more packets to feed
tcpdump
.So your
tcpdump
might needs to filter out the communication between the local and remote machine. Use something similar to:/usr/bin/tcpdump -i eth5.1 -s 0 -n -v -U -w - "not port 22"
or:
/usr/bin/tcpdump -i eth5.1 -s 0 -n -v -U -w - "not my_local_host"
This might alleviate the slowness and instability, so the script will behave better. See also later on, the point about using
nc
.Limiting the number of packets in
tcpdump
to avoid having to use CTRC+C all the time.If you only want to capture a small set of traffic, you should limit the number of
tcpdump
packets captured bytcpdump
.For instance for capturing 100 packets and returning:
tcpdump -c 100 -w -
Limiting
tcpdump
in time to avoid using CTRC+C all the time.If you want to capture 5 minutes (300 seconds) of traffic, use the
timeout
command on the remote side. As in:ssh "timeout 300 tcpdump -w -"
Dropping that shell
You are using the shell because you need $PATH to invoke
tcpdump
. Invoke the fulltcpdump
path instead.As in:
sshpass -p $password ssh -T $username@$ip_address -p 30007 "/usr/bin/tcpdump -i eth5.1 -s 0 -n -v -U -w -"
unbuffering
tcpdump
tcpdump
output totcpdump
tostdout
is buffered. To unbuffer it to get data faster from the remote host, and lose less data when interrupting it, use-l
:/usr/bin/tcpdump -i eth5.1 -s 0 -n -v -U -l -w -
This might or might not be useful on your case, make some tests. It will sure left you more data on your side when you interrupt it with CTRL-C.
not using SSH for getting the traffic dumps. Use
netcat
instead.If you do not have so strict security requirements e.g. a capture inside your own network, and not have firewall(s) blocking ports in the way between the two hosts, drop that SSH for getting
tcpdump
output back. It is a computationally heavy protocol, and will get in the way if you need to capture more volume of remote traffic. Usenc
instead to get thetcpdump
data.As in local machine:
nc -l -p 20000 > capture.dump &
Remote machine:
ssh remote "/usr/bin/tcpdump -w - | nc IP_local_machine 20000" > /dev/null
Dropping that
sshpass
Use ssh keys to authenticate instead of a password.
Lastly, if doing it more professionally, considering the possibility of using an agent + a professional service.
You can do it using
cshark
.
Capture traffic and upload it directly to CloudShark for analysis. Use
the CloudShark service at https://www.cloudshark.org or your own
CloudShark appliance.
I suggest some improvements for your remote capturing traffic script:
preventing CTRC+C from killing your script:
This can be done using a trap to capture
SIGINT
. You usually place it at the beginning of your script. See this example:trap "pkill ssh" INT
Obviously, the filter to get the only the ssh you want can be improved.
Filtering out the communication with the remote machine from that
tcpdump
You telling us your system is not reacting well to the capture, might be a recursive data capture overloading the system. Depending on the interface you are listening to, you might be creating a recursive situation where in each connection you have with the remote machine, the controlling connection data will be added to the capture, which in turn will generate more packets to feed
tcpdump
.So your
tcpdump
might needs to filter out the communication between the local and remote machine. Use something similar to:/usr/bin/tcpdump -i eth5.1 -s 0 -n -v -U -w - "not port 22"
or:
/usr/bin/tcpdump -i eth5.1 -s 0 -n -v -U -w - "not my_local_host"
This might alleviate the slowness and instability, so the script will behave better. See also later on, the point about using
nc
.Limiting the number of packets in
tcpdump
to avoid having to use CTRC+C all the time.If you only want to capture a small set of traffic, you should limit the number of
tcpdump
packets captured bytcpdump
.For instance for capturing 100 packets and returning:
tcpdump -c 100 -w -
Limiting
tcpdump
in time to avoid using CTRC+C all the time.If you want to capture 5 minutes (300 seconds) of traffic, use the
timeout
command on the remote side. As in:ssh "timeout 300 tcpdump -w -"
Dropping that shell
You are using the shell because you need $PATH to invoke
tcpdump
. Invoke the fulltcpdump
path instead.As in:
sshpass -p $password ssh -T $username@$ip_address -p 30007 "/usr/bin/tcpdump -i eth5.1 -s 0 -n -v -U -w -"
unbuffering
tcpdump
tcpdump
output totcpdump
tostdout
is buffered. To unbuffer it to get data faster from the remote host, and lose less data when interrupting it, use-l
:/usr/bin/tcpdump -i eth5.1 -s 0 -n -v -U -l -w -
This might or might not be useful on your case, make some tests. It will sure left you more data on your side when you interrupt it with CTRL-C.
not using SSH for getting the traffic dumps. Use
netcat
instead.If you do not have so strict security requirements e.g. a capture inside your own network, and not have firewall(s) blocking ports in the way between the two hosts, drop that SSH for getting
tcpdump
output back. It is a computationally heavy protocol, and will get in the way if you need to capture more volume of remote traffic. Usenc
instead to get thetcpdump
data.As in local machine:
nc -l -p 20000 > capture.dump &
Remote machine:
ssh remote "/usr/bin/tcpdump -w - | nc IP_local_machine 20000" > /dev/null
Dropping that
sshpass
Use ssh keys to authenticate instead of a password.
Lastly, if doing it more professionally, considering the possibility of using an agent + a professional service.
You can do it using
cshark
.
Capture traffic and upload it directly to CloudShark for analysis. Use
the CloudShark service at https://www.cloudshark.org or your own
CloudShark appliance.
edited Feb 6 at 8:56
answered Feb 3 at 7:07
Rui F RibeiroRui F Ribeiro
40.5k1479137
40.5k1479137
when did control+c start sending aSIGTERM
?
– thrig
Feb 3 at 15:30
@thrig indeed, it is a SIGINT, thanks
– Rui F Ribeiro
Feb 3 at 15:33
Thanks for the feedback. Some of your suggestions are not able to be implemented in my environment, but #1 above is exactly what I needed to get things working for me. I created a separate function for the "cleanup" operations that I needed to have done, and then wrotetrap "cleanup" SIGINT SIGTERM
right above my main code as shown above. I also threw in some echo statements just for debugging purposes, but when I initiate aCTRL
+C
in my console, it ends my tcpdump and performs what I need it to.
– Drew
Feb 6 at 4:55
add a comment |
when did control+c start sending aSIGTERM
?
– thrig
Feb 3 at 15:30
@thrig indeed, it is a SIGINT, thanks
– Rui F Ribeiro
Feb 3 at 15:33
Thanks for the feedback. Some of your suggestions are not able to be implemented in my environment, but #1 above is exactly what I needed to get things working for me. I created a separate function for the "cleanup" operations that I needed to have done, and then wrotetrap "cleanup" SIGINT SIGTERM
right above my main code as shown above. I also threw in some echo statements just for debugging purposes, but when I initiate aCTRL
+C
in my console, it ends my tcpdump and performs what I need it to.
– Drew
Feb 6 at 4:55
when did control+c start sending a
SIGTERM
?– thrig
Feb 3 at 15:30
when did control+c start sending a
SIGTERM
?– thrig
Feb 3 at 15:30
@thrig indeed, it is a SIGINT, thanks
– Rui F Ribeiro
Feb 3 at 15:33
@thrig indeed, it is a SIGINT, thanks
– Rui F Ribeiro
Feb 3 at 15:33
Thanks for the feedback. Some of your suggestions are not able to be implemented in my environment, but #1 above is exactly what I needed to get things working for me. I created a separate function for the "cleanup" operations that I needed to have done, and then wrote
trap "cleanup" SIGINT SIGTERM
right above my main code as shown above. I also threw in some echo statements just for debugging purposes, but when I initiate a CTRL
+C
in my console, it ends my tcpdump and performs what I need it to.– Drew
Feb 6 at 4:55
Thanks for the feedback. Some of your suggestions are not able to be implemented in my environment, but #1 above is exactly what I needed to get things working for me. I created a separate function for the "cleanup" operations that I needed to have done, and then wrote
trap "cleanup" SIGINT SIGTERM
right above my main code as shown above. I also threw in some echo statements just for debugging purposes, but when I initiate a CTRL
+C
in my console, it ends my tcpdump and performs what I need it to.– Drew
Feb 6 at 4:55
add a comment |
Thanks for contributing an answer to Unix & Linux Stack Exchange!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function ()
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2funix.stackexchange.com%2fquestions%2f498382%2fstop-ctrlc-exiting-local-script-which-is-running-tcpdump-in-remote-machine%23new-answer', 'question_page');
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown