Monday, May 30, 2011

wusb54g - ralink 2500

A family member running kernel was having some problems with her older Linksys WUSB54G (Ralink 2500 chip). As seen in the photo, this is an external USB Wi-Fi card. When I installed her system (Zenwalk Slackware) back in 2009, ndiswrapper was the answer for this chip, which was posing problems for some Linux installations. It did fine, even with encryption and so on. Recently however, the relatives de-encrypted their network, probably so a visiting relative could use their network or during a Windows update, and the Linksys card was unable to associate with the LAN router once the network was keyless. This is a matter of opening or dropping the encryption configuration line and then ordering the remaining lines. However, over a telephone, implementing these kinds of changes required a lot of patience from my relative (thank you, Mom!). Ultimately, at least over the phone, it appeared there was no associating to this unencrypted network via ndiswrapper and using standard commands such as, say:
iwconfig wlan0 essid Foo
iwconfig wlan0 key open #(or using "off")
iwconfig wlan0 ap 00:20:etc
So it was a conundrum. We tried several different permutations, as noted above, before giving-up for the weekend.

Then I got to thinking about the old rt2500 driver. This driver is anachronistic, as all of these legacy Ralink cards now are managed directly in the kernel. But it is less anachronistic than ndiswrapper. Further, it would be a lot to ask a family member to update their entire system, a full Linux installation, with only telephone guidance. It looked like the middle ground would be to withdraw ndiswrapper and install the last/latest rt2500 driver to see if it was less finicky. Would the source for this older driver still be available. Turns out it was no longer available at the Ralink site. Summary: I couldn't travel to Mom's place to make the changes and it had been going slowly over the phone.

Solution: Linksys WUSB100

I locally purchased a WUSB100, id 1737:0078 ($15), to install onto my system, make configuration software, and then mail to her. There are two versions of WUSB100

Version 1 module rt2870sta

This site indicates that the the rt2870sta works with the following Linksys USBs:
USB: 1737:0070 Linksys WUSB100 v1 RangePlus Wireless Network Adapter [Ralink RT2870]
USB: 1737:0071 Linksys WUSB600N v1 Dual-Band Wireless-N Network Adapter [Ralink RT2870]
USB: 1737:0077 Linksys WUSB54GC v3 802.11g Adapter [Ralink RT2070L]
Noting that my 1737:0078 is not on that list

Version 2 - module rt2870 or rt3070?

Written on the back of the WUSB100 in my possession: FCCID Q87-WUSB100v2. Still began with the rt2870 since some were having success with this. The kernel would recognize it and assign ra0, but would not assign memory resources or allow connection. During this process, found there are at least two chips in version 2, the Belkin 050d:825b or what I have, the Ralink chip 1737:0078. I'm on the right track but, for the Ralink chip, it appears will have to go to the rt3070sta which means a patch is necessary. That will be my next weekend project. Meanwhile, I've also left the Belkin stuff here for those who have Belkins.
Ralink This is supposed to take care of the patch stuff according to this site
I believe the fix is to replace all instances of usb_buffer_alloc with usb_alloc_coherent and all instances of usb_buffer_free with usb_free_coherent. The instances I replaced were in include/os/rt_linux.h and os/linux/rt_usb_util.c.

preinstalled driver attempts

Well before I compiled the rt3070sta module, I had hoped for the good luck of a driver included with the distro working. In favor of such a dream, the WUSB100 was detected by udevmonitor and lsusb. However, no module was being loaded. Thus, I looked in the wifi driver directory for useful drviers included with the distro:
$ls /lib/modules/
[snip] rtl8187.ko rt2x00 (directory) rtl8180.ko
$ls /lib/modules/
rt2400pci.ko rt2500pci.ko rt2500usb.ko rt2x00lib.ko rt2x00pci.ko rt2x00usb.ko rt61pci.ko rt73usb.ko
I tried loading some of these with modprobe but the card continued to go unreachable. That is, in spite of modprobing these drivers in, the command
#ifconfig ra0 up (or wifi0, etc)
was yielding nothing. Back to the Google machine.

module rt2870sta attempts

Also before compiling the rt3070sta, I'd noticed some had success with the rt2870sta module and a few tweaks. It wasn't already onboard:
root[/]# find -iname rt2870*
  • downloaded rt3070sta, now deprecated, cached here (scroll down to "nightflier"'s post) and also here, along with some associated patches.
  • downloaded the rt2870sta source, now deprecated, here.This provided me with version2010_0709_RT2870_Linux_STA_v2.4.0.1.tar.bz2.
  • downloaded the firmware, same location. File is
  • The settings for rt2870sta.dat are explained here

rt2870sta compiling notes

most comprehensive link
Before compiling, be sure the card ID "1737:0078" is included in the card ID section. I located them by navigating to the top source directory and then
$ grep -r USB_DEVICE *
In my source, these statements were in /common/rtusb_dev_id.c. I added the line in there:
{USB_DEVICE(0x1737,0x0078)}, /* Linksys WUSB100v2 Pepsi */
(I like Pepsi, so whatever). In this fellow's source, they were in rt2870.h.
Still within the source directory, I also made the following change
$ geany /os/linux/
Blacklist any modules that might attempt to load and conflict.
# geany /etc/modprobe.d/blacklist
blacklist rt2x00usb
blacklist rt2x00lib
blacklist rt2500usb
Backed-up the default /etc/Wireless/RT2870STA/RT2870STA.dat
# cp /etc/Wireless/RT2870STA/RT2870STA.dat /etc/Wireless/RT2870STA/RT2870STA.bak.def
Compiling is a basic $make/#make install operation. Unzip and install the firmware, although I noted no significant change from before the firmware was installed to after.
# cp Download/RT2870_Firmware_V22/rt2870.bin /lib/firmware/
# chmod 555 /lib/firmware/rt2870.bin
After compiling, installation, and modprobing, it's good to run # depmod, so I did that as well. Zince I'm using Zlackware Zenwalk, added the MAC to /etc/iftab. Added the module and updated the kernel
# depmod

After all of this, the rt2870sta was a no-go. A deeper look, showed that it lacks product and bus information and was not even being assigned an IRQ or other resources. For example, compare it to the (working) Atheros card below
# lshw -C network
description: Wireless interface
product: AR242x 802.11abg Wireless PCI Express Adapter
vendor: Atheros Communications Inc.
physical id: 0
bus info: pci@0000:05:00.0
logical name: wifi0
version: 01
serial: 00:2e:xx:xx:xx:xx
width: 64 bits
clock: 33MHz
capabilities: pm msi pciexpress msix bus_master cap_list logical ethernet physical wireless
configuration: broadcast=yes driver=ath_pci ip= latency=0 multicast=yes wireless=IEEE 802.11g
resources: irq:18 memory:f3100000-f310ffff
description: Wireless interface
physical id: 1
logical name: ra0
serial: 68:3e:xx:xx:xx:xx
capabilities: ethernet physical wireless
configuration: broadcast=yes driver=RALINK WLAN driverversion= multicast=yes wireless=Ralink STA
  • it was suggested here, that a change had to be made in /etc/udev/rules.d/10-wusb100.rules, or that the file had to be created. The rule then called rt2870sta and it would then work with the "0078" version.
  • creating a softlink worked for this guy

Saturday, May 21, 2011

ffmpeg - phone size

Links: volume post   general howto   random settings  

Mp4's and flv's are our friends, cell-phone sized (320x240 generic, 432x320 iPhone) viewables. Trick with ffmpeg is getting them there without pixellation and the right volume settings. This entry is just a collection of transcoding settings I've played with. There are plenty of good howto's out there forum information.

audio :: volume and sync

Sometimes .flv files are the correct size but with sync or volume inconsistencies. Resampling to keep volume the same is done by leaving off volume settings, or using the default setting of -vol 256. Going to 512 will double it, and I've found that 768 works well if the original sound is faint. So, to resample with an increase in volume:
$ ffmpeg -i somefile.flv -vol 512 -acodec libfaac someout.flv
I find specifying "libfaac" avoids libmp3 and its playback oddities. Increases the output file size by maybe 10 percent, say from 5.8M to 5.9M, but stable playback.

video :: pixellation

I think the pixellation that occurs shrinking videos is if the pixel size stays the same size as it was for the larger version. Also, 2 pass encoding is probably the best, sending the first pass to null, and turning off the audio ("an") and video (-y /dev/null)
$ ffmpeg somefile.avi -pass 1 -f rawvideo -y /dev/null -an

Sunday, May 15, 2011

moto V3 - linux

Links:  p2kmoto source      moto4lin source

My old HTC G1 was recently ripped-off at work and I didn't want to purchase a G2X, so it had me thinking. First I thought I'd pay the $120 insurance deductible and get a replacement G1 to take me to whenever I made a decision. Second though, I had an old V3 (device code ID 22b8:4901) sitting in a drawer -- why not activate it and see if I could live with WAP and a non-QWERTY keypad until I decided? Meanwhile, see if 2011 Linux access was enough to save contacts and photos.

activation - 10 minutes plus driving time

My G1 was T-Mobile, and I had served the two year plan. The V3 was a Cingular phone and I had also served the Cingular contract prior to switching to T-Mobile G1 in 2008. Before I switched to T-Mobile, I went to the Cingular store (by then, AT&T) and they gave me the unlock code for the V3. I never used the code, so I brought it with me to the T-Mobile store last week with the old V3. At the T-Mobile store, a dude put in a new SIM and entered the code. The V3 fired right up. He switched the V3 onto the plan I had for the G1, and away I went. I sat in the parking lot and messed with the text and the WAP for awhile, and it seemed to work. It was a blast from the past.

PC connection - a few hours

The part of the experiment Googling around for Linux access to Motorolas was uninspiring. It appeared the likely candidates were p2kmoto and moto4linux. These two pieces work together. Available at the links at the top of the page.

Compile and install p2kmoto, which puts in libp2kmoto, and the CLI executable p2ktest. Then, hook-up the phone (it takes a micro-USB cable) and run # p2ktest to see if it's connecting in the right ways. I first ran # udevmonitor to be sure that HAL was doing the right things with the phone; also double-checked with # lsusb. All was good.

Next compile and install moto4linux. The moto4linux is run simply as user, but it won't find the phone. So the order is:
# p2ktest
$ moto4linux
The above two commands are all that are needed to manage phone access and files. P2ktest apparently finds and opens the phone for access; moto4linux then does the file management. It (moto4linux) opens a GUI, so it's cut and pasty.

WAP access - ongoing