On Sat, 2006-01-07 at 20:17 +0100, Stefan Rompf wrote: > Caveats: > -rfmon can affect all virtual devices as Mike pointed out
See my reply to him. > -As a matter of fact, virtual devices are not independant eveb without rfmon, > simply because one physical device can only tune to one channel at a time Same here. Cards that can't do this properly disallow some settings. Or e.g. if you have an AP virtual device then you can't change the channel on the virtual STA device etc. > -Which link type should be used by the virtual device? Is it easier to change > all protocols to support 802.11 frames or is ethernet emulation mode > simplest? > -If we use 802.11 natively, should we always tack on radiotap headers? imho it should use 802.11 natively but not tack on radiotap headers (overhead?) unless for a rfmon virtual device. > Questions: > -what happens to iwpriv? It goes away. > -where are the netlink messages/wireless extensions handled? Should the > device > driver forward into the stack, or should the stack call into the device > driver? I think the "stack" provides demultiplexing and validation of the data received from userspace and then calls into a driver method to handle the changed configuration, which makes the driver again call some 'stack library' methods to make that configuration. IOW the driver validates the configuration and rejects it if necessary, and the 'stack library' applies it. > c)which stack to use? Actually, it's intel vs. devicescape. I'm about to port > the driver of a popular card to devicescape to get a personal opinion. I think neither of the two support what we want. dscape is closer, and we may be able to work from there. > I think we should start discussing a), beginning with b) when we have > answered > most questions concerning a). right. johannes
signature.asc
Description: This is a digitally signed message part
