NOTE: this page is for archival only, see the note at the end of the page.

mac80211 issues

This page lists the issues blocking zd1211rw moving to the mac80211 stack. Some of these may already be resolved, they just need to be checked.

Advanced ERP handling

Daniel recently extended softmac and zd1211rw to parse ERP fields in beacons and probe responses (short preamble and 802.11g protection fields), and to finely control the transmissions and reprogram the RTS CTS register appropriately. This needs implementing in zd1211rw-mac80211. This may require further stack development.

mac80211 patches for ERP handling merged. Now we need driver-level handling, which requires mac80211 to have proper support to disable a TX queue outside of a TX handler (this has been under discussion recently).

Basic rates handling

In the softmac driver, we program the basic rates for RTS/CTS based on the association info. Need a similar system in mac80211.

Detailed error statistics

Ulrich has greatly improved the zd1211rw 802.11 error statistics. This code needs moving over to the mac80211 driver after figuring out how mac80211 does this.


Benoit reported that multicasting is not working with zd1211rw-mac80211, making IPv6 unusable. This is probably a stack-level problem, as the zd1211rw code for handling multicasting is identical in both drivers.

16:15 < benoit> dsd_: i have tested zd1211rw-mac80211 with ipv6
16:15 < benoit> first, i disable SMP in order to boot (bug not related to 
16:16 < benoit> i manage to get ipv6 working
16:16 < benoit> ie, it does not work at first, i have to reconnect until it 
16:18 < benoit> when it does not work, tcpdump (on the laptop) shows that not 
                "router sollicitation" is sent
16:19 < benoit> so, no ipv6 addr/router .... pretty logical
16:28 < benoit> so, it's mostly unreliable

Testing on ARM and SPARC64

We have happy ARM and SPARC64 users. To my knowledge, mac80211 has not been tested there.

MAC address issues

Johannes writes:

In zd1211, we start with hwaddr = dev->wiphy->perm_addr which isn't
correct either, for a pure monitor mode we want to start with a zero mac
addr to avoid acking packets. Also, zd1211rw will end up having a NULL
hwaddr when a monitor interface is added, most likely segfaulting in
zd_write_mac_addr then.

monitor mode scanning oops

Scanning for networks after creating a zd1211rw monitor interface [ causes an zd_mac_config_interface]

mac80211 patch submitted, awaiting review/merge.

Non-blocking issues

These issues are specific to mac80211 (as opposed to being regressions over the softmac driver), so these are not holding up the merge.

multiple interfaces broken

Discussed on the "Arrested Development" thread:

I forgot to mention that the monitor support doesn't work with
additonal interfaces right now. Additional interfaces are broken
currently for zd1211rw.

Fixed issues

  • Regulatory domain control
  • Signal level reporting
  • Connectivity loss issues
  • monitor mode not showing all frames

This is a static dump of the old wiki, taken after locking it in January 2015. The new wiki is at
versions of this page: last, v21, v20, v19, v18, v17, v16, v15, v14, v13, v12, v11, v10, v9, v8, v7, v6, v5, v4, v3, v2, v1