Run device driver seems to be missing from pfSense 2.0

wallabybob

The FreeBSD 8.1 release notes say The run(4) driver for Ralink RT2700U/RT2800U/RT3000U USB 802.11agn devices has been added. The driver is in the source code tree but there is no man page for it.

I bought a Tenda W311U usb stick for under US$20 (after converting from local currency) and it was immediately recognised by the run driver on a FreeBSD 8.1 system. The driver source suggests it supports hostap mode (and station monitor, WDS and possibly others). I was able to initialise it in hostap mode in FreeBSD.

I copied the FreeBSD driver files (/boot/kernel/if_run.ko and if_run.ko.symbols to /boot/kernel on pfSense, kldload'd the driver, plugged in the NIC and the NIC was recognised by the run driver without problem.

On pfSense I edited /etc/inc/globals.inc to add run to the list of known wireless devices and /etc/inc/interfaces.inc to add run to the list of known interfaces with ALTQ support. Here are the diffs:

diff -b -C 4 /etc/inc/globals.inc.orig /etc/inc/globals.inc

*** /etc/inc/globals.inc.orig Mon Aug 23 16:16:13 2010
–- /etc/inc/globals.inc Mon Aug 23 16:17:05 2010

*** 102,110 ****
"captiveportal_element_sizelimit" => 1048576,
"xmlrpcpath" => "/pfSense/xmlrpc.php",
"embeddedbootupslice" => "/dev/ad0a",
"services_dhcp_server_enable" => true,
! "wireless_regex" => "/^(ndis|wi|ath|an|ral|ural|iwi|wlan|rum|zyd|mwl|bwi|ipw|iwn|malo|uath|upgt|urtw|wpi)/",
"help_base_url" => "/help.php"
);

// Loop through and set vlan_long_frame VLAN_MTU
--- 102,110 ----
"captiveportal_element_sizelimit" => 1048576,
"xmlrpcpath" => "/pfSense/xmlrpc.php",
"embeddedbootupslice" => "/dev/ad0a",
"services_dhcp_server_enable" => true,
! "wireless_regex" => "/^(ndis|wi|ath|an|ral|ural|iwi|wlan|rum|run|zyd|mwl|bwi|ipw|iwn|malo|uath|upgt|urtw|wpi)/",
"help_base_url" => "/help.php"
);

// Loop through and set vlan_long_frame VLAN_MTU

diff -b -C 4 /etc/inc/interfaces.inc.orig /etc/inc/interfaces.inc

*** /etc/inc/interfaces.inc.orig Mon Aug 23 16:16:24 2010
--- /etc/inc/interfaces.inc Mon Aug 23 16:18:30 2010

*** 3183,3191 ****
*/
$capable = array("age", "ale", "an", "ath", "aue", "awi", "bce",
"bfe", "bge", "dc", "de", "ed", "em", "ep", "fxp", "gem",
"hme", "igb", "ipw", "iwi", "jme", "le", "msk", "mxge", "my", "nfe",
! "npe", "nve", "ral", "re", "rl", "rum", "sf", "sis", "sk",
"ste", "stge", "txp", "udav", "ural", "vge", "vr", "wi", "xl",
"ndis", "tun", "ovpns", "ovpnc", "vlan", "pppoe", "pptp", "ng",
"l2tp", "ppp");

--- 3183,3191 ----
*/
$capable = array("age", "ale", "an", "ath", "aue", "awi", "bce",
"bfe", "bge", "dc", "de", "ed", "em", "ep", "fxp", "gem",
"hme", "igb", "ipw", "iwi", "jme", "le", "msk", "mxge", "my", "nfe",
! "npe", "nve", "ral", "re", "rl", "rum", "run", "sf", "sis", "sk",
"ste", "stge", "txp", "udav", "ural", "vge", "vr", "wi", "xl",
"ndis", "tun", "ovpns", "ovpnc", "vlan", "pppoe", "pptp", "ng",
"l2tp", "ppp");

Then I rebooted and was able to configure the wireless aspects of run0 (ssid, crypto, etc)

I'll report again after I've had an opportunity to exercise the device.

wallabybob

I configured it as an AP with WPA2 encryption and it has been downloading from the internet and file transferring files from other systems on the LAN for a couple of hours now without hiccup.

eri--

Committed.

wallabybob

Thanks.

jimp

I went ahead and added it to the kernel configs, and bwn(4) too since it looks like it made it in.

wallabybob

Suggested further updates to the wireless support spreadsheet (based on a reading of the source code; I haven't tested these except hostap mode):

adhoc: Y
mesh: Y
Virt Ints: 8? (I'm not sure what this entry means; the driver appears to allow 8 virtual APs but are they the same as Virt Ints? HostAP entry should be YM? Should other _Y_s be _YM_s?)
Firmware: runfw

jimp

I went ahead and updated those fields. I added YM to the hostap column since you saw that it supported 8 virtual APs.

Usually if it supports multiple stations it would say virtual stations as well as APs, but I haven't looked too deeply at the code.

shadow

i had to dink to get runfw, but it appears this is working.

jimp

Yeah, runfw was missed (by me). That's what happens when a driver doesn't have a man page stating what options it really needs :P

It's in now and a new snapshot is building.

wallabybob

I think the firmware entry might still be missing from the google docs spreadsheet.

jimp

Fixed :-)

wallabybob

I upgraded to a recent snapshot that I expected would include the run driver in the kernel.

On reboot the startup reported:

ugen3.2: <ralink>at usbus3
run0: <1.0> on usbus3
run0: MAC/BBP RT3070 (rev 0x0201), RF RT3020 (MIMO 1T1R), address c8:3a:35:c4:ee:f3
runfw: root not mounted yet, no way to load image
run0: failed loadfirmware of file runfw
run0: could not load 8051 microcode
device_attach: run0 attach returned 6
run0: <1.0> on usbus3
run0: MAC/BBP RT3070 (rev 0x0201), RF RT3020 (MIMO 1T1R), address c8:3a:35:c4:ee:f3
runfw: root not mounted yet, no way to load image
run0: failed loadfirmware of file runfw
run0: could not load 8051 microcode
device_attach: run0 attach returned 6
Root mount waiting for: usbus3
ugen3.3: <ralink>at usbus3
rum0: <ralink 0="" 3="" 54m.usb…....,="" class="" 0,="" rev="" 2.00="" 0.01,="" addr="">on usbus3
rum0: MAC/BBP RT2573 (rev 0x2573a), RF RT2528
Trying to mount root from ufs:/dev/ad0s1a</ralink></ralink></ralink>

I removed the run device and reinserted it and the firmware (unsurprisingly) loaded,

I added the line:
runfw_load="YES"
to /boot/loader.conf

Preferred option is to include the firmware as part of the kernel rather than a separate module?

jimp

I tried, it wouldn't build into the kernel. runfw isn't a valid kernel config directive.

Perhaps that is something that the driver's maintainer still has yet to fix.

shadow

is loader.conf preserved across updates, or is this going to be an unpleasant surprise waiting for later?

jimp

I think loader.conf is clobbered, but loader.conf.local is left alone.

Ideally they should both be safe, I think there is a ticket open for it getting overwritten.

shadow

for the record, it appears the run driver doesn't work reliably yet anyway. I can associate but IP traffic is broken, looks similar to kern/132722.

I'll be collecting more info and reporting it.

wallabybob

I've had over 100MB download successfully over a run link and I've not seen anything I would consider to be like kern/132722.

Can you describe your problem in a bit more detail?

shadow

Are you in hostap mode, or station?

I'm in hostap mode. In either crypted mode (WEP or WPA) I associate and then get no useful IP traffic. In non-crypted mode, I associate, DHCP, and then get a connection with apparent packet loss on the return trip.

run0: <1.0> on usbus2
run0: MAC/BBP RT2872 (rev 0x0202), RF RT2850 (MIMO 2T2R), address 00:0e:8e:24:9b:48
run0: firmware RT2870 loaded

I submitted a PR just now.

wallabybob

@shadow:

Are you in hostap mode, or station?

My run device is in hostap mode, WPA2 and AES. Here is how it is reported in startup.

ugen3.2: <ralink>at usbus3
run0: <1.0> on usbus3
run0: MAC/BBP RT3070 (rev 0x0201), RF RT3020 (MIMO 1T1R), address c8:3a:35:c4:ee:f3
run0: firmware RT2870 loaded</ralink>

I had some trouble with Windows Vista clients (required a registry tweak on Vista to get DHCP to work) and a Ubuntu 10.04 client (fixed by changing from TKIP to AES on Access Point) some time ago using an Atheros NIC in pfSense as AP. I made the run settings the same as the Atheros settings I was using and everything just worked when talking with the run as AP.

shadow

usb/150189

The machine also has an ath, and I used the same settings initially except the run was in 802.11a mode. I also tried the run in 802.11g mode. I then changed WEP to WPA. I then turned crypt off.

ldperron

I have a RT3070 fully working here in HOSTAP mode. The wireless card is not really common in the market, but works well: http://www.winxim.com.cn/en/products_xq.asp?ProductNO=24
If you need help to settle the "?" in the spreadsheet, I'm willing to help… just tell me what need to be tested.

I think it caught a bug on my first try... it was impossible to associate with it, but it may be because I create and deleted a VAP in the interfaces TAB, because actually chosing "run0" interface directly for my wifi interface. I will try to reproduce it if I have time. A reboot fixed the issue.

I indeed had to add runfw_load="YES" in my loader.conf.

I now have a good question: can this driver be easily backported to FreeBsd 7.2 (pfSense 1.2.3)?

Thanks

wallabybob

@ldperron:

I now have a good question: can this driver be easily backported to FreeBsd 7.2 (pfSense 1.2.3)?

Probably not easily since the USB stack in FreeBSD 8.x is different from the USB stack in FreeBSD 7.2. But I have no idea how different the two USB stacks are.

jimp

Different enough that I doubt it would be worth the effort involved.

shadow

@shadow:

for the record, it appears the run driver doesn't work reliably yet anyway. I can associate but IP traffic is broken, looks similar to kern/132722.

I'll be collecting more info and reporting it.

2 bugs. One in ehci:
http://lists.freebsd.org/pipermail/freebsd-current/2010-October/020504.html
and one in the 802.11a support (at least)
http://gitorious.org/run/run/commits/P4_ratectl_fix