IdeasPage [FreeBSD WIKI]

This page is read only. You can view the source, but not change it. Ask your administrator if you think this is wrong.
===== Wifi Ideas Page =====

===== WPA2 preauthentication in hostapd =====

//Suggested Summer of Code project idea//

**Technical Contact**: [[/AdrianChadd|adrian@]]

WPA2 is the authentication protocol defined as part of the IEEE 802.11i specification. This protocol is now commonly used to authenticate wireless stations to access points. Part of this protocol is the ability to pre-authenticate a station with one or more access points so that roaming can happen quickly. %%FreeBSD%% lacks support for this aspect of the protocol in the hostapd program used to construct a WPA-enabled access point. This task would port the Linux code that exists to support pre-authentication in hostapd. This mostly involves rewriting some user-mode multicast code and testing the result. (Whatever we do here should be upstreamed to w1.fi.)

==== Requirements ====

  * Good knowledge of C.
  * Wireless networking fundamentals.
  * WPA-capable wireless network setup.

===== net80211 rate control =====

**Technical Contact**: [[/AdrianChadd|adrian@]], <freebsd-wireless@freebsd.org>

Update the net80211 rate control API and test with newer hardware.

15:18:28 < adrian> the rate control API is done; that shoud be changed to "update it and test it on modern hardware"
15:18:36 < adrian> it's in a gsoc branch, I never had the time to integrate it
15:18:38 < adrian> i really should at some point though

  * Teaching it about multiple TX rate attempts (eg what ath(4) hardware supports;
  * Teaching about MCS rates;
  * Taking aggregate frame sizes into account (to select suitable rates for A-MPDU);
  * Make decisions about frame protection - ie, correctly set RTS or CTS-to-self for 11g and 11n interoperability with legacy networks;
  * Be SMPS aware - ie, if the peer is doing SMPS, restrict the MCS rate correctly to 0-7 (static SMPS) or prefix all frames with RTS (dynamic SMPS);
  * Do HT/20 and HT/40 selection;
  * Do STBC selection;
  * Select short or long guard interval.

==== Requirements ====

The ideal student will have a supported 802.11n chipset (Intel, Atheros) and be familiar with basic wireless concepts and C programming. If in doubt, please email <freebsd-wireless@freebsd.org> to ensure your 802.11n NIC is supported in %%FreeBSD%%-HEAD.

===== 802.11 Fuzzing and Testing (GSoC) =====
//Suggested Summer of Code project idea//

**Technical Contact**: [[/AdrianChadd|adrian@]]

Build a "packet fuzzer" tool that can be used to build test suites to improve reliability of the 802.11 code against garbage data. There are various tools out but we're not aware of any good ones that work with 802.11 and are generally available. The basic idea is to write a packet injector/playback tool that's driven by a scripting language. Then you need to build up a database of test cases. It's also possibly important to do time-based playback.

==== Requirements ====

  * Good knowledge of C.
  * Wireless networking fundamentals.
  * WPA-capable wireless network setup.

===== Extend wtap simulator to support station, adhoc, hostap modes =====
//Suggested %%SoC%% project idea//

**Technical Contact**: <freebsd-wireless@freebsd.org>

The wtap interface simulates enough of a wireless interface to allow for mesh (802.11s) testing. It would be nice to extend this to support the other operational modes (sta, hostap, adhoc).

==== Requirements ====

  * Good knowledge of C;
  * Basic understanding of drivers;
  * Basic understanding of wireless functionality.

No wireless hardware is required for this project.

===== Extend/cleanup the net80211 regulatory database =====

**Technical Contact**: <freebsd-wireless@freebsd.org>

The net80211 code does contain a basic regulatory database but it could do with an overhaul. Specifically:

  * It currently stores things per SKU and the SKU list is hard-coded in net80211. This should be undone so the regulatory "country" entries can be arbitrary;
  * Allow for multiple entries to map to a given country - for example, there will be multiple entries for Japan, one for each of the previous regulatory definitions of Japan;
  * Make the _driver_ map the SKU code to a country code entry - for example, there are a number of Japan SKUs in the ath(4)/ath_hal(4) driver, and the driver should map those SKUs to the relevant net80211 entry;
  * Add in entries for DFS requirements - which DFS domain they are in, what the CAC/NOL times are, etc. For ETSI, this includes marking some of the weather radar channels as having much longer CAC/NOL times.

==== Requirements ====

  * Good knowledge of C;
  * Basic understanding of wireless functionality;
  * Basic grounding (and/or willingness to learn) about regulatory domain related issues.

This will require net80211 and driver work - the drivers will need to be decoupled from the assumptions that the "SKU" fields have any meaning. ath(4) in particular maps the SKU fields to what the internal EEPROM values are (which is where the SKU field in net80211 originated from.)

===== Implement a new VAP type that is specifically for raw frame injection/reception =====

**Technical Contact**: <freebsd-wireless@freebsd.org>

None of the current operating modes are really designed for raw frame injection with no actual MLME functionality.  Some people (eg people implementing custom mesh/adhoc operational modes) are finding this very inconvenient.

Instead of trying to change adhoc/ahdemo/monitor to work this way, it may make more sense to simply implement a new VAP operating mode that can be used to implement this.

==== Requirements ====

  * Good knowledge of C;
  * Good knowledge of wireless and net80211;
  * Not being afraid of trying to make a new VAP operating mode and finding all the strange issues therein.

===== Implement per-channel activity/survey support in ath(4) and net80211 =====

**Technical Contact**: <freebsd-wireless@freebsd.org>

The ath(4) hardware has some live counters which track the channel status - how much time is spent TX'ing, RX'ing, and how much time it believes the channel air is busy. The HAL exposes these as counters and it would be nice to track this per-channel and expose it to net80211.

Then other modules in net80211 (eg automatic channel selection) can use this to determine the least used channel.

==== Requirements ====

  * Good knowledge of C;
  * Own a supported ath(4) NIC - anything AR5212 and later (including 802.11n) NICs which are supported will be enough for this task;
  * Not afraid to learn about how the Atheros wireless NICs work;
  * Not being afraid of doing some device driver and net80211 hacking.

===== Implement RX power histogram in net80211 =====

**Technical Contact**: <freebsd-wireless@freebsd.org>

Most drivers expose the per-frame RSSI as part of the RX process. This can be used by net80211 to build up a histogram of RX power levels. This forms part of the 802.11h DFS specification and is used in both the channel activity measurement and during automatic channel selection.

==== Requirements ====

  * Good knowledge of C;
  * Own a supported wireless NIC in %%FreeBSD%% which returns the per-frame RSSI;
  * Not be afraid to learn more about 802.11h and the net80211 stack.

===== Implement statistics graphing / visualisation =====

**Technical Contact**: <freebsd-wireless@freebsd.org>

Both the wireless stack and individual drivers provide a very large amount of useful statistics information, however right now this is exposed only via some basic test utilities.

This project aims to provide a generic way to log, visualise and explore the wireless statistics from a variety of locations.

The general architecture is thus:

  * A userland daemon which will take statistics from a variety of sources (driver, stack, kernel APIs) and both log them to a file as well as expose them as a JSON or similar encoded stream;
  * A web service that allows both a live playback of JSON data as well as browsing historical information which has been saved to a file;
  * A HTML5/Javascript (browser portable, as much as possible!) implementation of a generic data visualisation frontend, that can take both live and historical data and expose it in a flexible, useful way.

==== Requirements ====

  * Good knowledge of javascript/HTML5;
  * Own a supported wireless NIC in %%FreeBSD%% - preferably an Atheros PCI/PCIe NIC, but anything supported will be good to begin with;
  * Not be afraid by data representation and graphing.