Huge thanks to our Platinum Members Endace and LiveAction,
and our Silver Member Veeam, for supporting the Wireshark Foundation and project.

Ethereal-dev: Re: [Ethereal-dev] Remote Capture Using rpcapd

Note: This archive is from the project's previous web site, ethereal.com. This list is no longer active.

From: Guy Harris <gharris@xxxxxxxxx>
Date: Thu, 28 Jul 2005 01:55:52 -0700
Ulf Lamping wrote:

Even if it's fixed, the usage of this feature is still a bit clumsy in our GUI. Putting all settings into a single interface line really isn't very intuitive. We (I) may add something to the capture options GUI so it become a bit more comfortable using some of the features from the WinPcap API.

Ultimately, we should probably have separate "remote host" and "device" fields, where a blank remote host means "local host". Ideally, the "remote host" field could be a combo box, although that needs discovery mechanisms. (Rendezvous^H^H^H^H^H^H^H^H^HBonjour might be one for rpcap; SLP might be another.)

There might be multiple remote capture protocols, e.g. Network Chemistry's TZSP, Microsoft's remote capture protocol for NetMon (if somebody reverse-engineers it), and perhaps even "ssh to the remote machine and run tcpdump or Tethereal". I'm not sure what the UI should be for that; the user shouldn't be *obliged* to specify it if an application can determine what protocol the remote machine uses (e.g., through the discovery mechanism), but they might have to specify it if a machine can't be discovered through such a mechanism.

BTW: I really would like to see support of this in libpcap. Are there any plans/thoughts that this remote capturing feature will become part of libpcap?

I'd like to see it in the next release, which I'd like to be a 1.0 release. I don't see a security problem with offering the client side, although if doing security right requires API work (I've been thinking that perhaps supporting GSS-API and SPNEGO might be the right way to handle authentication, so that the protocol and API don't commit to a particular authentication mechanism), we'd at least want to get the API right before releasing.