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 ___________________________________________________________________________ Sent via: Wireshark-dev mailing list <[email protected]> Archives: http://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev mailto:[email protected]?subject=unsubscribe
