SOLVED: Linksys WUSB600N v2

After much tiddling’n’fiddling I finally got my new Linksys WUSB600N v2 working.
Contrary to many posts, mine did NOT work with either the standard rt2870sta module, nor the updated version from the driver:wireless repo.
Also the rt2870 version from the ralink website didn’ t work.
After a days worth of Googling I came across this post. The bottom line?

  1. Download rt3572 from the Ralink website.
  2. Add {USB_DEVICE(0x1737,0x0079)}, /* WUSB600N v2 */ to common/rtusb_dev_id.c
  3. Follow README_STA

I did not install firmware packages. And be sure the rt2800sta module doesn’ t get loaded. (you could just remove it, I suppose.)

Happy surfing! lol!
Koos

Erm

The rt3572sta-kmp-$flavor packages from driver:wireless got this extra ID added about 4 months ago and they are built from the exact same vendor source.

Additionally, I had a “guinea pig” with the exact same device and he confirmed those packages work with 1737:0079.

Cool. Glad that it works. I think I got steered towards the rt2870 so often, that when I figured out that I needed to look for the rt3572 I probably didn’t check back with driver:wireless. It was sort of an educated guess to use the rt3572 driver. How did you find out?
Too bad also no-one took the efforts off filling out their findings at the HCL:Network (Wireless) page. I think you should’ve…
Anyways, I filled in the blanks for the v2 stick. Apparently it needs to be improved. Please do so.

Thanks,
Koos

Using 1737:0079 as a search string for a big search engine (well, that and also ignoring all older threads found in several *buntu-related fora/bugtrackers as you most likely don’t find anything useful there).

(Off-topic: Seems to me, the *Buntu-bugtracker is actually sponsored by AOL, because >95% of threads there begin with $MORE_OR_LESS_USEFUL_DESCRIPTION_OF_SOME_PROBLEM followed by sometimes dozens of “answers” which -in a nutshell- read as “Me too” :-)).

I don’t know if there are a bunch of other interesting hits (especially for people who don’t understand german), but this one here gave me an idea:

http://www.linux-club.de/viewtopic.php?f=19&t=107288

Adding the ID to the kmp packages was simple, getting a “guinea pig” for testing a little more complicated (as always one might add sigh).

Adding the ID to the kmp packages was simple, getting a “guinea pig” for testing a little more complicated (as always one might add sigh).

In the future, I wouldn’t mind being a guinea pig when you need one, even if I had to order the adapter and wait a couple days to receive and test, as long as it’s not a super expensive adapter.

Although an interesting offer, there is a well known problem, which would bite you here, the only difference, it would bite you “from the other side”.

You see, one of the main problems for people trying to help some user reporting “my device from $VENDOR called $SOME_FANCY_NAME does not work” is, that names/vendors are very often of no real use.

One of the first questions (at least, if the answer is “good” ???) would ask for the device ID because that is the data that matters. Some ohter data -especially for yet “unknown” devices with a known chipset- might be found in the windows drivers (yes, they also rely on device IDs, they just hide it from the user, at least a little) and then making a more or less educated guess which existing driver might be working with that “new” device.

In order to tell you “hey, you could buy $DEVICE for testing purposes”, one would have to know of a device not yet working with linux OOTB but most likely havong a chipset already supported and only the ID is missing in some driver already out there.

One of the things that drive this sort of open development present in FOSS is “scratching an itch” and something will be fixed soon (if possible), so you would have to find the itches in advance (or even by guessing), which might be quite hard and not really an interesting thing to do.

The best way to make things better, would be to concentrate on threads with “yet unknown” devices and push the respective user having problems with it to give useful information and do some testing, simply because there you have the “itch” and now you can try to help “scratching it”.

To be frank (and thereby maybe annoy some people her, but I have a good reason for that), telling $USER to compile $SOME_DRIVER with maybe $SOME_CHANGE looks like a good advice but really isn’t at least when having in mind what adds real value to the community and/or the distribution.

It’s very simple, IF a user is able to get a device running by compiling some driver THEN it is also possible for somebody else (one of those “somebody else”-persons might be even myself) to build a package of that driver and include it into the distribution or some extra repository,

And quite frankly, this is the way to go, there is only one case where I think “compile XYZ” is a good advise, this case is directly related to a certain person, Larry and one of the drivers he is maintaining in one of his git-trees.

OTOH, IF that works and I happen to read that thread, I will try to build backported packages (and this already happened a couple of times) to add some real value to already released distributions, and by real value I mean “ready made packages the user hast to install and things will work”.

In a nutshell, I am very optimistic, that at the moment, there are driver packages for most of the devices out there, sometimes there is even more than one possible driver.

If there isn’t already a package in driver:wireless but there is a native linux driver from a vendor or in some git tree, I would try to build one.

For devices from Ralink or Realtek, there are packages in driver:wireless for every device they offer drivers except for the ones already supported by some in-kernel drivers (and for those ones, there are also up to date packages, either compat-wireless or backported staging drivers).

If somebody helps to get a device working by instructing some user to build a driver from source, he will help that person but if a package exists it can help a lot of users and make things also a lot easier (hint: kernel updates) and that is the main reason why I try to package every driver I find as soon as possible.

If a package already exists and somebody trying to help still gives advise to compile $WHATEVER, it even makes things a lot more complicated than it should be.

One of the main reasons I never switched from (open)SUSE to another distribution is the way kmp-packages handle external kernel modules and now with OBS you will always have a compatible package even if a kernel update had ABI-changes.

No other distribution I tried has something that comes even close to this framework, either they build the drivers from source in a more or less automated way (dkms, module-assistant) or the packages must be updated as well on a kernel update, on openSUSE and with kmp-packages they “survive” an update is they are compatible, if not they are updated automatically.

So if people want to really give good advise, they should always look for a driver package first, in most cases there is one.

So tagging the threads on wireless issues with the PCI-ID in a format like 1737:0079 might be not the worst of possible ideas (at least to help the helpers)?

Regards
pistazienfresser

On 01/20/2011 06:06 AM, pistazienfresser wrote:
>
> Akoellh;2280027 Wrote:
>> …]
>>
>> One of the first questions (at least, if the answer is “good” ???)
>> would ask for the device ID because that is the data that matters…]
>
> So tagging the threads on wireless issues with the PCI-ID in a format
> like -1737:0079- might be not the worst of possible ideas (at least to
> help the helpers)?

s/PCI-ID/PCI-ID or USB-ID/

That information is absolutely necessary. As Akoellh said, the vendor name/model
is essentially useless.

BTW: I will have an announcement regarding Realtek drivers for 802.11n chips
using mac80211 in the next few days. It is very exciting.

Could some body help me please. for 2 days i’m trying to get my wirless WUSB600N v2 to work but with no luck. >:(
I’m using backtrack 4 and try to do follow the readme file, but got stuck at some points.
I don’t know exactly what to do from the line => #>cd wpa_supplicant-x.x
=>#>./wpa_supplicant -Dwext -ira0 -c wpa…
**Build for being controlled…
=>#>./wpa_supplicant …
4> $make

compile driver source code…


5>.
6>…
7>…
if i could get some help for those steps what to do pleae.

I’m new to linux.

Please don’t hijack threads. If you start a new one, someone will most likely be able to help you.