• SummerOfCode2017
• Porting80211nAnd80211acToFreeBSDiwm

Porting 802.11n (and hopefully 802.11ac) to FreeBSD iwm(4)

• Student: MateuszPiotrowski (0mp@)

• Mentor: AdrianChadd (adrian@)

Project description

The aim of the project is to add the lacking 802.11n and 802.11ac support for the FreeBSD iwm driver. The priority is the 802.11n standard as 802.11ac is based on it.

The driver parts will be ported from 3 source trees: DragonFly BSD and Linux and OpenBSD.

Plan

Research & learning about wireless device driver development

1. Linux iwlwifi:

1. Start by drawing out the iwlwifi driver code by hand.

2. Then look at the mac80211 code that creates the device and populates the mac80211 callbacks. Look for things like TX, RX, channel context, start and stop.

2. 802.11n:

• WiFi/BringUp is a good writeup explaining 11n bring-up.

Antenna configuration

1. Let's review iwlwifi/mvm TX and RX antenna configuration code

• What does it do for:
• Initial setup?
• MAC context setup?
• PHY context setup?
• TX packet setup?

  
  We need to get it to work otherwise MIMO rates won't work at all.
  
  MIMO rates are mainly based on two things:

• The abilities of the hardware.
• Whatever is negotiated with the other side of a connection.

  
  

  Where to start?
  Look for PLCP. Find the routine that calculates the PLCP value to stuff in the transmit descriptor and see what calls it and map that out a couple levels.

2. Then we have to investigate iwlwifi and iwn to see how they assemble the MIMO version of the transmit PLCP.

• Right now iwm only knows about 11abg PLCP configuration and rate configuration.

3. Let's add placeholders routines for 11n methods.

• iwm won't do any 11n rates until we tell net80211 that 11n can be used.

4. Make MAC and PHY contexts in firmware aware of the fact that they can now use 11n.

5. Tell net80211 that it can now use 11n and see if it crashes.

Notes

These are loose notes and knowledge I gather during my research and conversations with other developers.

Typically, when the 802.11n support is added to a device driver this is the order of implementing features:

• Antenna configuration
• Channel configuration
• RX path
• Make monitor mode work
• Then worry about TX
• Then worry about rate control

It's good to know that iwm is doing some really weird things with antenna configuration and channel setup, so it's worth looking at what iwlwifi/mvm/ is doing.

The RX path for iwlwifi/mvm/ shouldn't be that much different to what we've done in the FreeBSD RX path since the hardware is still giving us decap'ed frames but step #1 is always how is the NIC supposed to be configured to be in 11n mode and on an 11n channel way before you transmit 11n.

802.11ac doesn't run in 2.4 GHz.

Firstly - 11ac layers on top of 11n. There are some 11ac specific PHY level headers going on but MCS0..7 in 11n is MCS0..7 in 11ac. It's just MCS8 and MCS9 that are 11ac specific. Then, for 11n, you have multiple spatial streams. (MCS0..7 -> 1 stream, MCS8..15 -> 2 stream, MCS16..23 -> 3 stream, etc.) With 11ac, they have it as a 2d matrix. ((1, 2, 3.. n) stream ; (MCS0..9)) Then the third dimension is channel width - 20 and 40 are the same as 11abg, 11n. 80 and higher are 11ac so they really did build on top of 11n.

There are some new capabilities, some new ways to negotiate things that might not be done 100% correctly yet, but its getting there now the other bit is that almost all vendors have some kind of "11ac in 2GHz" vendor specific operation which AdrianChadd laid some groundwork for, but they are not going to be supported for the longest time.

You don't do 80MHz on 2GHz, For 40MHz however, there's a whole overlapping interop thing going on.

PLCP

802.11 protocols permit to negotiate transmission rates for every session. As well as that it is possible to change packet fragmentation in order to improve the throughput as the connection conditions change. This is where PLCP kicks in; it is a PHY layer which makes the features I listed possible.

Looking for PLCP uses in `mvm`

Firstly, I greped the mvm code for PLCP and tried to figure out how it works and when it is called.

The first function I focused on was iwl_mvm_mac80211_idx_to_hwrate.

It turned out that it is called from iwl_mvm_bss_info_changed. iwl_mvm_bss_info_changed behavior depends on whether on the mode it is operating in, which is either STA or AP/ADHOC.

When the mode is either AP or ADHOC then this is a list of function calls:

• iwl_mvm_bss_info_changed_ap_ibss

  • iwl_mvm_mac_ctxt_beacon_changed

    • iwl_mvm_mac_ctxt_send_beacon which sets the rate based on the used bandwidth (which could be either 2.4GHz or 5GHz) to what appears to be the minimal rate of the modulation scheme being in use (IWL_FIRST_OFDM_RATE and IWL_FIRST_CCK_RATE)

When the mode is STA then iwl_mvm_bss_info_changed_station is called, which doesn't seem to do anything anything about PLCP.

Another function where iwl_mvm_mac80211_idx_to_hwrate is called is iwl_mvm_get_tx_rate in iwlwifi/mvm/tx.c.

• iwl_mvm_set_tx_params

  • iwl_mvm_set_tx_cmd_rate

    • iwl_mvm_get_tx_rate

I still have to map out those function calls one or two levels higher as I do not understand the logic completely yet.

To-dos

I need to investigate iwl_hwrate_to_plcp_idx (iwlwifi/mvm/rs.c) as it looks like a function which calculates which rate should be applied.

Also, I don't know yet why and when those rates are changed.

PLCP in mvm/tx.c is still a mystery.

Milestones

Reports

Useful links

• Notes about Wi-Fi driver development: MateuszPiotrowski/Drivers