Message ID | CAMfPB_wtsXjxFkY6M4cNjxDK678DV4VPjwDRzVOtgrf-4jDL-Q@mail.gmail.com (mailing list archive) |
---|---|
State | Not Applicable, archived |
Headers | show |
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@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
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 <Larry.Finger@lwfinger.net>: > 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 >
P.S. I also tested a clean tree (no patches) with the same results. 2012/12/10 Alessandro Lannocca <alessandro.lannocca@gmail.com>: > 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 <Larry.Finger@lwfinger.net>: > >> 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@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
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'
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
2012/12/10 Larry Finger <Larry.Finger@lwfinger.net>:
> 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 <Larry.Finger@lwfinger.net>
author: Ziv Huang <ziv_huang@realtek.com>
author: Georgia <georgia@realtek.com>
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>
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
On 12/10/2012 03:16 PM, Alessandro Lannocca wrote: > 2012/12/10 Larry Finger <Larry.Finger@lwfinger.net>: >> 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 <Larry.Finger@lwfinger.net> > author: Ziv Huang <ziv_huang@realtek.com> > author: Georgia <georgia@realtek.com> > 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 -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
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
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 <alessandro.lannocca@gmail.com>: > 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
--- 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)