Kyle Hamilton (aerowolf) wrote,
I've been thinking. (Run screaming, lock the doors, put pillows over your head, and do your best to blot out my words.)

Brad Templeton recently mentioned something about "what if we make 802.11* beacons contain more than just SSID data?" Following up with that, I'm thinking along these lines:

1) 802.11* beacons are in a fixed format.
2) 802.11* access points could fairly easily be configured to send out additional beacon-like packets -- unencrypted bits of XML that give information about how to connect, what shop you're in, maybe a URL to a map of the store, associated things.
3) In Windows, 802.11* devices don't have the ability to listen for those additional packets without associating to the network that they're sent on. That would require RFMON mode, and there is no driver that supports RFMON in Windows.
4) Brad's talking about assigning everyone an IP address, or something associated, within the 10.x.x.x range. My question is, why?
- we know the BSSID of the AP we're talking to (that's essentially the MAC address of the access point)
- we know the MAC address of our card
- why should we impose the overhead of TCP/IP or even UDP/IP on an interaction that could, as he points out, be only 5 seconds long?
5) Why not send packets to the broadcast Ethernet address (ff:ff:ff:ff:ff:ff) every second or two, with information about what's offered? We have 1500 bytes to work with (minus the header and trailer) -- that would certainly be enough to transmit a DHCPOFFER with a set of "vendor-specific information" fields that instead contain text strings, including a URL to download the XML file, and a generic overview of who owns the AP and what you're being offered. [If such URL is desired, send a DHCPACK for the address offered, query the URL, get whatever information is thus published, and then DHCPRELEASE -- with the DHCPOFFER expiring after 30 seconds or so, so the address isn't eaten forever.] All of this can be done at the MAC level, before it even hits the IP layer.

As he rightly points out, Rendezvous only takes a couple steps out of the equation. My question is, why should we be so lazy as to try to force old paradigms to fit into new schemes where they don't fit? All it takes is something lower-layer to provide the information in the first place, and then we don't have to worry about the upper layers until they're actively needed.
  • Post a new comment

    Error

    Anonymous comments are disabled in this journal

    default userpic

    Your reply will be screened

    Your IP address will be recorded 

  • 2 comments