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

Wireshark-dev: Re: [Wireshark-dev] Extending wireshark's capture capabilities

From: Guy Harris <guy@xxxxxxxxxxxx>
Date: Tue, 20 Nov 2007 12:49:49 -0800
Will Barker wrote:
Thanks Guy for your very quick and informative response - comments below.

1) Inline with the realtime capture support currently offered on Windows
by other device types,
"Realtime capture support" in what sense? "Update list of packets in
real time"?

I just mean capturing/displaying in realtime as opposed to reading from a
file (of a previously recorded session). We've supported the latter for a
while now by enabling our captured data to be saved in libpcap format by our
apps.

That should work without packet.dll changes.

I'm not sure that there is an absolute *need* but I found myself going down
that path since the normal win32 cases seem to lead you that way e.g. to
fad-win32: pcap_findalldevs -> PacketGetAdapterNames etc.

That's not a modification of packet.dll; it's just using PacketGetAdapterNames() as the call on Windows, just as you use various ioctls or getifaddrs() on various UN*X systems. packet.dll is to WinPcap as the various low-level platform-specific capture mechanisms are to various UN*X systems.

I was also
influenced I think by the fact that other 3rd party support had been added
that way (e.g. DAG, AIRPCAP) but perhaps it was just done that way in order
to leverage already existing support within packet.dll for those devices? -
which could be useful independent on any wpcap/wireshark-specific usage?)

...or it might date back to a time before libpcap/WinPcap was set up to support add-on support for devices not using the standard capture mechanism.

OK - will do. However, that was just intended as an example. I was hoping
that there would be some way of decoupling DLT and WTAP values

No. WTAP values are internal values for Wireshark; capture files use DLT_ values (well, actually, they use LINKTYPE_ values as defined in savefile.c, but almost all of them are equal to the matching DLT_ values; the split is due to some cases where different platforms define the same DLT_ value differently - that can work for programs for a particular platform, but *doesn't* work for capture files that are supposed to be readable on *all* platforms).

so that it
wasn't necessary to add 1) a DLT value and b) a mapping to a WTAP_ENCAP
value in pcap_to_wtap_map in order to enable a pcap device to supply frames
of any particular WTAP_ENCAP value for decode.

It's intentional that they're separate. Libpcap/WinPcap, and the libpcap file format, are intended for use by multiple applications, so they're defined independently of Wireshark. Wireshark supports capture file formats other than libpcap, and those formats have link-layer header types not supported by libpcap, so it has its own set of link-layer type values.

See, for example, the way DLT_MTP2_WITH_PHDR (value 139; search for
WTAP_ENCAP_MTP2_WITH_PHDR in wiretap/libpcap.c) is handled.

Yes there does seem to be potential for doing the same with
WTAP_ENCAP_PPP_WITH_PHDR for instance?

Yes, but you'd need to use a DLT_ value that maps to WTAP_ENCAP_PPP_WITH_PHDR. There currently isn't one.

What are the capture attributes you need?

The kind of thing I'm referring to here is configuration for our card, for
example,

a)  selecting the type of line encoding for sync lines e.g.  NRZ, NRZI, FM0
etc.
b) selecting the line interface type e.g. V.24, X.21, V.35 etc.
c) for monitoring async lines, selecting the rate, # of stop bits, parity
etc.

Those sound as if they might be useful for other serial-port monitoring hardware; I don't know whether, for example, the API that Endace supplies for DAG cards supports setting those values, but, if it does, libpcap/WinPcap calls to set those properties could be used by DAG cards as well.

For now, you'd have to add your own APIs for that to WinPcap, and Wireshark would have to be modified to use it. You'd also want to have an API that can be used to determine whether a given device supports those APIs, so that you don't offer the ability to select a line interface type on a 802.11 network. :-)

(In the longer term, I'd like to have libpcap/WinPcap support an attribute-value-pair mechanism for device properties, so that

1) an application can query a device to find out what properties it supports;

2) that application can then set those properties either at open time or, if possible and appropriate, while the capture is in progress (e.g., the channel number for an 802.11 adapter);

	3) new properties can be added without having to add new API functions.)