Run device driver seems to be missing from pfSense 2.0
-
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 -
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.
-
i had to dink to get runfw, but it appears this is working.
-
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.
-
I think the firmware entry might still be missing from the google docs spreadsheet.
-
Fixed :-)
-
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.confPreferred option is to include the firmware as part of the kernel rather than a separate module?
-
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.
-
is loader.conf preserved across updates, or is this going to be an unpleasant surprise waiting for later?
-
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.
-
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.
-
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?
-
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 loadedI submitted a PR just now.
-
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.
-
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.
-
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
-
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.
-
Different enough that I doubt it would be worth the effort involved.
-
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
