On 4/3/12 9:00 AM, Guy Harris wrote:
>
> On Apr 3, 2012, at 10:33 AM, Jeff Morriss wrote:
>
>> *My* intent was to revert back out my change to go back to what Joerg had intended in r34356. That revision says the intent was "to increase common source code coverage".
>
> I assume by "coverage" he means "testing the code to make sure it builds, even if it never runs" (so that non-Windows developers are less likely to make a change that breaks the build on Windows).
>
>> I think I had also see some comments (r28285, for example) about wanting/trying to get the AirPcap GUI working on Linux. I don't know much more than that since I don't have one of the devices to play with. Joerg?
>
> There's "making the AirPcap GUI work on Linux", which I would instead state as "providing common GUI code on Windows-with-AirPcap, Linux, and possibly other platforms to allow the user to select an 802.11 channel on which to capture", and there's "making AirPcap work on Linux", which involves driver work (whether kernel-mode or user-mode) and might involve reverse engineering (I seem to remember one of the CACE people indicating that at least one of the AirPcap adapters used Broadcom hardware, and they got the documentation for it under non-disclosure - Broadcom are as secretive about at least some of their hardware as one of its founders was about his alleged private life - if your browser is set up to support Google's search suggestion feature and you haven't disabled it, try typing
>
> henry nicholas d
>
> and see what it suggests. :-))
>
> For "providing common GUI code on Windows-with-AirPcap, Linux, and possibly other platforms to allow the user to select an 802.11 channel on which to capture", ultimately, libpcap should support APIs for getting a list of supported channels and setting the channel for 802.11 adapters, so that programs won't have to worry about the details of how to set the channel on different OSes, and WinPcap should support those APIs on AirPcap adapters, and then Wireshark could use those APIs. Unfortunately, my supplies of Copious Free Time(TM) are a bit depleted, so I haven't had time to work on that; Wireshark could do that itself for the platforms on which it can be done:
Bug 6973 contains a patch for a wireless toolbar which uses the Netlink
library (libnl). This would fix the problem on Linux but it wouldn't use
common code.
--
Join us for Sharkfest ’12! · Wireshark® Developer and User Conference
Berkeley, CA, June 24-27 · sharkfest.wireshark.org