• WiFi
• IdeasPage

wiki-admin comment: this page is being checked for staleness as of 20240829

Wifi Ideas Page

Various ideas for improvement of FreeBSD's wireless functionality.

WPA2 preauthentication in hostapd

Suggested Google Summer of Code project idea

Technical Contact: <freebsd-wireless AT freebsd DOT org>

(Suggested by: AdrianChadd)

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: <freebsd-wireless AT freebsd DOT org>

(Suggested by: AdrianChadd)

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

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 AT freebsd DOT org> to ensure your 802.11n NIC is supported in FreeBSD-HEAD.

802.11 Fuzzing and Testing

Suggested Google Summer of Code project idea

Technical Contact: <freebsd-wireless AT freebsd DOT org>

(Suggested by: AdrianChadd)

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 Google Summer Of Code project idea

Technical Contact: <freebsd-wireless AT freebsd DOT 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 AT freebsd DOT 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 AT freebsd DOT 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 AT freebsd DOT 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 AT freebsd DOT 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 AT freebsd DOT 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.

CategoryProject CategoryTodo CategoryGsoc