login
Search
Hi all. We, the MadWifi team, announce our decision to move away from the binary-only HAL and change the focus of our future development towards ath5k [1], a completely free (as in freedom) driver which will eventually become an integral part of the Linux kernel. We encourage all interested developers to join us and contribute to our efforts. For those who are not familiar with the concept, the proprietary "Hardware Abstraction Layer" (HAL) [2] was designed as compromise to allow at least one Free and Open Source Software (FOSS) wireless driver component. Unlike many other wireless devices Atheros chipsets can use a wide range of frequencies and the host software can control many aspects of the radio. Regulatory agencies all over the world have laws which restrict the use of the wireless spectrum to certain frequency bands under specific transmission power levels. These laws drive wireless manufacturers to come up with solutions to enforce compliance with the wide array of regulatory agencies. The binary HAL is a wrapper around all chipset registers, and all direct hardware access is routed through it. This approach ensures that non-compliant settings are not applied to the radio, while allowing the open source part of the driver to interact with the chipset in a permissive manner. We understand Atheros' reasons for introducing the HAL and distributing it in binary form only, and we supported it. But this decision forced us to deal with a black box that we could neither fix nor fully understand - a major issue for a free software project. This prevented MadWifi from appearing in many Linux distributions. Because of the proprietary HAL and since the MadWifi driver also did not make use of the new mac80211 layer in Linux it has been impossible for it to become part of the Linux kernel. It's also been clear to us that the "security through obscurity" approach won't work to protect the hardware against unlawful use. Regardless, we kept working on MadWifi as no acceptable ...
This is a multi-part message in MIME format. ------_=_NextPart_001_01CA8FFF.97FC997F Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Madwifi currently doesn't support Bullet M5 which I believe has AR9160 chipset. Is there a plan to ever support it ?? Is there something I can do to help in getting that supported in madwifi. Although it is a/g/n chip I intend to use it only for g mode so madwifi should still be fine as long as it can attach to the chipset. =20 Thanks, Jaideep =20 ------_=_NextPart_001_01CA8FFF.97FC997F Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN"> <HTML><HEAD> <META http-equiv=3DContent-Type content=3D"text/html; = charset=3Dus-ascii"> <META content=3D"MSHTML 6.00.2900.3636" name=3DGENERATOR></HEAD> <BODY> <DIV><SPAN class=3D868120901-08012010>Madwifi currently doesn't support = Bullet M5=20 which I believe has AR9160 chipset. Is there a plan to ever support it = ?? Is=20 there something I can do to help in getting that supported in madwifi. = Although=20 it is a/g/n chip I intend to use it only for g mode so madwifi should = still be=20 fine as long as it can attach to the chipset.</SPAN></DIV> <DIV><SPAN class=3D868120901-08012010></SPAN>&nbsp;</DIV> <DIV><SPAN class=3D868120901-08012010>Thanks,</SPAN></DIV> <DIV><SPAN class=3D868120901-08012010>Jaideep</SPAN></DIV> <DIV><SPAN class=3D868120901-08012010></SPAN>&nbsp;</DIV></BODY></HTML> ------_=_NextPart_001_01CA8FFF.97FC997F--
The purpose of this message is just to create the madwifi-devel newsgroup over at gmane.org. It can be safely ignored. :) Bye, Mike ------------------------------------------------------- This SF.Net email is sponsored by: Oracle 10g Get certified on the hottest thing ever to hit the market... Oracle 10g. Take an Oracle 10g class now, and we'll give you the exam FREE. http://ads.osdn.com/?ad_id=3149&alloc_id=8166&op=click
Congratulations ! I also thought about going to bcm43xx based WLAN cards, as they are now working much better than two months ago ... and, from a what-happens-in-linux-kernel-perspective, it seamed much more lively and healthy. For example, several people tried to get better roaming support into madwifi. That's basically a job for net80211, not for the atheros chipset. But the madwifi project lacked people with enought time and knowledge in the net80211 area, so no peer review did happen and, of course, the code in the madwifi svn didn't get changed, so madwifi still doesn't roam more smoothly. So, by moving to ath5k, which is using mac80211, there is no need to have people that know and can maintain BSD's net80211 inside Linux. We get the best from both worlds: some very knowledgeable people in the mac80211 area, and some very knowledgeable persons in the atheros driver area. I like that :-) ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
This sounds great! Moving to OpenHAL should benefit madwifi in many ways. There is only one thing I question: "Another important development is the work on a "central regulatory domain agent". It aims to ensure compliance with the regulatory constraints and rules based on the current location of the user. The agent and its integration with the kernel will allow wireless LAN drivers to enforce local regulations without requiring non-free software for that task. This work will soon be published for merging with the upstream kernel." In my opinion, protection should not be in the software for such things. While Atheros may be required by law to do this, madwifi (this is NOT legal advice in any way shape or form) is not required to do so. One comparison which can be made to this situation is that of VLC. Whereas commercial DVD playing apps look at region codes, VLC ignores them. VLC could choose to abide by these codes and put code in to stop the wrong region from playing, but the project chooses not to. Madwifi should do the same. Another comparison is the GPL kernel module debate. The kernel was made to prohibit access to certain symbols for programs which were not GPLd by checking the Module_License to see if it was equal to GPL. Linuxant got around this by setting the Module_License to "GPL\0for files in the \"GPL\" directory; for others, only LICENSE file applies." The null character made this effectively "GPL" so the kernel loaded the proprietary modules as if they were GPL. Now, Linus Torvalds got a bunch of patches to fix this. However, his response was this: "I'd prefer not to do that. Since they want to circumvent this, almost anything we want to do is a waste of time." He too offered a patch, adding to it the byline, "Arms race forces bloat upon module users" [1]. This is the philosophy that madwifi needs to abide by. Don't protect your code from hackers, or people wanting to abuse it. Developers should just focus on making the best Linux Atheros driver possible, ...
Hello! It's a separate effort from MadWifi, not limited to specific wireless The difference here is that wireless developers actually expect to work with the device vendors. The vendors may be more forthcoming if the free driver supports regulatory control (directly or through some other layers). Anyway, the regulatory control patches are discussed in linux-wireless@vger.kernel.org, not here. Please don't cross-post unless you are a member of the team and you are making an announcement. You are giving a bad example to others. -- Regards, Pavel Roskin ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ _______________________________________________ Madwifi-devel mailing list Madwifi-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/madwifi-devel
So it's going in the net80211 stack? Hrm... maybe I should post my Here's where I'm confused. Madwifi is going AWAY from Atheros' assistance(moving away from the HAL). Moreover, why should Atheros(or any other company for that matter) care if other people choose to transmit over other frequencies? (The following is not legal advice, do not use it as such) Atheros does not get blamed if other people use My apologies, ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ _______________________________________________ Madwifi-devel mailing list Madwifi-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/madwifi-devel
The relevant discussions can be found here: http://thread.gmane.org/gmane.linux.kernel.wireless.general/6049 Wrong. While we move away from the proprietary HAL, we don't move away from Atheros. As stated in the announcement we're in contact with Atheros I could be wrong here): Because of the FCC rules that seem to require device vendors (that's not Atheros, but Atheros customers such as D-Link, Netgear and others) to make sure that their products can't be "abused" to easily break the regulatory rules, otherwise these products won't get FCC certification and thus are not allowed to be sold in FCC-regulated countries. Other regulatory bodies have similar rules, afaik. Bye, Mike ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ _______________________________________________ Madwifi-devel mailing list Madwifi-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/madwifi-devel
Hi, The current open HAL looks similar to madwifi-old which I really liked but some of the features like background scanning are absent. I am interested to know how much of the code that was developed for the madwifi driver with the proprietary HAL will be reusable in the new OpenHAL version? Will the aim be to get the driver back to the same state or will there be large modifications with the added flexibility of an open source HAL. I hope this does not come across as critical because it is not intended to be. Cheers Dave ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ _______________________________________________ Madwifi-devel mailing list Madwifi-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/madwifi-devel
Any old legacy madwifi driver (which uses the proprietary HAL) relies on net80211, with the exception of dadwifi-openahal. dadwifi-openhal is now replaced though with ath5k [1]. ath5k uses the new Linux mac80211[1]. Since net80211 is 'complete wireless stack' and mac80211 is a 'Linux API used to write SoftMAC wireless drivers' the drivers as a whole differ significantly. As such only small portions of the driver were reusable, and those that were made it into New development is going to be focused on ath5k. Relying on the proprietary HAL has been like working with a black box and the legacy drivers also rely on Wireless-Extensions which will not longer have new features added, preventing us from extending the usage and features of the driver. To reap benefits of the latest Linux wireless developments we must focus on mac80211, cfg80211 [3] and nl80211 [4]. cfg80211 and nl80211 is still under development and we are yet to provide userspace utilities for them. However, mac80211 is now part of the stock kernel and as such we are working on stabilizing it. In the meantime I'd advise users to look in to wpa_supplicant [5] and hostapd [6]. You can also still use wireless-tools (iwconfig, iwlist, iwevent) with ath5k and any mac80211 driver. Luis [1] http://madwifi.org/wiki/About/ath5k [2] http://linuxwireless.org/en/developers/mac80211 [3] http://linuxwireless.org/en/developers/cfg80211 [4] http://linuxwireless.org/en/developers/nl80211 [5] http://hostap.epitest.fi/wpa_supplicant/ [6] http://hostap.epitest.fi/hostapd/ ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ _______________________________________________ Madwifi-devel mailing list Madwifi-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/madwifi-devel
AR9160 should be supported by the trunk. Please actually try it. -- Regards, Pavel Roskin ------------------------------------------------------------------------------ This SF.Net email is sponsored by the Verizon Developer Community Take advantage of Verizon's best-in-class app development support A streamlined, 14 day to market process makes app distribution fast and easy Join now and get one step closer to millions of Verizon customers http://p.sf.net/sfu/verizon-dev2dev _______________________________________________ Madwifi-devel mailing list Madwifi-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/madwifi-devel
My bad. Bullet M5 is based on AR928X chipset rather than AR9160. Here is
the lspci information from Bullet M5. I compiled and installed
madwifi-trunk r4099 on the board. This doesn't attach to chipset as
well.
root@OpenWrt:~# lspci
00:00.0 Network controller: Atheros Communications Inc. AR928X Wireless
Network Adapter (PCI-Express) (rev 01)
root@OpenWrt:~# lspci -v
00:00.0 Network controller: Atheros Communications Inc. AR928X Wireless
Network Adapter (PCI-Express) (rev 01)
Subsystem: Device 0777:e205
Flags: bus master, fast devsel, latency 0, IRQ 48
Memory at 10000000 (64-bit, non-prefetchable) [size=64K]
Capabilities: [40] Power Management version 2
Capabilities: [50] MSI: Enable- Count=1/1 Maskable- 64bit-
Capabilities: [60] Express Legacy Endpoint, MSI 00
Capabilities: [90] MSI-X: Enable- Count=1 Masked-
Capabilities: [100] Advanced Error Reporting
Capabilities: [140] Virtual Channel <?>
Capabilities: [160] Device Serial Number 00-00-00-00-00-00-00-00
root@OpenWrt:~# lspci -n
00:00.0 0280: 168c:002a (rev 01)
So now correct question would be are we planning to support AR9280 in
madwifi and how can I help. Or did I miss turning on some other flag in
madwifi which didn't allow madwifi to associate with this radio.
Thanks,
Jaideep
------------------------------------------------------------------------------
This SF.Net email is sponsored by the Verizon Developer Community
Take advantage of Verizon's best-in-class app development support
A streamlined, 14 day to market process makes app distribution fast and easy
Join now and get one step closer to millions of Verizon customers
http://p.sf.net/sfu/verizon-dev2dev
_______________________________________________
Madwifi-devel mailing list
Madwifi-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/madwifi-devel
Correct, its PCI ID is in not in the table of the supported devices FreeBSD HAL supports AR928X, so it should be possible, but it's would be quite a big effort. One approach would be to port MadWifi to the new channel API used by FreeBSD. That would be the best thing if we want to stay in sync with FreeBSD. But in terms of code changes, it's a major effort, and I don't see it happening, especially since we don't have many active developers and testers to deal with possible bugs. Changes will be needed throughout MadWifi. Another approach would be to backport FreeBSD HAL to the old channel API. That would be less labor intensive, and it would bring us all fixes from FreeBSD HAL. I think it could be done, at least partly, using an automated patching tool, such as cochinelle. Finally, we could backport only the files for AR928X support and their dependencies. That's would be the easiest in terms of changes, but it would still take several iterations before it compiles, and I'm not sure it would work right away. It tried it and gave up due to lack of time. You can get FreeBSD HAL by svn co http://svn.freebsd.org/base/head/sys/dev/ath -- Regards, Pavel Roskin ------------------------------------------------------------------------------ This SF.Net email is sponsored by the Verizon Developer Community Take advantage of Verizon's best-in-class app development support A streamlined, 14 day to market process makes app distribution fast and easy Join now and get one step closer to millions of Verizon customers http://p.sf.net/sfu/verizon-dev2dev _______________________________________________ Madwifi-devel mailing list Madwifi-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/madwifi-devel
The chipset is not AR9160, it's AR9223. Madwifi will not work on this device without modifications (calibration data is on system flash instead of a separate EEPROM chip). If you flash OpenWrt on this thing, it already comes with working wifi with 802.11n support (thanks to ath9k), so I don't think there's much point in trying to make it work with madwifi... - Felix ------------------------------------------------------------------------------ This SF.Net email is sponsored by the Verizon Developer Community Take advantage of Verizon's best-in-class app development support A streamlined, 14 day to market process makes app distribution fast and easy Join now and get one step closer to millions of Verizon customers http://p.sf.net/sfu/verizon-dev2dev _______________________________________________ Madwifi-devel mailing list Madwifi-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/madwifi-devel
