I never tested with a named pipe on linux, only on Windows, where the capturing process waits for the receiver to connect to the pipe, then starts writing to it, and when the receiver disconnects again (which is a consequence of pressing "stop" in Wireshark), the capturing process terminates. If the result of "my" test is a file of 50 packets about which Wireshark does not complain, and the result of Harris' test is still a 0 B file, you know for sure that both tcpdump and ssh are OK if you use tcpdump with -w - and 2>/dev/null.įinally, try again with the named pipe, first also with the -c 50. This will make tcpdump stop the capture after first 50 packets. So please repeat both tests above with additional parameter of tcpdump, -c 50. You need to be extremely lucky that only part of the last packet would not be written to the output file in this case. The capture file appears to have been cut short in the middle of a packet is a consequence of the fact that you've stopped the ssh and tcpdump together by pressing ^C, so both processes were killed abruptly, not gracefully. So if tcpdump would be printing something to stdout, it would be the only output remaining, but the resulting file size is 0 bytes.īut there is still some space left for doubt. w /dev/null 2> /dev/null indicate that stderr should go to trash and the binary pcap data should also be written to trash instead of stdout (while -w - means to use stdout for the binary pcap data). Both tests seem to indicate that there must have been some typo in your original attempts, because:Ģ> /dev/null prevents tcpdump's stderr from being grabbed by the ssh session at the server and thus intermixed with the contents of the capture file at the client (as Harris wrote, ssh mixes stdout and stderr together at server end so you cannot split them back at client end) Ssh "echo thePassword | sudo -S tcpdump -s 0 -n -w -U -i eth0 not port 22 2>/dev/null" > /tmp/remotecapture
Ssh "tcpdump -s 0 -n -w -U -i eth0 not port 22 2>/dev/null" > /tmp/remotecapture Tcpdump: listening on eth0, link-type EN10MB (Ethernet), capture size 65535 bytesĬheck Guy Harris' answer below and my comment on 14 Feb When Wireshark threw an error regarding libpcap format, I also tried clipping the first line that's passed before the raw packets, to no avail though. Redirecting to a simple file does work but not in a format Wireshark can read later. No packets captured! As no data was captured, closing the temporary capture file!.Ssh -t "tcpdump -s 0 -n -w -U -i eth0 not port 22" > /tmp/remotecapture.fifoĪnd tried some variations that resulted in I set a remote capture to a host using tcpdump and a named pipe like so
0 kommentar(er)
