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.
Short preamble handling
We don't correctly adjust the preamble in the device-generated RTS/CTS frames. We should use the new mac80211 notification system to keep the RTS_CTS register up to date. Patch written, will send to Ulrich soon.
We also need a way of disabling the TX queue outside of the TX handler to complete this properly. This mac80211 functionality 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.
[http://dsd.object4.net/git/?p=zd1211.git;a=commitdiff;h=2c1784a975f39b49037358b061d4f94ed9ffcac2 Detailed error statistics]
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 zd1211) 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 works 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
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 [http://www.nabble.com/PROBLEMS-with-monitor-mode-zd1211rw-mac80211-driver-on-a-zd121-HLP-system-froze-p11411347.html causes an oops.in zd_mac_config_interface]
mac80211 patch submitted, awaiting review/merge.
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.
- Regulatory domain control
- Signal level reporting
- Connectivity loss issues
- monitor mode not showing all frames