[Guy Harris <guy@xxxxxxxxxxxx>]

On Jan 26, 2020, at 12:46 AM, Erwin Rol <mailinglists@xxxxxxxxxxxx> wrote:
> 
> Hey all,
> 
> I was wondering if there is a remote capture "protocol" that works on
> Mac, Windows, and Linux? 
> 
> The idea I have is to use a small (and cheap) microcontroller like a
> STM32F407 that can capture a fieldbus (RS485 based, etc.) and relay
> that in realtime (realtime as in not storing it locally) to a PC
> running Wireshark.
> 
> I could simply pack it in some UDP protocol and write a dissector for
> that, but than I would loose my timing information, because it will be
> the timing of wenn the UDP packet has been received and not the time of
> when the fieldbus packet was received.

Then pack it in a UDP protocol *where the UDP packets include local time stamps as well as packet data*.

> Is there already anything out there that supports transporting capture
> data (including timing) over Ethernet that works on all 3 major
> platforms (rcap seems windows only,

If you mean rpcap, only WinPcap has *builtin* support; the *client and server code* is present in current versions of libpcap, but it's only compiled in by default in Windows - for other OSes you have to run the configure script or CMake with an argument to request it.

> ssh seems linux only,

No, it should work with all UN*Xes - libssh doesn't ship with macOS, so we provide it as part of the Wireshark application bundle - and we might also provide libssh with the Windows installation as well.

> and both are to heavy to implement on a microcontroller).

An independent implementation of rpcap - probably without some features such as password authentication - might be possible.  However, the authentication and control part of the protocol requires TCP; there's no 100% UDP version.

The "Peek remote" protocol, originally implemented by AG Group/Wildpackets for the *Peek packet analyzers for capturing Wi-Fi traffic from access points and other network devices, just encapsulates network packets in UDP datagrams, with a header that gives metadata such as the timing information.  That involves manually setting up the capturing machine, giving the IP address of the remote machine and possibly a port number, and then setting up the machine from which you're sending, giving *it* the IP address of the capturing machine.  It sends packets to a particular port on the capturing machine.

Something such as that might work.  A scheme in which:

	there's a well-known port number for the remote capture service;

	the capturing machine sends a "please start sending me packets" message to that port on the remote machine, giving a port number on the capturing machine;

	the remote machine starts sending encapsulated packets to the port in question on the capturing machine;

	the capturing machine can send a "please stop sending me packets" message to the well-known port to stop the capture;

might make it more convenient.  I don't know whether I'm missing a reason why, apparently, neither Aruba nor Cisco came up with something such as that.

Now, neither of those will work without writing code on the capturing machine side, but an extcap module would probably work, and should work on all platforms.