I am trying to work on a package that will monitor the AP for certain events, such as association and disassociation. I could do this (I believe) as a script running a polling loop doing "wl assoclist", but I want to get timely updates without excessive overhead. If I put a large delay in the polling loop, I won't get timely updates. If I use a short delay, I'll get excessive overhead. Timely updates would be critical to handling the case of a station moving from one AP to another.

From what I've read about the wireless extensions, it looks like I might be able to write an application that would receive association and disassociation events, but I'm not sure. My two basic questions are:
1) Would the broadcom wl driver support this feature of wireless extensions?
2) Which of the WE APIs would I use to receive these envents? Is there any existing (publically available code) that does something like this?

I feel bad asking an open-ended question such as this, but I've spent several days searching the web to no avail. It appears that in v18 of the WE, they added the event type IWEVASSOCREQIE, which seems to suggest that one can receive an event when an association is made, but I can't figure out how to actually receive the event. I'm wondering if this is only applicable to scanning, which wouldn't help me as you need to bring the radio off-line to scan.

Even if one cannot receive associations as an event, there is presumably some way for the application to get a list of associated APs, since the "wl" application needs to do this. Would anyone have any idea how to do this?

Thanks. Any insight or pointers to where I could explore further would be greatly appreciated.

--Jim

I hate to break it to you but the broadcom wl driver doesn't support the wireless extensions (WE) -- we faked it by writing an intercept/translate module called wlcompat. The job of wlcompat is to hook into the ioctl mechanism and look for WE messages and translate them to broadcom proprietary messages; it works but it's somewhat imprecise, there's no direct mapping for some commands and there's no broadcom documentation.

In short, all we know about the wl.o module is inferred from the headers and the interaction with the wl utility and nas.

Time to get rid of the Broadcom binary crap. How difficult is to get the open driver to full production mode?

Well yeah, everyone knows that we need to switch to the opensource bcm43xx, and that the existing binary only stuff is keeping us on 2.4. The reality is that the bcm43xx module isn't ready and probably won't be ready any time in the immediate future.

If you have the time and knowledge you can try contributing to that project, but there's really nothing to do but wait otherwise.