On Wed, 2006-01-04 at 13:35 +0100, Jiri Benc wrote: > The list wasn't complete, it was the things that need (from my POV) to > be resolved first only. There are more issues - some of them are known > to me, including this one, but I have them stored mostly as comments at > corresponding places in my development tree. I will try to extract them > into some nice todo list accessible to others.
That'd be great :) > /* TODO: implement register/unregister functions for adding TX/RX handlers > * into ordered list */ Yeah, I've seen that, though couldn't really make sense of it. > The frames really goes through all of decryption functions but they are > not tried to decrypt, the functions return at they beginning. This > probably can be optimized. And many other parts of the code need > optimization too. Ok. > > What's with CONFIG_OAP_LEDS_WLAN? Shouldn't that LED handling function > > be a pointer that can be assigned to whatever one wants, and you could > > then get rid of IEEE80211_LEDS etc? > > LED handling seems strange. It probably depends on some other stuff not > released by Devicescape, I would suspect something responsible for > handling LEDs on their AP boxes or so. Makes sense. With the broadcom cards that have LEDs this could be interesting, but in the current form the code seems just useless. > It's not vlan. Some devices are capable to associate to multiple APs and > you need to present this to userspace by more interfaces. The same with > WDS links. Ah. That makes sense. Didn't know that was supported. Oh another question: is the stack capable of having a raw device associated with the actual hardware device that sees all incoming and outgoing frames including 802.11 headers? I'd love to have that for debugging... Thanks for your quick reply. johannes
signature.asc
Description: This is a digitally signed message part
