Re: [Madwifi-devel] ar5k and Atheros AR5005G
Hi all. > To make things easier for development I'd like to suggest a few madwif > ibranches created: > > * madwifi-1152-openhal: based on madwifi-1152, patched with my patch, > added openhal, old hal removed. Working free solution. Should exist > just as a reference and to allow users to checkout a working free > alternative in the mean time. > > * madwifi-dadwifi-openal: based on the latest dadwifi with the > openhal, old hal removed. As dadwifi gets updated you can pull updates > to this branch. As the openhal advances you can make updates to the > openhal here. I've set up the suggested branches, with slight changing to the proposed names: * http://svn.madwifi.org/branches/madwifi-old-openhal (based on r1142) * http://svn.madwifi.org/branches/dadwifi-openhal (based on r1827) Neither of them has received any modifications yet, they are basically copies of the mentioned revisions. I'm currently lacking the time to import Nick's work into the madwifi-old-openhal branch, for example - it would be nice if someone else could work on that. The MadWifi project happily provides any interested party access to the resources we have at hands - including (but not limited to) r/w access to the repository, an account for our Trac (used to manage tickets for bugs, patches, ...), e-mail, Let me know if you need something in that regard and I'll try to get it done. We'd love to support these efforts where possible. Bye, Mike - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Madwifi-devel] ar5k and Atheros AR5005G
Hi. Michael Buesch wrote: IIRC Pavel already explained that getting rid of the HAL per se should be no problem - it could easily be dissolved into the driver, if that is one of the requirements to be fulfilled before the driver (MadWifi or DadWifi) is considered for mainline inclusion. As soon as there is source available to dissolve, at least. Ok, so who actually does the work? The MadWifi team? It won't happen today or tomorrow, but I'm confident that it will happen. Any contribution to that effort is highly welcome - the more people help, the faster will the goal be reached. From what I understood the "... once the hal issue is resolved" part of David's mail refered to exactly that question. Ok, I don't know what "The HAL Issue" (tm) is. You referred to the archives where that exact "issue"(s) (binary-only, non-free, no sources, unwanted level of abstraction) has/have been discussed in lenght, but you claim you didn't have a clue what David was talking about? Come on. Bye, Mike - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Madwifi-devel] ar5k and Atheros AR5005G
Hi. > On Wednesday 29 November 2006 16:24, David Kimdon wrote: >> There is absolutely no reason why dadwifi can't be merged into the >> mainline once the hal issue is resolved. > Last time we talked about that stuff, it was decided that > we don't want a HAL... See archives. IIRC Pavel already explained that getting rid of the HAL per se should be no problem - it could easily be dissolved into the driver, if that is one of the requirements to be fulfilled before the driver (MadWifi or DadWifi) is considered for mainline inclusion. As soon as there is source available to dissolve, at least. >From what I understood the "... once the hal issue is resolved" part of David's mail refered to exactly that question. Bye, Mike - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Madwifi-devel] ANNOUNCE: SFLC helps developers assess ar5k (enabling free Atheros HAL)
Hi. > At least, this way we have a chance to get USB working as well (See > http://madwifi.org/ticket/33). It's not the HAL that prevents MadWifi implementing USB support. Replacing the binary-only HAL with OpenHAL and/or dissolving the HAL functionality in the driver source does not get us any closer to a working support of USB sticks. Quoting Sam Leffler on that topic: === cut === The Atheros-based USB devices work rather differently from the cardbus/pci cards. In particular there is no hal; instead there's an onboard processor that runs the hal and implements a special protocol. This means you can reuse some of madwifi but you also (probably) need to redo the code some to break out different interfaces. It's not a simple project. === cut === see: http://article.gmane.org/gmane.linux.drivers.madwifi.user/5380 > OpenBSD seems to have a working driver (if_uath.c) for these USB WLAN > sticks. Which, at least for some sticks, requires a not freely distributable binary firmware blob, by the way (see: http://archives.neohapsis.com/archives/openbsd/cvs/2006-09/0233.html ). Nevertheless, it would be nice to have that driver ported to Linux. Bye, Mike - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Madwifi-devel] ANNOUNCE: SFLC helps developers assess ar5k (enabling free Atheros HAL)
Hi. > Just in case you want to experiment, i have a working port of ar5k > that works on madwifi-old before the BSD - HEAD merge... Just to mention it: madwifi-old is no longer officially supported, and is a bad ground to start working on IMO (at least for anything that goes beyond a quick test). Interested parties should start from trunk instead (which is at r1809 as of now, by the way), or, even better, from the DadWifi branch. However, it will require some work to get the OpenHAL working in either of them. I suggest that related questions and discussions should be directed to the madwifi-devel list, since they might be of little interest (yet) on netdev or lkml. The MadWifi project is happy to provide resources (such as r/w access to our Subversion repository) to support these efforts, by the way. Please contact me offlist for details. Bye, Mike - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Madwifi-devel] ANNOUNCE: SFLC helps developers assess ar5k (enabling free Atheros HAL)
Hi. Michael Buesch wrote: Well, it never worked for me. But I gave up trying about half a year ago. But maybe it's just stupid me. ;) Well, we have various support channels (an IRC channel besides two mailing lists, for example) that you are welcome to make use of in case of problems :) Bye, Mike - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Broadcom 43xx first results
Hi. On Mon, 2005-12-05 at 13:46 -0500, Jeff Garzik wrote: > > Although I'm a bit biased towards MadWifi, I'd second your suggestion to > > make use of the Devicescape code. The benefit of having a fully-blown > > 802.11 stack in the kernel that drivers can make use of has been > > discussed before, so I won't go into that yet again. > Use the stack that's already in the kernel. Sorry, that was my bad. I thought that the Devicescape code found its way to the kernel (didn't follow the discussion some months ago too closely). Although I think there probably are better alternatives to the 802.11 stack that is in the kernel right now, having a central 802.11 stack at all is a great improvement that should be used where possible. > Encouraging otherwise hinders continued wireless progress under Linux. That depends. If the encouraging is about an alternative, more complete and superior 802.11 stack for Linux which could be integrated with less effort than extending the existing code, that should be worth to talk about. Please note that I'm not refering here to any of the related suggestions which have been made during the past months - it's a general statement. Bye, Mike - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Broadcom 43xx first results
Hi. On Mon, 2005-12-05 at 19:00 +0100, Jiri Benc wrote: > Why yet another attempt to write 802.11 stack? Sure, the one currently > in the kernel is unusable and everybody knows about it. But why not to > improve code opensourced by Devicescape some time ago instead of > inventing the wheel again and again? Or, in case there is some unknown objection to the mentioned code: use the 802.11 stack that comes along with MadWifi, which provides things like virtual interfaces (for multiple SSID support on one physical card) and WPA support. Although I'm a bit biased towards MadWifi, I'd second your suggestion to make use of the Devicescape code. The benefit of having a fully-blown 802.11 stack in the kernel that drivers can make use of has been discussed before, so I won't go into that yet again. Bye, Mike - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Question on manual bridging.
Hi. On Tue, 2005-11-22 at 15:26 -0800, Ben Greear wrote: > Connected to eth0 is a PC with MAC address AA, which is exactly the > same MAC address as ms1 has (this is to work around the fact that > a wifi interface can't really go into promisc mode or send frames with > a different source MAC address.) > > Is there a way to make ebtables (or something else) bridge all packets > from ms1 to eth0 (un-changed), and have all packets from eth0 with > source-MAC of AA be sent out ms1? I once made this working with the bridging code. Unfortunately I can't find the mail that described the necessary changes (I asked about a similar setup on the bridging ml several years back). It was something like "change the bridge in a way that it doesn't drop packets with out MAC address from forwarding it to the enslaved devices. Just a few lines had to be changed, and it worked great with Lucent WaveLAN cards out of the box. If such an setup would be ok for you, I'd try to find the print-out of the mail in question. I'm sure that I have it somewhere here. Bye, Mike - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: atheros driver - desc
Hi. Mateusz Berezecki wrote: > Im sending a series of 8 patches splitted and diffed as in > SubmittingPatches documentation. Patch 4/8 is missing here. Bye, Mike -- Use PGP/GPG! My key: http://keys.indymedia.org/cgi-bin/lookup?op=get&search=62C29B94 Fingerprint: BC2E 79BF 0C8F 0282 864B 9CEC 8343 5169 62C2 9B94 - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
