On 12/09/2012 06:34 PM, Alessandro Lannocca wrote:
Good morning, I recently (yesterday) bought an RTL8188RU-based wifi
card, the Alfa AWUS036NHR <0bda:817f>, and proceeded to compile
compat-wireless 3.6.8-1 to have it working.
I'm using this card for penetration testing purposes, so I applied
this this patch to be able to switch channels in monitor mode and to
prevent the driver from overwriting QoS headers:
<snip>
--- a/net/mac80211/tx.c Sat Sep 29 20:29:54 2012 -0400
+++ b/net/mac80211/tx.c Sat Sep 29 20:37:29 2012 -0400
@@ -1487,7 +1487,10 @@
/* Older kernels do not have the select_queue callback */
skb_set_queue_mapping(skb, ieee80211_select_queue(sdata, skb));
#endif
- ieee80211_set_qos_hdr(sdata, skb);
+ // Don't overwrite QoS header in monitor mode
+ if (likely(info->control.vif->
type != NL80211_IFTYPE_MONITOR)) {
+ ieee80211_set_qos_hdr(sdata, skb);
+ }
ieee80211_tx(sdata, skb, false);
rcu_read_unlock();
}
diff -r 0de05c2ae1be net/wireless/chan.c
--- a/net/wireless/chan.c Sat Sep 29 20:29:54 2012 -0400
+++ b/net/wireless/chan.c Sat Sep 29 20:37:29 2012 -0400
@@ -85,8 +85,8 @@
if (!rdev->ops->set_monitor_channel)
return -EOPNOTSUPP;
- if (!cfg80211_has_monitors_only(rdev))
- return -EBUSY;
+ //if (!cfg80211_has_monitors_only(rdev))
+ // return -EBUSY;
chan = rdev_freq_to_chan(rdev, freq, chantype);
if (!chan)
</snip>
Now, it works almost perfectly, I can use my card for regular surfing
with all kinds of AP (WEP/WPA/OPN), monitor mode works and injection
too; however, when in monitor mode, it detects associated WPA clients
as non-associated (exept for itself, it detects its own association
and its own generated wpa-handshake), and I'm unable to get any WPA
handshake.
Also, after the first succesfull connection and disconnection, the
card goes 'mute', it just stops responding, scanning etc, until
unplugged and replugged.
For this purpose I'm using the latest aircrack-ng suite, other
equipment I have, correctly reports all the clients in my own wireless
network as being associated, but not this rtl8188ru card; I think some
unicast frames are being filtered out while in monitor mode.
It's worth noting that injection works and I'm currently able to
effectively deauth wpa clients, but the card doesn't pick up their
(re-)association nor the wpa handshake.
I tried also compat-wireless from linux-next and compat-drivers
aswell; all exhibit this behaviour, unfortunately compat-drivers
exposes some other bugs.
I'm willing to patch/test/recompile to get this bugs ironed out,
unfortunately loading rtl8192cu with "options debug=5" doesn't seem to
have any effect on my logs, however I'm attaching a .pcap capture and
I'm willing to follow your instructions to get you useful info from my
system.
Also, this bug/problem seems to be a regression, beacuse using an
ancient 2.6.34 kernel with compat-wireless-backport.2.6.39-1 the
problem doesn't exist, all works perfectly.
In the attached .pcap file, you'll find a 2-3 APs, including my own,
and 2-3 clients (all connected on my network - CCC), the only
associated client shown is the alfa card itself, the handshake has
been captured aswell, but the other clients (my phone and my tablet)
are show not-associated, when in reality they are
connected/reconnecting and their 4-way handshake shoud be visible
aswell; this is kinda weird.
My system is Ubuntu 12.10
kernel 3.5.0-19
compat-wireless 3.6.8-1
Alfa AWUS036NHR device id 0bda:817f
dmesg output (I know it's probably useless, but it's all it gives me)
<snip>
Dec 6 15:43:26 rothor kernel: [ 1562.960110] rtl8192cu: Chip version 0x10
Dec 6 15:43:26 rothor kernel: [ 1563.036520] rtl8192cu: MAC address:
00:c0:ca:6a:e2:38
Dec 6 15:43:26 rothor kernel: [ 1563.036523] rtl8192cu: Board Type 1
Dec 6 15:43:26 rothor kernel: [ 1563.036822] rtl8192cu: Loading
firmware rtlwifi/rtl8192cufw.bin
Dec 6 15:43:26 rothor kernel: [ 1563.036901] usbcore: registered new
interface driver rtl8192cu
Dec 6 15:43:35 rothor kernel: [ 1571.216096] rtl8192cu: MAC auto ON okay!
Dec 6 15:43:35 rothor kernel: [ 1571.248809] rtl8192cu: Tx queue select: 0x05
</snip>
Any help being appreciated, thank you in advance for your time.
Are you sure your patches are correct? The location that you used affects
*every* driver that uses mac80211, not just rtl8192cu.
I just tested by having rtl8192cu unloaded, then I loaded it with 'sudo modprobe
-v rtl8192cu debug=5'. When I did that and plugged in the device, my log was
immediately "flooded" with the following:
[ 3269.706508] rtl8192cu: Chip version 0x10
[ 3270.130396] rtl8192cu: MAC address: 00:1f:1f:c8:8e:cb
[ 3270.130423] rtl8192cu: Board Type 0
[ 3270.131246] rtlwifi: rx_max_size 15360, rx_urb_num 8, in_ep 1
[ 3270.131827] rtl8192cu: Loading firmware rtlwifi/rtl8192cufw.bin
[ 3270.132914] rtlwifi:rtl_fw_cb():<0-0> Firmware callback routine entered!
[ 3270.137746] ieee80211 phy2: Selected rate control algorithm 'rtl_rc'
[ 3270.150347] rtl8192cu:rtl92cu_gpio_radio_on_off_checking():<0-0> GPIO_IN=0b
[ 3270.150366] rtl8192cu:rtl92cu_gpio_radio_on_off_checking():<0-0> N-SS RF =0
[ 3270.150373] rtl8192cu:rtl92cu_gpio_radio_on_off_checking():<0-0>
pHalData->bHwRadioOff and eRfPowerStateToSet do not match: pHalData->bHwRadioOff
0, eRfPowerStateToSet 0
[ 3270.150379] rtlwifi: wireless switch is on
[ 3270.150977] rtl8192cu:rtl92cu_gpio_radio_on_off_checking():<0-0> GPIO_IN=0b
[ 3270.150984] rtl8192cu:rtl92cu_gpio_radio_on_off_checking():<0-0> N-SS RF =0
[ 3270.150990] rtl8192cu:rtl92cu_gpio_radio_on_off_checking():<0-0>
pHalData->bHwRadioOff and eRfPowerStateToSet do not match: pHalData->bHwRadioOff
0, eRfPowerStateToSet 0
[ 3270.608096] rtl8192cu:_rtl92cu_init_power_on():<0-0> Autoload Done!
[ 3270.617855] rtl8192cu: MAC auto ON okay!
[ 3270.723379] rtl8192cu: Tx queue select: 0x05
[ 3270.723591] rtl8192cu:rtl92c_set_network_type():<0-0> Set Network type to NO
LINK!
[ 3270.726441] rtl8192c_common:rtl92c_phy_set_bw_mode():<0-0> FALSE driver sleep
or unload
[ 3270.727029] rtl8192c_common:rtl92c_download_fw():<0-0> Firmware Version(63),
Signature(0x88c1),Size(32)
[ 3270.727251] rtl8192c_common:_rtl92c_write_fw():<0-0> FW size is 15982 bytes
[ 3270.745940] rtl8192c_common:_rtl92c_fw_free_to_go():<0-0> Checksum report OK
! REG_MCUFWDL:0x00030004
[ 3270.751440] rtl8192c_common:_rtl92c_fw_free_to_go():<0-0> Polling FW ready
success!! REG_MCUFWDL:0x000300c6
[ 3270.751443] rtl8192c_common:rtl92c_download_fw():<0-0> Firmware is ready to run!
[ 3270.751446] rtl8192cu:_rtl92cu_phy_config_mac_with_headerfile():<0-0> Read
Rtl819XMACPHY_Array
[ 3270.751448] rtl8192cu:_rtl92cu_phy_config_mac_with_headerfile():<0-0>
Img:RTL8192CEMAC_2T_ARRAY
[ 3270.757884] rtl8192c_common:_rtl92c_phy_bb8192c_config_parafile():<0-0> ==>
[ 3270.757889] rtl8192c_common:rtl92c_phy_set_bb_reg():<0-0> regaddr(0x24),
bitmask(0xffffffff), data(0x11800f)
[ 3270.757968] rtl8192c_common:rtl92c_phy_set_bb_reg():<0-0> regaddr(0x24),
bitmask(0xffffffff), data(0x11800f)
As you can see, that is about 1 second worth of logging. I suggest that you use
"debug=4" to start with. It is a lot less like "drinking from a firehose".
Larry
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
