 | 1 | initial version |
We see no stderr messages from the remote side of the ssh session perhaps implying that the unknown -batch parameter is suppressing or redirecting those messages with stdout making harder to see what is wrong.
Confirm that tcpdump is in the $PATH of the shell spawned by ssh on your remote device and that userid has permission to run tcpdump.
Compare the output of this failed tcpdump command (where we see a bash error message from the remote side):
% ssh ntppi.local. tcpdump -i wlan0 -s 0 -U -w - -c 1 | tshark -i -
Capturing on 'Standard input'
bash: tcpdump: command not found
tshark: End of file on pipe magic during open.
0 packets captured
%
With this successful command (where I used sudo tcpdump):
% ssh ntppi.local. sudo tcpdump -i wlan0 -s 0 -U -w - -c 1 | tshark -i -
Capturing on 'Standard input'
tcpdump: listening on wlan0, link-type EN10MB (Ethernet), capture size 262144 bytes
1 packet captured
3 packets received by filter
0 packets dropped by kernel
1 0.000000 fe80::123:b28b:5ec9:ec65 → fe80::8be:fe4a:b13d:3dd1 SSH 270 0xedb6 Good 0xedb6 8bd2bb92edad14befdec64f73603ab91 0 22 60544 100426379 Server: Encrypted packet (len=184)
1 packet captured
With this successful command:
% ssh ntppi.local. sudo tcpdump -i wlan0 -s 0 -U -w - -c 1 | Wireshark -k -i -
tcpdump: listening on wlan0, link-type EN10MB (Ethernet), capture size 262144 bytes
** (wireshark:86816) 14:41:01.187675 [MATE MESSAGE] -- initialize_mate: entering
1 packet captured
3 packets received by filter
0 packets dropped by kernel
** (wireshark:86816) 14:41:01.234288 [Capture MESSAGE] -- Capture Start ...
** (wireshark:86816) 14:41:01.336244 [Capture MESSAGE] -- Capture started
** (wireshark:86816) 14:41:01.336276 [Capture MESSAGE] -- File: "/var/folders/wk/rjxg8gjs2zl8j_0xgwnn1y9r0000gn/T/wireshark_Standard inputYHRVP2.pcapng"
** (wireshark:86816) 14:41:01.402738 [Capture MESSAGE] -- Capture stopped.
In these latter two examples tcpdump's stderr status messages do not interfere with tshark's and wireshark's from successfully reading from stdin.
| | 2 | No.2 Revision |
We see no stderr messages from the remote side of the ssh session perhaps implying that the unknown -batch parameter is suppressing or redirecting those stderr messages with to stdout making harder to see what is wrong.
Confirm that tcpdump is in the $PATH of the shell spawned by ssh on your remote device and that userid has permission to run tcpdump.
Compare the output of this failed tcpdump command (where we see a bash error message from the remote side):
% ssh ntppi.local. tcpdump -i wlan0 -s 0 -U -w - -c 1 | tshark -i -
Capturing on 'Standard input'
bash: tcpdump: command not found
tshark: End of file on pipe magic during open.
0 packets captured
%
With this successful command (where I used sudo tcpdump):
% ssh ntppi.local. sudo tcpdump -i wlan0 -s 0 -U -w - -c 1 | tshark -i -
Capturing on 'Standard input'
tcpdump: listening on wlan0, link-type EN10MB (Ethernet), capture size 262144 bytes
1 packet captured
3 packets received by filter
0 packets dropped by kernel
1 0.000000 fe80::123:b28b:5ec9:ec65 → fe80::8be:fe4a:b13d:3dd1 SSH 270 0xedb6 Good 0xedb6 8bd2bb92edad14befdec64f73603ab91 0 22 60544 100426379 Server: Encrypted packet (len=184)
1 packet captured
With this successful command:
% ssh ntppi.local. sudo tcpdump -i wlan0 -s 0 -U -w - -c 1 | Wireshark -k -i -
tcpdump: listening on wlan0, link-type EN10MB (Ethernet), capture size 262144 bytes
** (wireshark:86816) 14:41:01.187675 [MATE MESSAGE] -- initialize_mate: entering
1 packet captured
3 packets received by filter
0 packets dropped by kernel
** (wireshark:86816) 14:41:01.234288 [Capture MESSAGE] -- Capture Start ...
** (wireshark:86816) 14:41:01.336244 [Capture MESSAGE] -- Capture started
** (wireshark:86816) 14:41:01.336276 [Capture MESSAGE] -- File: "/var/folders/wk/rjxg8gjs2zl8j_0xgwnn1y9r0000gn/T/wireshark_Standard inputYHRVP2.pcapng"
** (wireshark:86816) 14:41:01.402738 [Capture MESSAGE] -- Capture stopped.
In these latter two examples tcpdump's stderr status messages do not interfere with tshark's tshark and wireshark's wireshark from successfully reading from stdin.