Wireshark-dev: Re: [Wireshark-dev] Extending wireshark's capture capabilities
From: Guy Harris <[email protected]>
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
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
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

a)  selecting the type of line encoding for sync lines e.g.  NRZ, NRZI, FM0
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
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 
	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.)