RTL8187 / urtw issue

MrHorizontal

I'm having a problem with an Alfa AWUS036H USB WLAN card (based on the Realtek RTL8187 chip) and pfSense 2.0.

pfSense recognises the usb device and assigns the correct driver (urtw) - however after assigning the interface, which pfSense also recognises as a Wireless device, the interface is totally unconfigurable - ie you go to the OPT interface and try to set the SSID etc it won't do anything, and if you press Save it takes a very long time for it to save, but in fact it doesn't actually set anything. No errors, no nothing.

The device itself has no problems, as it works when plugged into Windows and Linux VM's all is fine.

Similarly the status -> wireless appears, but shows no networks.

urtw is a new FreeBSD 8 driver, if that is a bone of contention, but otherwise I don't know what I can do to diagnose this further?

jimp

I added the urtw device into the kernel a while back but I haven't heard of anyone who has tried it yet, you're the first.

I do know that card does not support hostap mode, so it can only be a wireless client. I'm not sure what problems that might present in the GUI though. I don't have any such devices to test with.

Do you get any messages in the system log when you try all this?

MrHorizontal

OK - the webconfigurator seems to freeze for about 30 seconds when you apply changes to the interface (I can't open another page in another tab for example). As I said above, nothing in the wireless networks.

I get the same message in the system log and broadcast to tty:

urtw0: expect 0xe6!! (0x66)
urtw0: expect 0xe6!! (0x66)
urtw0: RF calibration failed
urtw0: RF calibration failed

The interface is assigned to urtw0, however, ifconfig prints out:

urtw0: flags=8843 <up,broadcast,running,simplex,multicast>metric 0 mtu 2290
	ether 00:c0:ca:39:ad:fe
	media: IEEE 802.11 Wireless Ethernet autoselect mode 11g
	status: associated
urtw0_wlan0: flags=8843 <up,broadcast,running,simplex,multicast>metric 0 mtu 1500
	ether 00:c0:ca:39:ad:fe
	inet6 fe80::2c0:caff:fe39:adfe%urtw0_wlan0 prefixlen 64 scopeid 0x10 
	nd6 options=3 <performnud,accept_rtadv>media: IEEE 802.11 Wireless Ethernet autoselect mode 11g
	status: no carrier
	ssid XXX channel 10 (2457 MHz 11g)
	country US authmode WPA1+WPA2/802.11i privacy ON deftxkey UNDEF
	txpower 0 bmiss 7 scanvalid 450 bgscan bgscanintvl 300 bgscanidle 250
	roam:rssi 7 roam:rate 5 protmode RTSCTS roaming MANUAL</performnud,accept_rtadv></up,broadcast,running,simplex,multicast></up,broadcast,running,simplex,multicast>

Which I think is something to do with a WLAN clone? If so I don't have one set up…

jimp

2.0 automatically does the wireless clone behind the scenes, you shouldn't have to know or care about it.

Those messages from the driver, however, are worrisome. Sounds like it isn't getting a good response from your hardware. You may have to try it on a normal FreeBSD 8 install and if you have problems there, report it to the FreeBSD team. There isn't much we can do for drivers short of adding/removing them from our kernel.

MrHorizontal

Hrm. I guessed it'd be a FreeBSD issue, but messing with drivers is way above my head. For the record here are a few more logs through various stages of the process:

On plug in:

log messages + broadcast:

kernel: ugen0.3: <vendor 0x0bda=""> at usbus0
kernel: urtw0: <vendor 0="" 3="" 0x0bda="" product="" 0x8187,="" class="" 0,="" rev="" 2.00="" 1.00,="" addr=""> on usbus0
kernel: urtw0: unknown RTL8187L type: 0x8000000
kernel: urtw0: rtl8187l rf rtl8225u hwrev none</vendor></vendor>

(also when I rebooted with the device still in, the dmesg also showed the same, fyi)

ifconfig:

urtw0: flags=8802 <broadcast,simplex,multicast>metric 0 mtu 2290
	ether 00:c0:ca:39:ad:fe
	media: IEEE 802.11 Wireless Ethernet autoselect (autoselect)
	status: no carrier</broadcast,simplex,multicast>

On assign interface:

php: /interfaces_assign.php: Creating rrd update script
check_reload_status: reloading filter

urtw0: flags=8802 <broadcast,simplex,multicast>metric 0 mtu 2290
	ether 00:c0:ca:39:ad:fe
	media: IEEE 802.11 Wireless Ethernet autoselect (autoselect)
	status: no carrier</broadcast,simplex,multicast>

On enable interface and Save (changes NOT applied).

This is configuring the interface for DHCP, 802.11g, the Infrastructure (BSS) mode, my SSID and WPA2 shared key - the basic minimum essentially needed to bring up the interface - all other options are default.

php: /interfaces.php: Cloning new wireless interface urtw0_wlan0
kernel: wlan0: changing name to 'urtw0_wlan0'

So the auto-clone thing is indeed happening…

urtw0: flags=8802 <broadcast,simplex,multicast>metric 0 mtu 2290
	ether 00:c0:ca:39:ad:fe
	media: IEEE 802.11 Wireless Ethernet autoselect (autoselect)
	status: no carrier
urtw0_wlan0: flags=8802 <broadcast,simplex,multicast>metric 0 mtu 1500
	ether 00:c0:ca:39:ad:fe
	media: IEEE 802.11 Wireless Ethernet autoselect (autoselect)
	status: no carrier
	ssid "" channel 1 (2412 MHz 11b)
	country US authmode OPEN privacy OFF txpower 0 bmiss 7 scanvalid 60
	bgscan bgscanintvl 300 bgscanidle 250 roam:rssi 7 roam:rate 1
	bintval 0</broadcast,simplex,multicast></broadcast,simplex,multicast>

And finally, when applied:

php: /interfaces.php: The command '/sbin/ifconfig 'urtw0_wlan1' 'indoor'' returned exit code '1', the output was 'ifconfig: country US (United States) is not usable with regdomain 0'
php: /interfaces.php: The command '/sbin/dhclient -c /var/etc/dhclient_opt9.conf urtw0_wlan1 > /tmp/urtw0_wlan1_output > /tmp/urtw0_wlan1_error_output' returned exit code '1', the output was ''

urtw0: flags=8843 <up,broadcast,running,simplex,multicast>metric 0 mtu 2290
	ether 00:c0:ca:39:ad:fe
	media: IEEE 802.11 Wireless Ethernet autoselect mode 11g
	status: associated
urtw0_wlan1: flags=8843 <up,broadcast,running,simplex,multicast>metric 0 mtu 1500
	ether 00:c0:ca:39:ad:fe
	inet6 fe80::2c0:caff:fe39:adfe%urtw0_wlan1 prefixlen 64 scopeid 0x8 
	nd6 options=3 <performnud,accept_rtadv>media: IEEE 802.11 Wireless Ethernet autoselect mode 11g
	status: no carrier
	ssid XXX channel 10 (2457 MHz 11g)
	country US authmode WPA1+WPA2/802.11i privacy ON deftxkey UNDEF
	txpower 0 bmiss 7 scanvalid 450 bgscan bgscanintvl 300 bgscanidle 250
	roam:rssi 7 roam:rate 5 protmode OFF roaming MANUAL</performnud,accept_rtadv></up,broadcast,running,simplex,multicast></up,broadcast,running,simplex,multicast>

That last log message made me fiddle around with the regdomains, but regardless of which country (FCC / ETSI / DEBUG / NONE) and regulatory domain I set, there was no success.

It could also be something to do with the VMWare USB Host driver as well… when ermal fixes the ftp proxy, I'll see what happens on an ALIX 2D3, but I won't get my hopes up... :(

Efonnes

The code for applying the regulatory domain, country code, and the indoor/outdoor/anywhere settings does it in a separate ifconfig command than the one that applies the rest of the settings, so it is likely not the cause.

If you want to be sure, you could try setting the country code and setting the regulatory domain to the same one mentioned with the country (though actually, changing regulatory domain and leaving country default should work, too), which should allow it to apply the other setting without an error, or I could try adding an additional default setting that changes nothing on the one with the indoor/outdoor/anywhere options.

The "status: no carrier" line means that either it is just not connecting or there is some other failure. I've seen at least a couple cases where this can happen on hardware that is known to work. First of all, post the output of ps -A | grep _wlan

MrHorizontal

I've done a little bit more research on the urtw driver.

Judging from the man page here versus the man page here showing supported cards, there might be 2 different versions of the driver. Given that pfSense has a dmesg saying:

urtw0: <vendor 0="" 2="" 0x0bda="" product="" 0x8187,="" class="" 0,="" rev="" 2.00="" 1.00,="" addr="">on usbus0
urtw0: unknown RTL8187L type: 0x8000000
urtw0: rtl8187l rf rtl8225u hwrev none</vendor>

which as you can see says 'unknown' vendor, it might just be a case of version conflict with the driver being used.

The guys at OpenBSD seem to have dealt with the issue of the Alfa AWUS036H and urtw as can be seen in the changelogs here. There's also a fair bit of decent discussion on it here too.

@Efonne:

# ps -A | grep _wlan
 5107  ??  Ss     0:00.02 /usr/sbin/wpa_supplicant -B -i urtw0_wlan1 -c /var/etc/wpa_supplicant_urtw0_wlan1.conf
# cat /var/etc/wpa_supplicant_urtw0_wlan1.conf
ctrl_interface=/var/run/wpa_supplicant
ctrl_interface_group=0
ap_scan=1
#fast_reauth=1
network={
ssid="XXX"
scan_ssid=1
priority=5
key_mgmt=WPA-PSK
psk="XXXXXXXXXXXXXXXX"
pairwise=CCMP TKIP
group=CCMP TKIP
}

Efonnes

Why do you have a urtw0_wlan1 now instead of urtw0_wlan0? I suppose as long as you don't also have a urtw0_wlan0 then it is fine, though. However, if you have both then there could potentially be issues.

MrHorizontal

I don't think it's a problem. _wlan0 was defined automatically when pfSense tried to join my WLAN. _wlan1 was defined when I added the clone in the Interfaces / assign page. If not, it could also be because unplugged and replugged the device in.

Efonnes

As long as ifconfig does not show both, I suppose it should be fine. If it did have both, it could potentially be a problem, since that driver probably does not support having a second virtual interface. It probably wouldn't allow it anyway, though.

This reminded me that it might be useful to make it so the wlan0 interface is removed when the base interface is unassigned, freeing it up for explicitly creating the virtual interface on the wireless tab if someone wants to do it that way, but if they haven't rebooted the system after unassigning the base interface. I might look into that.

That tab was actually intended more for the cards that have drivers supporting multiple access points per card. Also for those that support having a clone in infrastructure mode and another in access point mode at the same time (though I haven't had any luck with getting that actually working well yet).

MrHorizontal

Tested this on the ALIX instead of VMWare… and it works.

Seems it's something to do with the Virtual USB device of VMWare Server...