This is a static archive of our old Q&A Site. Please post any new questions and answers at

configure extcap sshdump



I'm trying to use the remote ssh functionnality to capture CAN frames (virtual vcan0) But I have got an error message, see below :

alt text
Can someone help me ? Thank you. Cheers.

@sindy /usr/sbin/tcpdump -i can0 -w /tmp/can_test.pcap is ok: the file generated by the remote machine (beaglebone black) is readable by WS on the local machine

However, with the plain tcpdump, no packets are captured: alt text alt text

So the functionnality ssh remote does not work with your indications.

The only way I found to capture these packets is describe below (as evidenced by) :

  1. I log on the remote
  2. create a pipe
  3. start WS

Then the packets are captured:

ssh [email protected] "dumpcap -i can0 -P -w -" | wireshark -k -i -

alt text

asked 12 Jul '17, 08:27

lamoule74's gravatar image

accept rate: 66%

edited 25 Jul '17, 03:29

grahamb's gravatar image

grahamb ♦

I guess your capture filter syntax is incorrect. Can you provide all of your remote ssh options including your remote capture filter?

(12 Jul '17, 13:41) cmaynard ♦♦

Actually I don't have a filter... When I'm using WS without "normally", I'm not lauching the sniffing interface without a filter, I specify the filter CAN with dissector j1939 later..

See below

alt text

A detail : I'm trying this from a virtual machine.

I'll try with a true session...

(12 Jul '17, 23:40) lamoule74

I think this is a known bug in the ssh interface. Try using a single space as "Remote capture filter".

(13 Jul '17, 02:01) stig ♦

hey Stig, it displays a different error message :

alt text

(13 Jul '17, 04:50) lamoule74

dumpcap produces pcapng by default which isn't supported for pipes, so you need to append a -P to the command. I'm not certain if that should be added to the "Remote capture binary" or the "Remote capture filter" fields.

(13 Jul '17, 05:43) grahamb ♦

hey grahamb

command unknow with -P. this is a p capslock right?

alt text

(13 Jul '17, 06:25) lamoule74

Yes uppercase, see the dumpcap manpage for more info.

(13 Jul '17, 08:20) grahamb ♦

@lamoule74, can you request tcpdump instead of dumpcap down there on the remote machine? For tcpdump, pcap is the default output format when capturing on a single interface. As you use no capture filter, the fact that with dumpcap it needs to be prepended with -f while with tcpdump it goes directly should not cause issues.

(13 Jul '17, 09:39) sindy

@sindy tcpdump does not support the can frames apparently :

alt text

(18 Jul '17, 08:57) lamoule74

That's a misinterpretation of the error message. It says exactly what it reads: packet printing is not supported, i.e. the simple packet dissection engine of tcpdump has no clue about the internals of the CAN frames, but nevertheless they can be written to a file (as in this case no dissection is necessary). Same case e.g. with USB frames.

So use /usr/sbin/tcpdump -i can0 -w /tmp/can_test.pcap and then download can_test.pcap to the machine running Wireshark and open it there. If this works, remote ssh capture spawning tcpdump should work as well, because it does use -w - to allow piping of pcap rather than text output.

(18 Jul '17, 09:16) sindy

@sindy The cuplrit seems to be the "Remote capture binary" text field: alt text

No args are allowed (I've also tried with simple and double quotes).

If I try the /usr/sbin/tcpdump -i can0 -w - in a shell, I can capture packets.

Do you know how to add args to the capture binary field?

(19 Jul '17, 00:03) lamoule74

No, the culprit of this particular failure is @lamoule74 :-)

You have logged in to the remote machine in order to test /usr/sbin/tcpdump -i can0 manually (as documented by your screenshot). So I have expected you to do exactly the same, just adding the -w /tmp/can_test.pcap part, to check that the contents of the resulting pcap file stored on the remote machine would be useful as I expected.

You have instead tried to add -w /tmp/can_test.pcap into the remote capture binary field of the ssh remote capture form of Wireshark.

There, you should have placed just the plain tcpdump. The ssh remote capture will itself add -w -.

(19 Jul '17, 04:51) sindy

What is the Wireshark version?

(19 Jul '17, 07:23) grahamb ♦

I must let someone else convert your Answer into a Comment, I'm getting an error when trying.

Can you log in to the remote machine, run the remote capture with "plain tcpdump" as shown below, and while it is running, use ps axfw | grep tcpdump on the remote machine and paste here the result?

(19 Jul '17, 07:25) sindy

I could not convert it either. The best I could do was append the "answer" to the end of the question and delete the "answer".

(19 Jul '17, 07:36) cmaynard ♦♦

@grahamb the version is 2.2.7-1 I've also tried the 2.2.6

@sindy here is the result of the command line :

[[email protected]:~] $ ps axfw | grep tcpdump 1284 ? Ss 0:00 | \_ /usr/sbin/tcpdump -i can0 -w - -f 1444 ? Ss 0:00 | \_ /usr/sbin/tcpdump -i can0 -w - -f 1522 ? Ss 0:00 | \_ /usr/sbin/tcpdump -i can0 -w - -f 1553 ? Ss 0:00 | \_ /usr/sbin/tcpdump -i can0 -w - -f 1573 ? Ss 0:00 | \_ /usr/sbin/tcpdump -i can0 -w - -f 1619 pts/2 S+ 0:00 | \_ /usr/sbin/tcpdump -i can0 -w - 1648 pts/3 S+ 0:00 \_ grep tcpdump 1111 ? Ss 0:00 /usr/sbin/tcpdump -i can0 -w - -f

(19 Jul '17, 07:53) lamoule74

A bit crowded down there I'd say, I guess you are not actually running that many captures. These are most likely zombies from previous sessions so it deserves a cleanup. Most likely also their parent ssh sessions have survived so there is likely a lot of zombie processes on the machine running Wireshark.

Otherwise the command line composed by remote ssh capture seems fair to me. -f has a different meaning for tcpdump than for dumpcap, but luckily it is a harmless one (just tried).

I would assume that tcpdump only has access to interfaces as root, and that is the reason why no data are received, but it is just a wild guess at the moment. So if you use the same user for direct login to beaglebone like you do for remote ssh capture, forget that I've mentioned that.

Maybe you could provide full path to dumpcap, much like you do for tcpdump, and add the -P option to it in the Remote capture binary field?

(19 Jul '17, 08:35) sindy

I tried to reboot the beaglebone to prevent any side effect from the previous sessions. The -f arg is probably added by WS because I didn't try this arg on the command line.

I added the debian user of the beaglebone to the wireshark group and tcpdump can capture packets when launched from the command line (not with WS). There is probably no need to switch to root. But I will try.

dumpcap -P is one of the first thing I tried, but the Remote capture binary field doesn't let me add any command containing arguments (see screen capture above). If I write something else than dumpcap, WS fires an error message Error by extcap pipe: bash dumpcap -P : command is missing

(19 Jul '17, 12:37) lamoule74

If stating "dumpcap -P" to the Remote capture binary field (including the "") doesn't help either, I'd say you've collected enough evidence to file a bug or even two:

  • I can see no reason why tcpdump should not work (as said, the -f is not harmful and the -w - is correctly added automatically as the output of ps confirms),

  • I can see no reason why it should not be possible to add parameters to binary name, given that dumpcap by default (i.e. without a command-line option) uses pcapng format, which is known not to be supported when using input pipes, even if capturing on a single interface.

There is also bug 11370 asking for support of pcapng at queue input.

(19 Jul '17, 13:06) sindy

Ok then, let's file a bug.

(20 Jul '17, 00:41) lamoule74

Please report the bug number here in a comment.

(20 Jul '17, 03:00) grahamb ♦
(20 Jul '17, 04:38) lamoule74
showing 5 of 22 show 17 more comments

One Answer:


It seems to work with 2.4.0 and "Remote capture command" field set to dumpcap -i can0 -P -w -

The "Remote interface" field seems to be ignored and -w - isn't added automatically, so I added the full command with parameters to make it work as below:


answered 25 Jul '17, 03:05

lamoule74's gravatar image

accept rate: 66%

edited 25 Jul '17, 06:25

sindy's gravatar image