Wireshark-dev: Re: [Wireshark-dev] Extending wireshark's capture capabilities
Date Index · Thread Index · Other Months · All Mailing Lists
Date Prev · Date Next · Thread Prev · Thread Next
From: "Gianluca Varenni" <gianluca.varenni@xxxxxxxxxxxx>
Date: Mon, 19 Nov 2007 12:12:22 -0800
----- Original Message ----- From: "Will Barker" <w.barker@xxxxxxxxx> 
To: "'Developer support list for Wireshark'" <wireshark-dev@xxxxxxxxxxxxx>
Sent: Monday, November 19, 2007 12:01 PM
Subject: Re: [Wireshark-dev] Extending wireshark's capture capabilities




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?].
Can you please contact me privately (or better, on the winpcap-bugs mailing list)? There shouldn't be any problem compiling packet.dll with support for WAN_PACKET. 

Have a nice day
GV





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

_______________________________________________
Wireshark-dev mailing list
Wireshark-dev@xxxxxxxxxxxxx
http://www.wireshark.org/mailman/listinfo/wireshark-dev