> So, now we asked: How would a sane UI look like. We had a few points: > * The interface needs to support some kind of "master" interface to > configure the hardware, 80211 parameters and > to actually configure and setup the > * Virtual interfaces. > Data is transferred only though the virtual interfaces, which could > be an AP interface, a STA interface in INFRA or Ad-Hoc mode, etc... . > Configuration is done though the master interface. Two things to inject, from my own little corner of userspace: 1. Monitor mode formatting. I ported over the BSD radiotap packet header system, it's in the Intel and I beleive some versions of the Devicescape stacks. Using these would be a very good thing for userspace. If for some reason it isn't used, then we (userspace tool people) need something equivalent. I like radiotap primarily because: * Dynamic per-packet stats. Drivers provide what their firmware is capable of providing per frame. The more info provided the better. * Expandable headers. New per-frame stats can be added into the RT headers without changing linktype, breaking existing apps, etc. * Format indicators. Is the 4 byte FCS tacked onto the end of the frame in rfmon? If we don't know this in userspace, we can't do 802.11 validation, wep decoding, and other important stuff. Userspace shouldn't have to know which driver is being used, this ought to be in the frame headers. Radiotap provides all of those and is already supported by tcpdump, ethereal, kismet, etc. 2. RFMon is weird/breaks interfaces The other gotcha with rfmon is it often breaks a cards ability to associate (though less often with new cards). Even if it doesn't, whatever tool put it into rfmon is likely to want to take control of the channel hopping, which will interfere with the associations of other virtual interfaces. Currently single-interface cards (ethX, whatever) thrown into rfmon just plain break, it a pretty obvious way. The linktype changes, traffic stops, and users more or less understand this is going to be the behavior. Once virtual interfaces come into play, it may cause some confusion if you can make virtual interfaces that do sta, adhoc, ap all at once without conflicting, and suddenly bringing up an rfmon interfaces causes them all to break. I don't know if the solution to this is a warning, marking non-rfmon virtual interfaces down, or just saying "they'll figure it out", but I figured it's worth considering at an early stage. -m -- Mike Kershaw/Dragorn <[email protected]> GPG Fingerprint: 3546 89DF 3C9D ED80 3381 A661 D7B2 8822 738B BDB1 <>!*''# Waka waka bang splat tick tick hash ^@`$$- Caret at back-tick dollar dollar dash, !*'$_ Bang splat tick dollar under-score, %*<>#4 Percent splat waka waka number four, &)../ Ampersand right-paren dot dot slash, |{~~SYSTEM HALTED Vertical-bar curly-bracket tilde tilde CRASH.
Attachment:
pgpLQefd74Eve.pgp
Description: PGP signature
- References:
- Re: [Bcm43xx-dev] [Fwd: State of the Union: Wireless]
- From: Michael Buesch <[email protected]>
- Re: [Bcm43xx-dev] [Fwd: State of the Union: Wireless]
- Prev by Date: Re: [PATCH 2 of 3] memcpy32 for x86_64
- Next by Date: Re: [Bcm43xx-dev] [Fwd: State of the Union: Wireless]
- Previous by thread: Re: [Bcm43xx-dev] [Fwd: State of the Union: Wireless]
- Next by thread: Re: [Bcm43xx-dev] [Fwd: State of the Union: Wireless]
- Index(es):
 |