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

[Guy Harris <guy@xxxxxxxxxxxx>]

Will Barker wrote:

> 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 have had to modify both wpcap.dll and packet.dll i.e.
> as with HAVE_DAG_API, HAVE_AIRPCAP_API etc. Whilst this is feasible for us,
> it would be better if our changes could be limited to just wpcap itself
> since
> a) we obviously want to minimise the code-based affected
> b) otherwise, as packet.dll continues to be developed, we'd need to continue
> to maintain it/merge in our support etc. in addition to wpcap

Unless you're accessing your device through NDIS, if there's a need to 
modify packet.dll, that's a bug or, at least, a misfeature.

The APIs that come with libpcap connect to the function pointers in the 
"struct pcap" structure; originally, the APIs added by WinPcap didn't 
connect to any such function pointers, but another person extending 
WinPcap had a problem due to that, so I connected some of them to 
function pointers.  That change is in the current top-of-tree libpcap 
CVS, and it might be in WinPcap 4.1 beta 2.

If there are any that remain that require you to modify packet.dll, 
please let me know, so I can fix it ASAP (so that the fix will be in 
libpcap 1.0 and WinPcap 4.1).

This is a WinPcap issue, probably best discussed on the winpcap-users 
mailing list (although there are libpcap developers and WinPcap 
developers on this list as well).

> 2) The 4.0.0.901 version of packet.dll won't build for me with
> HAVE_WANPACKET_API since some dependencies don't exist e.g. netmon.h. I have
> therefore had to build without that option [Anyone aware of an issue here?].
> This demonstrates the types of issues with 1) above i.e. if we install our
> packet.dll (in order to provide support with our capture device) then the
> user is limited to the functionality offered by the version of packet.dll at
> the point that we built our version (as opposed to whatever is offered by
> the version of winpcap that the user has actually installed).

That's a WinPcap issue.

> 4) wireshark only appears to support realtime capture via the libpcap format
> (by virtue of it piping the output back from dumpcap). That works OK for us
> but it does present some limitations compared with the
> wtap/wtap_phdr/(WTAP_ENCAP_*)-based format (which it converts the captured
> frames to internally before being processed by the dissectors i.e. using the
> pcap_to_wtap_map array). For example,
>
> a) whilst it is possible to decode based on WTAP_ENCAP_PPP by specifying a
> (libpcap) linktype of DLT_PPP_SERIAL, it is not possible to arrange for
> decoding to be carried out based on, say, WTAP_ENCAP_LAPB since there is no
> mapping to WTAP_ENCAP_LAPB in the pcap_to_wtap_map array

That's because there isn't yet a DLT_LAPB.  You'd need to ask for a LAPB 
DLT_ value on tcpdump-workers@xxxxxxxxxxx.  (Again, ask ASAP, so I can 
try to get it into libpcap 1.0; there will probably be some discussion, 
mainly concerning whether the packet begins with the address field or 
with some extra metadata such as direction information - that'd mainly 
affect the name of the DLT_ value.)

> b) even if there were a DLT-to-WTAP_ENCAP mapping to WTAP_ENCAP_LAPB there
> is no mechanism available to setup the wtap-based pseudo_header based on any
> info in the libpcap "file" so that, for instance, the x25.flags could be set
> so that the decoder can display the correct DCE/DTE direction - this only
> appears to be an option when reading a capture file in some other format and
> then internally converting to wtap format?

Libpcap format doesn't include a direction indication (pcap-NG does, but 
it's not yet supported); that information is usually supplied by adding 
some pseudo-header information to the packet data at the beginning. 
See, for example, the way DLT_MTP2_WITH_PHDR (value 139; search for 
WTAP_ENCAP_MTP2_WITH_PHDR in wiretap/libpcap.c) is handled.

> It would be great if the device-specific capture support could specify a
> generic (DLT/libpcap) linktype and then each frame have its own WTAP_ENCAP*
> value. This would then give the user the option of simply specifying an
> appropriate WTAP_ENCAP value for any particular capture session/frame.

What is the purpose of this?  Is it to deal with a device that captures 
on, for example, a generic WAN bitstream, where the device has to be 
told whether it's LAPB or PPP or...?

If so, the way to handle that is the same way that it's handled for the 
DAG device.

A mechanism was introduced in libpcap to support the way recent BSD 
variants handle 802.11 devices - they allow the application to select 
which link-layer header to supply on a particular capture stream 
(Ethernet, 802.11, 802.11 plus radio information).  Libpcap APIs were 
added to get a list of the link-layer types that a pcap_t could support, 
and to set the link-layer type to one of them.

That mechanism is also used for DAG devices - the list of link-layer 
types pcap-dag.c supplies is based on the list of link-layer (ERF) types 
supported by the device, so, for example, one of their PDH/TDM cards 
would offer DLT_CHDLC (Cisco HDLC), DLT_PPP_SERIAL (PPP), and DLT_FRELAY 
(Frame Relay), and the application can select one of those.

That mechanism is supported by Wireshark - that's what the "option menu" 
offering various link-layer types in the "Capture options" dialog box 
lets you select.

> Was
> this the intention of the WTAP_ENCAP_PER_PACKET value? - but that doesn't
> seem to have been adopted(yet?)

WTAP_ENCAP_PER_PACKET was introduced because Wiretap supports more than 
just libpcap format, and some of the file formats support captures with 
multiple packet types.  Not all WTAP_ENCAP values are supported by libpcap.


> 6) If we were to need some capture-device-specific UI e.g.
>
> a) to enable the user to override our automatic frame/link-type
> selection/detection

As per the above, that's already supported by libpcap/WinPcap and by 
Wireshark, and isn't device-specific.

> b) to configure device-specific capture attributes e.g. clocking parameters
> etc.
>
> is there someway we should hook that UI to wireshark - should it be some
> standard type of snapin? E.g. the interface-specific "Capture
> Interfaces"-Options button looks an obvious candidate from a
> user-perspective?

Ideally, there should be a standard libpcap/WinPcap API for that, so 
that multiple capture devices can use the same mechanism, and 
applications such as Wireshark can work with all of those devices 
without any need for device-specific plugins.

What are the capture attributes you need?