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

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

> ... the "option menu" offering various link-layer types in the "Capture
options" dialog box lets you select.

Version 0.99.6a (SVN Rev 22276) seems to have HAVE_PCAP_LIST_DATALINKS *NOT*
compiled in. Is that correct? Do I need to compile my own version of
wireshark to use this feature? I am trying to avoid device-specific mods
wherever possible.

Thanks

Will

-----Original Message-----
From: Will Barker [mailto:w.barker@xxxxxxxxx] 
Sent: 20 November 2007 16:51
To: 'Developer support list for Wireshark'
Subject: RE: [Wireshark-dev] Extending wireshark's capture capabilities

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.

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

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

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

I don't believe there are - but will check

> HAVE_WANPACKET_API build problems

I've sorted these out - they were due to an incorrect PSDK installation

> That's because there isn't yet a DLT_LAPB.  You'd need to ask for a LAPB 
DLT_ value on tcpdump-workers@xxxxxxxxxxx.

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

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

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

Yes exactly - thanks for the info on this - I'm digesting it now...

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

Thanks

Will

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

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?