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

I now have my own device capturing frames and passing them up to wireshark
where they are being successfully decoded. I have encountered some problems
along the way so I wonder if someone could confirm my findings and let me
know if any of my conclusions are incorrect. Some of this is inter-related
to some winpcap issues so I will take up any independent winpcap-specific
issues on winpcap-users@xxxxxxxxxxx as Guy suggested below.

1) Inline with the realtime capture support currently offered on Windows by
other device types, 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

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

3) Any ideas on how our installation process should handle the replacement
of wpcap.dll/packet.dll? Depending on whether our device-specific components
get installed before or after wireshark, we could end up with incompatible
wpcap.dll/packet.dll files in system32.

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

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. Was
this the intention of the WTAP_ENCAP_PER_PACKET value? - but that doesn't
seem to have been adopted(yet?)

5) When using a frame-based decoder e.g. packet-lapb, is there no
standard mechanism for showing the direction of the packet (other than by
using the pseudo_header as discussed in 4b above)?. Depicting a frame's
direction using a different colour would be great i.e. based on whether it
was sent or received

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

Thanks

Will

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


On Sep 17, 2007, at 5:21 AM, Will Barker wrote:

> We currently produce PC-based WAN products. These include support  
> for synchronous protocols such as X.25, PPP etc.
>
> We can currently capture frames using our own drivers/applications  
> on Windows and linux, save this information to file (in libpcap  
> format) which can then subsequently be read by wireshark.
>
> While this is useful it would be great if we could achieve the same  
> thing but in real-time.
>
> I assume that this could (technically) be achieved on Windows either  
> by
>
> 1)    extending winpcap in someway to enable it to capture our  
> frames and pass them up to Wireshark
> 2)    sit alongside winpcap and offer the frames up to wireshark  
> directly ourselves
>
> I assume 2) would require us to produce our own capture driver (NDIS  
> on Windows) which Wireshark would see as a pseudo LAN driver and we  
> could pass our WAN frames up to it using some (libpcap-based?)  
> format or other?

The only way to offer frames to Wireshark would be through libpcap/ 
WinPcap or via a pipe; the latter works better than the former.

That means 1) is probably your best bet.

> Can anyone point me in the right direction as to how to achieve  
> this? Developing the NDIS driver itself is not a problem since we've  
> lots of experience there - the issue is one of interfaces and what  
> is required in that regard in order for us to interface to wireshark  
> as seamlessly as possible.

Take a look at the libpcap/WinPcap source.  Look both at the pcap- 
win32.c file and the pcap-linux.c file, in the pcap_open_live()  
routines.

Look first at pcap-linux.c; the Linux pcap_open_live() has code at the  
beginning that looks for particular strings in the device name and, if  
it sees them, calls special open routines.

For Windows, you should pick device names that don't match a device  
name you'd see on Windows (if you restrict yourself to NT 5.x and  
later, i.e. W2K and later without Windows Me, that should be easy, as  
the device names you see on Windows are ugly blobs with a GUID in the  
middle), and, for Linux, do the same.  If you find a matching name,  
call your own open routine.  See pcap-dag.c for an example of how  
that's done - you write your own routines to perform operations such  
as reading packets, and set function pointers in the pcap_t structure  
to point to those routines.

> The next question would then be - how to achieve the same thing on  
> linux?

See above.  The bulk of the changes should be somewhat similar on  
Windows and Linux.

Further questions about this should probably be asked on the
tcpdump-workers@xxxxxxxxxxx 
  mailing list or, for Windows-specific issues, winpcap-users@xxxxxxxxxxx 
  list.=