Atheros driver.
Hi. I'm trying to find a PCI wireless card and bought one of these: http://www.tp-link.com/en/products/details/?categoryid=246model=TL-WN350GD dmesg shows: vendor Atheros, unknown product 0x001d (class network subclass ethernet, rev 0x01) at pci1 dev 1 function 0 not configured Does this mean point blank this is an un-supported chipset or are there things to check, etcetera? Best wishes.
Re: Atheros driver.
On Sun, Sep 30, 2012 at 10:42:55PM +0930, David Walker wrote: Hi. I'm trying to find a PCI wireless card and bought one of these: http://www.tp-link.com/en/products/details/?categoryid=246model=TL-WN350GD dmesg shows: vendor Atheros, unknown product 0x001d (class network subclass ethernet, rev 0x01) at pci1 dev 1 function 0 not configured Does this mean point blank this is an un-supported chipset or are there things to check, etcetera? That means it is unclaimed by all drivers in the kernel. In this case it seems to be an AR2417, which would be covered by ath(4) if ath was updated to support it. So it is unsupported for now.
Re: Atheros driver.
It looks like you're probably out of luck, see http://madwifi-project.org/wiki/Compatibility/TP-Link TL-WN350GD is AR2417 / AR5007G, neither of which are listed either in athn(4) or ath(4), or the CVS commits if openbsd src is searched. I've got this if it helps : athn0 at pci0 dev 15 function 0 Atheros AR5416 rev 0x01: irq 3 athn0: MAC AR5416 rev 2, RF AR2133 (3T2R), ROM rev 5 Which relates to http://www.tp-link.com/en/products/details/?categoryid=240model=TL-WN951N http://www.wikidevi.com/wiki/TP-LINK_TL-WN951N_v1 Works fine with OpenBSD with Windows devices, but there's a problem establishing a connection with Android, cause unknown. On 30 September 2012 14:12, David Walker davidianwal...@gmail.com wrote: Hi. I'm trying to find a PCI wireless card and bought one of these: http://www.tp-link.com/en/products/details/?categoryid=246model=TL-WN350GD dmesg shows: vendor Atheros, unknown product 0x001d (class network subclass ethernet, rev 0x01) at pci1 dev 1 function 0 not configured Does this mean point blank this is an un-supported chipset or are there things to check, etcetera? Best wishes.
Re: Atheros driver.
On Sun, Sep 30, 2012 at 04:39:16PM +0100, Peter Kay wrote: I've got this if it helps : athn0 at pci0 dev 15 function 0 Atheros AR5416 rev 0x01: irq 3 athn0: MAC AR5416 rev 2, RF AR2133 (3T2R), ROM rev 5 Works fine with OpenBSD with Windows devices, but there's a problem establishing a connection with Android, cause unknown. Android might require power management support which was recently added to athn(4) in -current. So try -current on the AP, it might fix problems with the Android device.
Re: Atheros driver.
This is post the -current fix with athn(4) power saving. Without it Android devices don't really work at all, with it they work for a bit and then stop working claiming the access point isn't within range. It's a problem that's not specific to OpenBSD - some access points suffer the same issue, but I've not seen a definite solution so far. On 30 September 2012 17:38, Stefan Sperling s...@openbsd.org wrote: On Sun, Sep 30, 2012 at 04:39:16PM +0100, Peter Kay wrote: I've got this if it helps : athn0 at pci0 dev 15 function 0 Atheros AR5416 rev 0x01: irq 3 athn0: MAC AR5416 rev 2, RF AR2133 (3T2R), ROM rev 5 Works fine with OpenBSD with Windows devices, but there's a problem establishing a connection with Android, cause unknown. Android might require power management support which was recently added to athn(4) in -current. So try -current on the AP, it might fix problems with the Android device.
Further developments regarding the Atheros driver
Reyk and I have decided to show something from the private handling of this Atheros copyright violation issue. It has been like pulling teeth since (most) Linux wireless guys and the SFLC do not wish to admit fault. I think that the Linux wireless guys should really think hard about this problem, how they look, and the legal risks they place upon the future of their source code bodies. There are lessons to be learned here -- be cautious because there is no such thing this relicensing meme that your user community spreads. In their zeal to get the code under their own license, some of these Linux wireless developers have broken copryright law repeatedly. But to even get to the point where they broke copyright law, they had to bypass a whole series of ethical considerations too. I believe these people have received bogus advice from Eben Moglen regarding how copyright law actually works in a global setting. Perhaps the internationally based developers should rethink their approach of taking advice from a US-based lawyer who apparently knows nothing about the Berne Convention. Furthermore, those developers are getting advice freely from ex-FSF people who have formed an agency with an agenda. Some have suggested that the SFLC was formed to avoid smearing the FSF with dirt whenever the SFLC does something risky. Don't get trampled; there could be penalties besides looking unethical and guilty. Be really cautious, especially with things like this coming to mess with our communities: http://www.linux-watch.com/news/NS8560536106.html Below, you can find a mail was sent by me (in consultation with Reyk) on Sep 5 to various people in the Linux wireless developer community and their advisors in the SFLC. Inside that message, you can find another message from Sep 1 that they never replied to. On Sep 5 there was finally a reply from Eben Moglen, but it added nothing constructive to the process, except that Eben Moglen admitted that the Linux developer's had done an Adaptation; I will show one particular sub-sentence from Eben's reply mail: we wish to secure as much of the work done to adapt Reyk's code for use with the Linux kernel as the authors will permit, [...] I don't think Eben wanted to say that. In copyright law, the word adapt has a very clear meaning. From our perspective, we see the SFLC giving bad advice three times to (some subset of) the Linux wireless developers (who they call their clients, after apparently more than a year of consultation): The first advice given by the SFLC resulted in Luis, Jiri, and Nick simply replacing Reyk's ISC license with the GPL around large parts of Reyk's code in various repositories. (Let us not concern ourselves with Sam's code for now). That occurred roughly around August 25. Our developers have cloned those public/published repositories, though some of them have now been taken offline by the developers who operated them. The second advice given by the SFLC was that a GPL can be wrapped around another author's work. That advice was re-posted by John Linville on Sep 5 at http://lwn.net/Articles/248223/ but it unfortunately says nothing about _when_ an author of a derivative receives the right to do such a thing. The SFLC waives that concern away. But that is the clincher -- by law, a new person doing small changes to an original work is not allowed to assert copyright, and hence, gains none of the rights given by copyright law, and hence, cannot assert a license (copyright licenses surrender a subset of the author's rights which the law gives them; the licenses do not not assert rights out of thin air). You can see this 'relicensing approach' is still published in files in the repository at http://madwifi.org/browser/branches/ath5k, for instance see http://madwifi.org/browser/branches/ath5k/ath5k_phy.c. This repository has also been cloned by some of our developers to show proof of publishing. Then my mail (shown below) arrived at the SFLC. There has been one reply from Eben to that mail, as noted above. Naturally I am tempted to show more mails... It appears that the mail I sent had some effect; because it seems that the developers received new advice from SFLC -- a third approach. Linville did not even follow what he re-posted from the SFLC on the 5th, but took an even more conservative approach. The Linville repository replaced Jiri's repository (which Jiri disconnected), and all of Reyk's original work now appeared with only an ISC license as Reyk had it. In this case Nick and Jiri have been added as co-owners of the copyright, though. http://git.kernel.org/?p=linux/kernel/git/linville/wireless-dev.git;a=blob;f=drivers/n%20%5Cet/wireless/ath5k_hw.c;h=07ad1278b39037caf68825cabcf9469db059dfc8;hb=everything http://git.kernel.org/?p=linux/kernel/git/linville/wireless-dev.git;a=tree;f=drivers/n%20\et/wireless;h=2d6caeba0924c34b9539960b9ab568ab3d193fc8;hb=everything Those files are still invalidly being distributed
Re: More on the Atheros driver situation
* Theo de Raadt [EMAIL PROTECTED] [070901 10:45]: Well, it looks like the Linux wireless people have decided that their relatively small modifications to the Atheros driver will be GPL'd, and not given back to improve the driver in the *BSD world. If code is released under copyright. be it BSD, or GPL, and someone other than the author(s) changes the license, can the person(s) who(m) made the changes seriously expect that somebody else cannot take that code under the terms of the original license, or some other license _they_ prefer and do the same? If I sound confused, it's probably because I am. :-\ -- W. Steven Schneider [EMAIL PROTECTED]
Re: More on the Atheros driver situation
On 9/1/07, Steven [EMAIL PROTECTED] wrote: If code is released under copyright. be it BSD, or GPL, and someone other than the author(s) changes the license, can the person(s) who(m) made the changes seriously expect that somebody else cannot take that code under the terms of the original license, or some other license _they_ prefer and do the same? Someone other than the authors _cannot_ change the license. Neither of these licenses grants anyone rights to change or remove licenses of the distributed code. In fact, they explicitly state that the license (and copyright) must stay intact. (New material can have a new license clause appended to it, but that is completely different than what you're talking about.) This whole escapade would be a lot simpler if people would stop relying on guesswork and assumptions for matters they do not understand. For most matters like these in the real world, the preferred behavior is to clam up until you study and understand it, and then engage in commentary. Read Theo's earlier email on the matter. He explains it quite well. http://marc.info/?l=openbsd-miscm=118861134304239w=2 DS
Re: More on the Atheros driver situation
On Saturday 01 September 2007, Theo de Raadt wrote: Well, it looks like the Linux wireless people have decided that their relatively small modifications to the Atheros driver will be GPL'd, and not given back to improve the driver in the *BSD world. http://marc.info/?l=linux-wirelessm=118857712529898w=2 All the email addresses you need to mail to express your distaste at this are right in that mail, except for one, which is Eben Moglen [EMAIL PROTECTED]. I've done what I can for now; Good luck to the rest of you. No worries Theo. That's easy to fix. Just delete the GPL license and copyright statement from the source files and replace that GNU shit with a nice, clean the BSD license. In fact, while we're at it, let's make a BSD licensed fork of GCC. With a little regex magic, we could have the new BCC fork done by tomorrow. (for those idiots who understand neither sarcasm nor copyright law, please ignore this post) jcr
Re: Question about atheros driver??
On Fri, Sep 23, 2005 at 09:36:05PM +0200, Reyk Floeter wrote: Is atheros driver supported under Alpha platform on OpenBSD 3.7?? not yet no, but i would be really happy about a donated alpha to port ath(4) to this platform ;). thanks to another developer, i got a 433MHz digital alpha Miata personal workstation with enough PCI slots to test the ath driver... the unmodified driver already attaches, but it does not fully work yet. there seem to be a problem with ath interrupts in hostap mode (appeared with ar5210 PCI) and there are minor bugs in EEPROM access on alpha. now i have to find my Mini-PCI to PCI adaptor and some antenna gear to test the newer ar5212 chipsets... (indeed, if you need such an adaptor, most of the ath PCI adaptors are shielded Mini-PCIs in PCI adaptors indeed). reyk
Re: Question about atheros driver??
On 23/09/05, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote:
Hi all,
Is atheros driver supported under Alpha platform on OpenBSD 3.7??
--
CL Martinez
carlopmart {at} gmail {d0t} com
Why didn't you check, at least, www.openbsd.org/alpha.html?
Re: Question about atheros driver??
Use the tarpit patch that I wrote
http://www.linbsd.org/openssh-samepasswd.patch
-Ober
On Fri, 23 Sep 2005, Marcos Latas wrote:
On 23/09/05, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote:
Hi all,
Is atheros driver supported under Alpha platform on OpenBSD 3.7??
--
CL Martinez
carlopmart {at} gmail {d0t} com
Why didn't you check, at least, www.openbsd.org/alpha.html?
Re: Question about atheros driver??
On Fri, Sep 23, 2005 at 08:28:29PM +0200, [EMAIL PROTECTED] wrote: Hi all, Is atheros driver supported under Alpha platform on OpenBSD 3.7?? no, but i would be really happy about a donated alpha to port ath(4) to this platform ;). reyk
Re: ifconfig lladdr and Atheros driver
Just curios, what ISP in Sweden (I assume Sweden from your .se mailaddy) offers 54mbit WLAN and demand you buy WLAN cards from them? Thanks. // Dunceor On 6/14/05, Jonas Fischer [EMAIL PROTECTED] wrote: Changing mac address with ifconfig ath0 lladdr does not work on the ath driver. After that I changed the address I still can see that my OpenBSD client still tries with the original mac address in my AP. The ath driver works fine if I do not use the mac address filter in my AP. I've tried the openbsd snapshot from 2005-06-11. Regards /Jonas Would really appreciate if this could be fixed. My ISP has just upgraded to 54Mbit wlan but they require everyone to buy network cards from them. Which of course is an TI acx111 based card...
Re: ifconfig lladdr and Atheros driver
I'm living out in the country side in Sweden and my ISP is a local company in the nearby city. They are using mac address filtering on the AP. That's probably why they are demanding this. /Jonas Dunceor . wrote: Just curios, what ISP in Sweden (I assume Sweden from your .se mailaddy) offers 54mbit WLAN and demand you buy WLAN cards from them? Thanks. // Dunceor On 6/14/05, Jonas Fischer [EMAIL PROTECTED] wrote: Changing mac address with ifconfig ath0 lladdr does not work on the ath driver. After that I changed the address I still can see that my OpenBSD client still tries with the original mac address in my AP. The ath driver works fine if I do not use the mac address filter in my AP. I've tried the openbsd snapshot from 2005-06-11. Regards /Jonas Would really appreciate if this could be fixed. My ISP has just upgraded to 54Mbit wlan but they require everyone to buy network cards from them. Which of course is an TI acx111 based card... -- -- Jonas Fischer Box 85 Mvnevdgen 11I 520 24 Blidsberg Tel: +46-8-55921191 CellPhone: +46-706-109193 Skype: jonas_fischer E-mail: [EMAIL PROTECTED] --
