Chumby WiFi cookbook fail

[dbc]

I'm trying to follow:
http://wiki.ladyada.net/chumbyhackerboa ... fi_network
to bring up WiFi on a Chumby hacker board V1.
I get:

Code: Select all

[  148.660000] usb 1-1.2: new high speed USB device using fsl-ehci and address 4
[  148.820000] usb 1-1.2: configuration #1 chosen from 1 choice
[  149.010000] Registered led device: rt2800usb-phy1::radio
[  149.020000] Registered led device: rt2800usb-phy1::assoc
[  149.050000] Registered led device: rt2800usb-phy1::quality
[  149.410000] rt2800usb 1-1.2:1.0: firmware: requesting rt2870.bin
[  150.280000] ADDRCONF(NETDEV_UP): wlan0: link is not ready

chumby-:/ # iwlist wlan0 scan
wlan0     No scan results

So it seems that the WiFi stick that Adafruit is shipping is based on a different chipset from the one in the wiki page, but the USB system doesn't seem to have problems finding a driver. But nothing I try can seem to make it see my WiFi network. I've got the chumby sitting 3 feet away from my wireless AP, and my iPod touch finds it just fine with a strong signal, so I don't think there is an RF issue.

Has anyone else tried to do this with the rt2800 dongles that Adafruit is currently shipping?

-dave

[dbc]

Additional information: After searching around the net, I see that people running Ubuntu, Suse, etc, are having trouble with rt2x00 drivers tripping over rt2870 drivers and seeing the same symptoms that I am. They are solving the problem by blacklisting rt2x00 drivers. I've got a post on the CHB support forum to find out how to blacklist modules in Chumby's linux, so I will run that experiment.

But... I'm wondering... did anybody at Adafruit actually test the RT2870 dongles with a CHB? Did your vendor perhaps do you in by shipping a product with the exact same part number but different chip set and not tell you? (I've had vendors do worse to me, so don't take this as a complaint -- been there, got the T-shirt.)

-dave

[dbc]

More info:

At the TP-Link web site they offer driver downloads for V1, V2, V3 and V4 versions of the WN321G. The driver files are the same size for V1-3, and different for V4, so I suspect the chip set change came in with V4. (I have a V4).

[adafruit]

we absolutely tested the dongles (321G) wth a CHB which is how we got the screenshots! they have always been the same part number ordered from the vendor and they look identical!
so we are not sure about them having a different chip.
we can't pull each product out of the box to test but we did sample a few and had no problems.
it sounds like whatever changed, changed very recently. thanks for letting us know! we have directly contacted the chumby hacker board devs.
if you can find a solution, we'll update our documentation. if you can't we can arrange for a refund.

[dbc]

we absolutely tested the dongles (321G) wth a CHB which is how we got the screenshots! they have always been the same part number ordered from the vendor and they look identical!
so we are not sure about them having a different chip.
we can't pull each product out of the box to test but we did sample a few and had no problems.

Oh, yes, I didn't mean to imply that you never tested them, I meant to ask a specific data question -- "did you test rev 4" -- sorry if it came off as inflamatory, it wasn't meant that way.

it sounds like whatever changed, changed very recently. thanks for letting us know! we have directly contacted the chumby hacker board devs.

The product is slightly different in two ways: 1) the product number is printed on the front in a different orientation, 2) if you get a magnifying glass and look on the back, the FCC ID ends 'V4'. I can see the vendor part number is identical, clearly they simply did a chip set change and rolled the drivers but kept all the marketing doc & skins the same.

if you can find a solution, we'll update our documentation. if you can't we can arrange for a refund.

I think that I can get this working by giving modprobe a blacklist -- I just need to find out how the Chumby flavor of Linux wants to see blacklists. I'm not too worried about a refund -- if I can't make it work I'll take it to the local robot club as swap fodder. In any case, if I find a solution I'll post it.

[adafruit]

we have not tried this new rev - but now that we are aware of the issue we are working on it. the chumby devs seem to imply got this working at some point we will update as we get information and also scour the boxes we have to see how many are rev4 and take those out of stock

[dbc]

What I gather from various info I have been able to google up is that the rt2x00 drivers were intended to cover the 2870 case, but some issue came up so the released drivers don't handle 2870. 2870 has it's own driver. The snag happens when the generic driver claims the 2870, thus the fix I've seen elsewhere is to blacklist the generic driver. Anyway... when I get a chance I will try to confirm that.

[adafruit]

OK here is the response:

"There are two drivers for the rt2780. There's the official one, and the community one (from the rt2x00 project, called "rt2800".)

The official one sucks. It has its own config file that's nonstandard, can't be run in AP mode, has a nonstandard wifi device name, has a ton of privileged calls, and it looks like you might have to reboot (?) to get it to change networks. I could be wrong on that, though.

Could you give the attached files a try? Create the directory /lib/firmware/RT2870STA and copy RT2870STA.dat to /lib/firmware/RT2870STA/RT2870STA.dat. Then copy rt3070sta.ko to /lib/firmware/2.6.28/extra/ and remove /lib/firmware/2.6.28/drivers/network/rt2x00/rt2800.ko and run "depmod -a". (Those paths may be slightly different, and the "extra" directory may need to be re-created). Hopefully, things will work when you reboot."

do you mind trying it out? it might be a few days until we find time to dedicate and if you want to try it might Just Work

[dbc]

Absolutely I'll try it. I should have a chance to test it and report back by Monday evening or so.

[dbc]

Got a chance to try it tonight. Very close, but it seems the driver was built against a different kernel.

Also:

Those paths may be slightly different

or maybe wildly different?

Here are the gruesome details:

Code: Select all

1. create directory: /lib/firmware/RT2870STA
2. cp RT2870STA.dat to /lib/firmware/RT2870STA/RT2870STA.dat
3. create directory: /lib/modules/2.6.28-chumby/extra
4. cp rt3070sta.ko to /lib/modules/2.6.28-chumby/extra/
5a. mv /lib/modules/2.6.28-chumby/updates/drivers/net/wireless/rt2x00/rt2800usb.ko
     to /mnt/storage/removed/ -- just to be a binary pack rat, rm has no undo.
5b. mv /lib/modules/2.6.28-chumby/updates/drivers/net/wireless/rt2x00/rt2800lib.ko
     to /mnt/storage/removed/
6. depmod -a
7. reboot
8. insert device, dmesg reports:
chumby-:/ # [   42.890000] usb 1-1.1: new high speed USB device using fsl-ehci and address 3
[   43.050000] usb 1-1.1: configuration #1 chosen from 1 choice
[   43.290000] rt3070sta: disagrees about version of symbol struct_module

9. get my kernel version:
chumby-:/ # more /proc/version
Linux version 2.6.28-chumby (builder@stormbuild) (gcc version 4.3.2 (Sourcery G++ Lite 2008q3-72) ) #302 PREEMPT Wed Jul 28 14:40:46 PDT 2010

So...
1. Yes, the paths in the build that was shipped in my recent V1 CHB are somewhat different.
2. The rt2800 module appears to have two pieces. I ripped them both out on a hunch.
3. The kernel is now attempting to load the driver we want to load, so the basic instructions appear sound.
4. The kernel and the driver disagree about the interface -- this indicates that the driver was built
against a different kernel than the one I have.

Bottom line: Very close. We need to sort out the kernel version skew and test again.

[dbc]

So, should I be expecting a new build of the driver to check out?

I posted over at the Chumby forums:
http://forum.chumby.com/viewtopic.php?id=6061
hoping that someone there can help sort out the version issue. I'd like to be able to give you an update for the HowTo that works with the V4 dongles.

In order to do this driver build myself, I need to solve two problems: a) Identify exactly which kernel I have so that I can get the right sources, b) construct the build environment from scratch. Part b isn't going to happen fast, although I eventually want to get there.

[adafruit]

please be patient, we have emailed the devs, and expect a response but they are in asia so emails take an extra day

[dbc]

please be patient, we have emailed the devs, and expect a response but they are in asia so emails take an extra day

OK, no problem.

[adafruit]

OK we got a new driver can you try this .ko?

[dbc]

Yes, sure. Unfortunately my calendar is as tight as a fiddle string for a while -- it will probably be late Tuesday before I get to it.

-dave