configure extcap sshdump

hey grahamb

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

Yes uppercase, see the dumpcap manpage for more info.

@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.

@sindy tcpdump does not support the can frames apparently :

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.

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

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?

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 -.

What is the Wireshark version?

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?

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".

@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

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?

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

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.

Ok then, let's file a bug.

Please report the bug number here in a comment.

bug 13899