Wireshark-dev: Re: [Wireshark-dev] [Wireshark-commits] rev 20049: /trunk/ /trunk/epan/dissector
Date Index · Thread Index · Other Months · All Mailing Lists
Date Prev · Date Next · Thread Prev · Thread Next
From: Loris Degioanni <loris.degioanni@xxxxxxxxx>
Date: Thu, 07 Dec 2006 12:48:48 -0800
Joerg Mayer wrote:


Gerald,

On Wed, Dec 06, 2006 at 02:53:31PM -0800, Gerald Combs wrote:

The WPA code (specifically the modules in the airpdcap directory) is
Windows-specific because we might use same code base for WPA decryption
in Wireshark and in the Airpcap driver.  We're working on
de-Windows-izing the code, which should be done in the next few days.
At that point we can remove the HAVE_AIRPDCAP define.


:-)


BTW, we now have encryption code in airpdcap/* and epan/crypt-*.[ch].
(including duplicate MD5 implementations).  Should this all be moved to
a common directory, e.g. epan/crypt/?


Yes, I think that would be the proper place.


As far as the Airpcap code being Windows-specific: we've tried to
generalize it so that it can be adapted to other platforms.  There's no
reason the code that calls airpcap_if_set_device_channel() under Windows
can't (and shouldn't) use the SIOCSIWFREQ ioctl under Linux.


The long term best place would be an integration of the capture part of
airpcap into libpcap,
Yes, this would be the optimal option, but it would require adding to libpcap features that are not strictly "capture oriented", like setting a channel or configuring a set of decryption keys.
I'd like to hear what people think about extending libpcap in that direction (Guy?); if it's considered interesting, I could give it a try. 


but until such a time adding support for other
OSses into airpcap would be nice too.
That's another possibility. A standardized wireless configuration API would be a big contribution to the community. Think for example about how cleaner the kismet code would be without a different source for every available chipset. What concerns me is that I tried to design the AirPcap API in the most generic possible way, but my reference was still the CACE AirPcap adapter. A review of the API would be important before starting any porting. 


Btw, the files in airpcap (except the Makefile) lack copyright headers
and license information headers.


The license is BSD. Can you point me the files without license?
Thanks,

Loris


 Ciao
      Joerg