[lkml]   [2006]   [Jan]   [6]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: State of the Union: Wireless
    > 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.


    Mike Kershaw/Dragorn <>
    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.

    [unhandled content-type:application/pgp-signature]
     \ /
      Last update: 2006-01-06 17:06    [W:0.028 / U:7.388 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site