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

["Will Barker" <w.barker@xxxxxxxxx>]

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

Yes I just mean though that when wireshark/dumpcap enumerates available
capture devices it does so via wpcap.dll:pcap_findalldevs and this currently
(on Windows - i.e. fad-win32) *only* uses PacketGetAdapterNames to locate
all the devices (i.e. via packet.dll). I assume that no one else has
appended their device to the list returned by packet.dll (from within wpcap)
- instead they have either 
a) replaced the enumeration method entirely, hence the alternative
fad*:pcap_findalldevs implementations 
OR
b) extended packet.dll to support their device

Will

-----Original Message-----
From: Guy Harris [mailto:guy@xxxxxxxxxxxx] 
Sent: 20 November 2007 20:50
To: w.barker@xxxxxxxxx; Developer support list for Wireshark
Subject: Re: [Wireshark-dev] Extending wireshark's capture capabilities

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