Neuros OSD 1.0 WiFi

From The Neuros Technology Wiki

This page details the ongoing progress of WiFi support on the OSD. I will try to keep it as up to date as possible. Support for some USB wifi dongles based on Ralink RT73 chipset was added into trunk at end of last week. While the driver works great for incoming data, it has still serious problems with outgoing data (see below) . --Nerochiaro 03:02, 30 April 2007 (CDT)

Contents 1 Supported dongles 2 USB Drivers 3 Wireless tools 4 Setting up wireless network 5 Open Issues and Things That Need Testing 6 Notes on Debugging 7 Design of WiFi User interface

[edit] Supported dongles

First, this will only work with the dongles that use the Ralink RT73 chip. There are various dongles that use this chip:

• Asus WL-167G (0b05:1723)
• Belkin F5D7050EF (0x50d:0x200)
• Belkin F5D7050ES (050d:705a)
• Conceptronic C54RU Ver2 (14b2:3c22)
• D-Link DWL-G122 H/W Ver.:C1 (07d1:3c03)
• Edimax EW7318UG (148f:2573)
• Linksys WUSB54GC (13b1:0020)
• Sitecom WL-113 (0df6:9712)
• Sitecom WL-172 (0df6:90ac)
• Surecom EP-9001-g (0769:31f3)
• PLanex GW-US54HP (????:????)
• Digitus DN-7003GR VPR 1.0 (????:????)

The numbers in parenthesis is the values you see if you attach the dongles in a Linux PC and run lsusb. There might be more dongles supported, but that's the ones i know about for now.

I used the Asus WL-167G for all my tests. It seems that there's an older version of this dongle which uses another, older, Ralink chip (rt2570), but i have no idea how that looks or how to find out the difference. Here's pictures of all the numbered labels on my dongle, they may or may not be useful to you: [1] [2]

Also remember that for dongles using the RT2570 chipset, you can try and follow the very old (but still partly meaningful instructions) from Ron's RT2570 HOWTO.

[edit] USB Drivers

The driver I used is the one from Serialmonkey project. They basically took the original driver from Ralink and modified to work better. They have a CVS version for the rt73 driver that is still receiving improvements, and I simply picked a nightly CVS snapshot around the end of April and checked it in into our SVN tree under /kernel/linux/drivers/usb/net/rt73. We might want to merge with the upstream CVS version from time to time to pick up the improvements they make.

All the problems I had in making this work in the end were almost all caused by our USB Host driver : /kernel/linux/drivers/usb/host/dm320/dm320-hcd.c For some reason it made all transfers of type Control be very slow and always time out. The fix was to change the register USB_RXINTVL to a small value, i'm still not sure why (Michael suggested it), but it worked.

The driver is built as part of the kernel and ends up in the final firmware with all the other drivers. However i have not added into the init scripts the commands to load it automatically. You can load it anytime by doing

 insmod rt73

or with debug information (lots of it) with

 insmod rt73 debug=2

I have also enabled in the default ntosd-dm320_defcofig kernel config script the option CONFIG_NET_RADIO, so the Linux wireless extension are in place. If you get a strange message of symbols not defined when you load this module, try double checking you have rebuilt your kernel with that option active.

This creates a new network interface called rausb0 (you see it in iwconfig). If you want to manipulate this interface in any way with the wireless tools (see below), you first neet to bring it up. The following will be the minimum needed to do it:

 ifconfig rausb0 up

Of course you might want to set an IP address and netmask for it, but you can always do that later.

[edit] Wireless tools

I checked into the tree the latest version of Linux wireless tools (linux-r3-extra-apps/wireless_tools.28) and enabled their automatic build when using neuros-bsp/build-helper.sh

The tools end up in /sbin on the final root file system and take up only around 56K (due to the multicall binary design).

You use these tools to setup wireless specific network parameters, as explained below

[edit] Setting up wireless network

The driver can work in different configurations, but we'll look only at managed mode here, which allows to associate the dongle with an Access Point (AP) and thus enter in its wireless network. So first thing we need to do is to bring the dongle in managed mode:

 iwconfig rausb0 mode managed

Then you can check for wireless networks around you by asking the driver to give you a site survey with:

 iwpriv rausb0 get_site_survey

This outputs a list of all access points available in the area. If you don't see anything, you might want to wait 20 seconds or so after you bring up the rausb0 interface, so that it has time to scan the air for networks.

The basic things you need to do for all types of networks are setting the channel and the networks SSID (i.e. the network name) to which you want to connect (you can get these two values from the site survey above):

 iwconfig rausb0 essid YOUR_NETWORK
 iwconfig rausb0 channel N

If the network is open, if you wait some seconds and then ask

 iwconfig rausb0 

If you see a line that has "Access point: SOMETHING" in it, then you're up and associated.

If the network has WEP authentication, to associate with the AP you need to authenticate this way:

 iwpriv rausb0 set AuthMode=WEPAUTO
 iwpriv rausb0 set EncrypType=WEP
 iwpriv rausb0 set Key1="YOUR_WEP_PASSWORD"
 iwpriv rausb0 set SSID="YOUR_NETWORK"

The parameter in YOUR_NETWORK is the same you used above with iwconfig.

And if the network has WPA authentication, you need to do this instead:

 iwpriv rausb0 set AuthMode=WPAPSK
 iwpriv rausb0 set EncrypType=TKIP
 iwpriv rausb0 set WPAPSK="YOUR_WPA_PASSWORD"
 iwpriv rausb0 set SSID="YOUR_NETWORK"

This is for WPA with pre-shared key (PSK). This is the most common usage in residential and SOHO setups. Some office setups use WPA Radius to authenticate, but I don't know how to setup that and I doubt we will need to know initially.

[edit] Open Issues and Things That Need Testing

Everything that is related to incoming transmissions works pretty well. I've used the dongle to dowload via HTTP with wget and it worked without a problem, even for very large files. Pinging stuff for long times also works. For example leave this will download an huge test file available just for this kind of tests:

 wget http://mirror.mclink.it/test.zip -O /dev/null

You can leave this running from the serial console and see how things go. I left mine for half an hour and it never had a problem (please note emphasis on doing this from serial console. if you do it from telnet, you will generate more outgoing traffic and this may trigger the bug below). (clearly you need to put wget on the OSD to use it, just enable CONFIG_WGET in neuros-bsp/sysapps/busybox/ntosd-dm320_defconfig and reconfgure/rebuild busybox).

However outgoing transmissions have serious problems. After some outgoing traffic fatal problems start to happen. For example using telnet to access the device and doing an ls on a large directory or cat of a large file is enough to trigger this problem.

To trigger this bug the easier way is to telnet into the box and do a simple:

  while [ 1 ] ; do find /usr/ ; done

This will repeat the command forever, and create enough traffic to make the bug appear.

Interestingly enough if you put a command that generated smaller bits of text like

  while [ 1 ] ; do echo "foo" ; done

The bug doesn't seem to appear.

So it seems the problem is again on the USB host driver since what happens is usb_control_msg timeouts and even the dongle getting disconnected (you see "INT RESET" message on the console). It might be worth trying to tune the value of the USB_TXINTVL on the driver to see if this helps, so far i've had no success with that, though.

To be able to see the bug when it happens even without the rest of the wifi-specific debug info (which is overwhelmingly huge) you can patch the driver with this patch that turns fatal messages in non-conditional printks, then you can load the driver with debug turned off and still see only these errors when they happen. See also the next section for more debug tricks.

I'm pretty sure the key to making this work is to understand what is really causing the usb_control_msg timeouts. It's related to these RX and TX interval registers, but in which way, why, and if that's the only factor is still something that needs to be found out.

[edit] Notes on Debugging

Obviously you need to debug from a cramfs boot, since you need bring eth0 down to be sure to route all traffic thru the wifi interface and this won't work with NFS mounted root. (If you're good at networking you may be able to use the route command to send data to the NFS host on the wired ethernet and all the rest of the data on the wireless, but i wasn't able to do it).

If you need to recompile the kernel to change the USB Host driver, you need to reflash it (but since you can make upk packages that only update the kernel, it won't take too much time). If you want to change only the driver, it's better to recompile it and then put it on media card and insmod it from there.

If you want to debug the driver then loading the driver with debug=2 might be a good idea, but also adds lots of processing overhead to output lots of debug text to the console. If you do this, you will need to telnet into the box to run test commands, because the serial console will be overrun by debug messages. Another better option is to figure out how to redirect output to a file with syslogd, instead of clogging the serial console. See this post in mailing list for how to do this, I have not tried it myself.

You might want to use debug=2 at first to isolate problems, but then when you know more or less where the problem are is, it's better to recompile the driver with printk instead of the conditional debug messages. Then you load it without debug support, but the debug messages that you changed to use printk will always appear, so you will have a cleaner view.

When the driver crashes or goes into USB timeouts or USB STALL, it's better to do

 ifconfig rausb0 down
 rmmod rt73

and then detach the USB dongle and re-attach it before doing anything else. This completely resets everything, which is always the best thing to do when debugging.

Good luck if you're going to try this !

[edit] Design of WiFi User interface

I've talked a bit with John Olson on this, and here's an idea for the design of the user interaction for the device, and some notes on how to implement it.

I'll add these here in a bit.