Run device driver seems to be missing from pfSense 2.0

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