Wifi Ideas Page

Suggested Summer of Code project idea

Technical Contact: adrian@, sam@

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.

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

Suggested Summer of Code project idea

Technical Contact: adrian@, freebsd-wireless@freebsd.org

Extend the net80211 rate control API to be 802.11n aware. This includes:

• 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.

The ideal student will have a supported 802.11n chipset (Intel, Broadcom, 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.

Suggested Summer of Code project idea

Technical Contact: adrian@, sam@

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.

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

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).

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

No wireless hardware is required for this project.

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.

• 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.)