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

["Gianluca Varenni" <gianluca.varenni@xxxxxxxxxxxx>]

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