----- 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 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 [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 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:[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 _______________________________________________ Wireshark-dev mailing list [email protected] http://www.wireshark.org/mailman/listinfo/wireshark-dev
