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.
After some more testing I can confirm the card going mute even after
changing mac address, attaching debug=4 kernel log; only
unplugging/replugging brings it back alive.
2012/12/10 Alessandro Lannocca <[email protected]>:
> You are completely right, and I feel a little bit idiot =), by the
> way, I enabled the debug option and now I'm attaching dmesg &
> debug.log and 2 pcap captures aswell, one with an handshake (from the
> alfa card) and one without; I was able to connect 2 times in a row
> (hitting the button really quick), after 2nd disconnection, I was
> unable to reconnect.
>
> In the pcap files, my other 2 clients (phone & tablet) are completely invisible.
>
> Attached debug=4 logs, zipped to save bandwidth
P.S. I also tested a clean tree (no patches) with the same results.
2012/12/10 Alessandro Lannocca <[email protected]>:
> Thank you Larry for your suggestion, however I can't get any debug log
> out of my machine, it's probably an ubuntu fault (or I'm missing
> something); I even tried switching from rsyslogd to sysklogd and all
> debug=[1...5] combintations, all to no avail.
>
> This is my actual <modprobe -v rtl8192cu debug=4> output:
>
> <snip>
> insmod /lib/modules/3.5.0-19-generic/updates/net/wireless/cfg80211.ko
> insmod /lib/modules/3.5.0-19-generic/updates/net/mac80211/mac80211.ko
> insmod /lib/modules/3.5.0-19-generic/updates/drivers/net/wireless/rtlwifi/rtlwifi.ko
> insmod /lib/modules/3.5.0-19-generic/updates/drivers/net/wireless/rtlwifi/rtl8192c/rtl8192c-common.ko
> insmod /lib/modules/3.5.0-19-generic/updates/drivers/net/wireless/rtlwifi/rtl8192cu/rtl8192cu.ko
> debug=4
> </snip>
>
> Attached you can find dmesg i grepped from my (now virtualized) test
> system. kern.log/syslog don't offer any more info.
>
> After some more testing this is the situation:
>
> - Card goes mute some seconds after a succesfull disconnection
> (interval between disconnection and muting seems random, some seconds
> however)
> - Card doesn't correctly see associated clients in monitor mode (wpa
> networks, don't know if this applies to wep aswell), it corretly sees
> itself associated and only get its own 4-way wpa handshake, not
> others.
> - Led is fixed all the time, it should blink during rx/tx
> - regd.c has only a bunch of countries coded, if I set my regdom to IT
> I can't get chans 12-13 to work, while if I set it to EC (Italy is an
> ETSI member) I get proper channel list.
> - maximum txpower is hardcorded to 20dBm in regd.c, it isn't possible
> to modify it accordingly to regdom.
>
> As a side note, commit 4f03c1ed8901a01ad4abcef95c02c007a2d481c2 is
> giving some headaches in monitor mode, due to the fact that it renders
> impossible to switch channels while a mon* and a wlan* interface
> coexist (however this is not a bug, just my 2 cents)
>
> If you're willing to tell me which distribution/version combo you're
> using I would be very happy to virtualize it and get some useful debug
> info out of it, also I'm currently targeting compat-wireless 3.6.8-1;
> although these issues remains in daily snapshots until at least last
> week, feel free to tell me which version should I be targeting.
>
> Thank you all for your time .
>
> Alex
>
> 2012/12/10 Larry Finger <[email protected]>:
>
>> 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
>>
Thank you Larry for your suggestion, however I can't get any debug log
out of my machine, it's probably an ubuntu fault (or I'm missing
something); I even tried switching from rsyslogd to sysklogd and all
debug=[1...5] combintations, all to no avail.
This is my actual <modprobe -v rtl8192cu debug=4> output:
<snip>
insmod /lib/modules/3.5.0-19-generic/updates/net/wireless/cfg80211.ko
insmod /lib/modules/3.5.0-19-generic/updates/net/mac80211/mac80211.ko
insmod /lib/modules/3.5.0-19-generic/updates/drivers/net/wireless/rtlwifi/rtlwifi.ko
insmod /lib/modules/3.5.0-19-generic/updates/drivers/net/wireless/rtlwifi/rtl8192c/rtl8192c-common.ko
insmod /lib/modules/3.5.0-19-generic/updates/drivers/net/wireless/rtlwifi/rtl8192cu/rtl8192cu.ko
debug=4
</snip>
Attached you can find dmesg i grepped from my (now virtualized) test
system. kern.log/syslog don't offer any more info.
After some more testing this is the situation:
- Card goes mute some seconds after a succesfull disconnection
(interval between disconnection and muting seems random, some seconds
however)
- Card doesn't correctly see associated clients in monitor mode (wpa
networks, don't know if this applies to wep aswell), it corretly sees
itself associated and only get its own 4-way wpa handshake, not
others.
- Led is fixed all the time, it should blink during rx/tx
- regd.c has only a bunch of countries coded, if I set my regdom to IT
I can't get chans 12-13 to work, while if I set it to EC (Italy is an
ETSI member) I get proper channel list.
- maximum txpower is hardcorded to 20dBm in regd.c, it isn't possible
to modify it accordingly to regdom.
As a side note, commit 4f03c1ed8901a01ad4abcef95c02c007a2d481c2 is
giving some headaches in monitor mode, due to the fact that it renders
impossible to switch channels while a mon* and a wlan* interface
coexist (however this is not a bug, just my 2 cents)
If you're willing to tell me which distribution/version combo you're
using I would be very happy to virtualize it and get some useful debug
info out of it, also I'm currently targeting compat-wireless 3.6.8-1;
although these issues remains in daily snapshots until at least last
week, feel free to tell me which version should I be targeting.
Thank you all for your time .
Alex
2012/12/10 Larry Finger <[email protected]>:
> 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
>
On 12/10/2012 03:06 PM, Alessandro Lannocca wrote:
> P.S. I also tested a clean tree (no patches) with the same results.
Please post the output of 'modinfo rtl8172cu | grep -v alias'
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
You are completely right, and I feel a little bit idiot =), by the
way, I enabled the debug option and now I'm attaching dmesg &
debug.log and 2 pcap captures aswell, one with an handshake (from the
alfa card) and one without; I was able to connect 2 times in a row
(hitting the button really quick), after 2nd disconnection, I was
unable to reconnect.
In the pcap files, my other 2 clients (phone & tablet) are completely invisible.
Attached debug=4 logs, zipped to save bandwidth
On 12/10/2012 03:16 PM, Alessandro Lannocca wrote:
> 2012/12/10 Larry Finger <[email protected]>:
>> modinfo rtl8172cu | grep -v alias
>
> Here you are:
>
> <snip>
>
> filename:
> /lib/modules/3.5.0-19-generic/updates/drivers/net/wireless/rtlwifi/rtl8192cu/rtl8192cu.ko
> firmware: rtlwifi/rtl8192cufw.bin
> description: Realtek 8192C/8188C 802.11n USB wireless
> license: GPL
> author: Larry Finger <[email protected]>
> author: Ziv Huang <[email protected]>
> author: Georgia <[email protected]>
> srcversion: DB3CA4D8CA86F098980FA95
> depends: rtlwifi,mac80211,rtl8192c-common,compat
> vermagic: 3.5.0-19-generic SMP mod_unload modversions 686
> parm: swenc:Set to 1 for software crypto (default 0)
> (bool)
> parm: debug:Set debug level (0-5) (default 0) (int)
Your configuration probably does not include "CONFIG_RTLWIFI_DEBUG=y". Without
that parameter being set, *ALL* the debug statements compile away.
Larry
2012/12/10 Larry Finger <[email protected]>:
> modinfo rtl8172cu | grep -v alias
Here you are:
<snip>
filename:
/lib/modules/3.5.0-19-generic/updates/drivers/net/wireless/rtlwifi/rtl8192cu/rtl8192cu.ko
firmware: rtlwifi/rtl8192cufw.bin
description: Realtek 8192C/8188C 802.11n USB wireless
license: GPL
author: Larry Finger <[email protected]>
author: Ziv Huang <[email protected]>
author: Georgia <[email protected]>
srcversion: DB3CA4D8CA86F098980FA95
depends: rtlwifi,mac80211,rtl8192c-common,compat
vermagic: 3.5.0-19-generic SMP mod_unload modversions 686
parm: swenc:Set to 1 for software crypto (default 0)
(bool)
parm: debug:Set debug level (0-5) (default 0) (int)
</snip>