|Release candidate(s):||r2174 - test results|
r2180 - test results
r2182 - test results
r2187 - test results
- switch to newer HAL, v0.9.18.0
- ensure compilation against recent kernel versions up to 2.6.20
- ensure compatibility back to kernel 2.4.22, drop support for 2.4.21 and older
- allow compilation without support of features such as fast frames, turbo mode, etc.
- support for some PCI Express cards fixed
- some security-related issues have been patched
- interoperation with wpa_supplicant and hostapd improved
- real channel noise instead of fixed -95dBm noise floor presented
- lots of bugs fixed, for different architectures and various modes of operation
- further improvements for build system
More detailed information in the revision log
- kernel panic from sample code
- Does "wlan_scan_monitor" module exist?
- Only old madwifi-driver package will connect to AirPort router
- Large Scan Results Patch.
- New IOCTL interface to allow application to pass IE to be sent in Management frames
- sent packet is not captured by monitor interface in the ng driver
- empty rate and mactime fileds in outgoing packets in monitor mode
- kernel oops under xscale BE 2.4.x rev > madwifi-ng-r-1451
- madwifi-ng not associating with some access-points
- svnr1644: get an oops configuring ath0 with wpasuplicant on ppc
- HAL status 13 on 168c/001c device
- Compile Breakage On 2.6.18-rc1-mm1
- [patch] care about update flag in iwspy data
- 5006EG (Atheros 2423) not supported
- 0.9.2 fails to compile on RHEL3 kernels
- Compile error
- Fails to build on Fedora Rawhide (and 2.6.18rc4) kernels
- [patch] Using a raw socket in 802.11 Radiotap mode to transmit does not work correctly
- Hardware Support: AR5006EG (PCI Express)
- [PATCH] Add absolute signal and noise to radiotap header on rx
- Cannot control rate
- [patch] Prism header - frame length
- malicious ad-hoc auth frame crashes the system
- Get measured noise data from the HAL instead of assuming -95dBm.
- Remove pad bytes from transmit feedback packets
- Various monitor mode fixes
- Correctly set pkttype field in monitor mode frames
- Allow monitor mode vaps to process error frames
- [regression] WPA TKIP broken with HAL 0.9.18.0
- Total hang on loading ath_pci (0.9.2) on mips-be platform
- WPA/RSN key length ioctl setting
- ieee80211_ioctl_create_vap does use copy_to_user for interface name
- wlanconfig prints wrong structure member for new interface name
- madwifi wont compile for linux-2.9.19-rc1-git2,3,4,5,6,7
- [patch] Channel Switch Announcement remote abuse fix / reliability improvement
- [patch] monitor mode sequence number of packets originating from the card are wrong
- [patch] multi-vap state machine bugfix
- [patch] unencrypted data packets are sent before WPA authentication succeeds
- IEEE80211_MLME_DISASSOC & IEEE80211_MLME_DEAUTH drops nodes on all vaps causing crash
- [patch] enable softled on HP laptops
- AR5212 802.11abg - WEP not working - OPEN works
- Send iwevent with node stats upon disassociation
- [patch] wrong parameter passing in IEEE80211_IOCTL_GET_APPIEBUF (r1822)
- TX timestamp (TSF) jumping in monitor mode
- [patch] User control of the short/long preamble via iwpriv ioctl
- FastFrames statistics are not incremented correctly
- Staggered beacons do not work in IBSS ad-hoc mode
- Support for Giga-byte GN-WI01GT?
- [patch] monitor mode: packet type to PACKET_OUGOING for all outgoing packets.
- simplify ieee80211_node->ni_rxfrag
- multiple VAP's: mastermode, stationmode - master VAP stops working when bringing up station mode VAP
- panic introduced by r2056
- 'make' broken with 2.6.20 kernel source
- if CONFIG_KMOD disabled in kernel, driver fails to load with various problems
- madwifi-driver subversion 2182 does not compile
- Various mode changing and scanning related annoyances (#572, #228, #275, #254, #352, #378)
- Suspend state not working properly (#201)
- Countrycode regression in recent HAL versions (#120)
- Stability problems when more than one VAP is in active use (#182, many other tickets)
- MAC address changing currently unsupported (#323) / not working correctly (#716)
- Documentation about private ioctl's and other features not 100% complete (#324, #486, #527, #399)
- No support for AR5008 chipsets available yet (#1001)
It's been a while since our last release... 227 commits have been done and 53 tickets were closed since v0.9.2.
Bad news first: although this release comes with a new HAL version, it does not support AR5008 (802.11n aka "XSpan") chipsets, and as it currently stands this won't change in the next release either. I'm sorry we have to disappoint all the MacBook (and also non-Mac 802.11n) users out there. The background of this issue is explained further in ticket #1001.
The new HAL, v0.9.18.0, fixes support for some of the AR5006 PCI Express chipset variants and provides some performance and resource optimizations. We are aware that this is not the latest HAL release available at this time; however, the latest HAL version requires some adjustments in the driver code, which would have delayed this release even more. The most current HAL will be made available in the next release along with a bunch of other improvements and changes.
MadWifi now compiles against the latest 2.6 kernel versions (up to 2.6.20), and it does not break anymore when you decide to turn off support for some of the advanced features, such as Fast Framing or Turbo Mode.
One of the more frequently mentioned wishes - the ability to see the current channel noise rather than the fixed "noise floor" value - is now fulfilled.
And more... the above mentioned changes are just an excerpt, the complete list is available at .
The next release most probably won't take that much time. Besides the already mentioned HAL upgrade (to v0.9.30.7 as of now) it will contain the results of work that takes place in the refcount branch, which fixes node locking issues to increase stability. Most of the outstanding submitted patches will be committed to trunk during the next days and weeks, and we hopefully can address some long-standing issues.
Apart from changes to the code it is planned to improve the documentation. For example the users guide should be moved to the wiki, which allows for easier updates, extensions and corrections. Making the compatibility easier to use is another task on our list. And last but not least I hope that I can spend some time on some ideas regarding automated build and functionality tests...
At this point I'd like to invite you to join the team. There are lots of ideas around for improving the MadWifi experience, but we lack manpower to make them real. You don't need to be an experienced programmer to help us! If you're interested, feel free to contact us at firstname.lastname@example.org.
We hope you enjoy the new version. As always, your feedback is highly welcome.
-- The MadWifi team