Wireshark-dev: Re: [Wireshark-dev] Extending wireshark's capture capabilities
From: "Gianluca Varenni" <[email protected]>
Date: Mon, 19 Nov 2007 12:12:22 -0800
----- Original Message ----- From: "Will Barker" <[email protected]>
To: "'Developer support list for Wireshark'" <[email protected]> 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 wiresharkwhere they are being successfully decoded. I have encountered some problemsalong 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 [email protected] 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 affectedb) otherwise, as packet.dll continues to be developed, we'd need to continueto maintain it/merge in our support etc. in addition to wpcap 2) The 18.104.22.1681 version of packet.dll won't build for me withHAVE_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 theuser is limited to the functionality offered by the version of packet.dll atthe 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 replacementof wpcap.dll/packet.dll? Depending on whether our device-specific componentsget 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 usbut it does present some limitations compared with the wtap/wtap_phdr/(WTAP_ENCAP_*)-based format (which it converts the capturedframes to internally before being processed by the dissectors i.e. using thepcap_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 fordecoding to be carried out based on, say, WTAP_ENCAP_LAPB since there is nomapping 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 thereis 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 setso that the decoder can display the correct DCE/DTE direction - this onlyappears to be an option when reading a capture file in some other format andthen internally converting to wtap format? It would be great if the device-specific capture support could specify ageneric (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/detectionb) to configure device-specific capture attributes e.g. clocking parametersetc. 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:[email protected]] Sent: 18 September 2007 01:05 To: [email protected]; 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 [email protected] mailing list or, for Windows-specific issues, [email protected] list.= _______________________________________________ Wireshark-dev mailing list [email protected]http://www.wireshark.org/mailman/listinfo/wireshark-dev
- Re: [Wireshark-dev] Extending wireshark's capture capabilities
- From: Will Barker
- Re: [Wireshark-dev] Extending wireshark's capture capabilities
- Prev by Date: Re: [Wireshark-dev] Extending wireshark's capture capabilities
- Next by Date: Re: [Wireshark-dev] Extending wireshark's capture capabilities
- Previous by thread: Re: [Wireshark-dev] Extending wireshark's capture capabilities
- Next by thread: Re: [Wireshark-dev] Extending wireshark's capture capabilities