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

From: Stephen Donnelly <stephen@xxxxxxxxxx>
Date: Wed, 21 Nov 2007 10:36:48 +1300
On Tue, 2007-11-20 at 12:49 -0800, Guy Harris wrote:
> Will Barker wrote:
> >> 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. :-)

Endace DAG cards cover a huge variety of physical and link layers, so
there are a very large number of configurable parameters across the
range. Some of these parameters are purely link related such as link
rate, scrambling, crc length etc, while other items are Endace or DAG
card specific.

It did not seem reasonable to us to burden libpcap/Winpcap/Wireshark
with APIs or UI code to deal with all the possible configuration
parameters. Our approach has been to keep the card and link
configuration separate, and assume that the user has correctly
configured the card for the link before starting the capture application
such as Wireshark.

A further reason for this decision is that Wireshark does not currently
attempt to configure NIC card parameters, e.g. via Ethtool in Linux.

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

If a 'generic' configuration layer was added to
libpcap/Winpcap/Wireshark, perhaps starting with support for Ethtool,
Endace would consider supporting DAG card configuration via the same
mechanism.

Stephen.
-- 
-----------------------------------------------------------------------
    Stephen Donnelly BCMS PhD           email: sfd@xxxxxxxxxx
    Endace Technology Ltd               phone: +64 7 839 0540
    Hamilton, New Zealand               cell:  +64 21 1104378
-----------------------------------------------------------------------