Hi everyone,
I'm having some troubles with my new wireless card and I was told on IRC
to send all the information I have here. As stated in the subject, the
card is an ASUS PCE-N15 which is supposed to contain a RTL8188CE.
Whenever I load the module and try to setup my wifi, there are warnings
in dmesg. I attached those in kernel_warnings.txt. I'm currently using a
kernel from
git://git.kernel.org/pub/scm/linux/kernel/git/linville/wireless-testing.git
at commit 12c18c7a3d8f20366424834b20be40f7f3a9e2c2 (from yesterday).
I also attached the output of lspci and the config file of my kernel.
Please tell me if you need any other debug information,
Best,
Vincent Brillault
Hi again,
I've made more debugging on my system. I joined to this mail the
modification I've made on my checkout of the wireless-testing git (added
a certain number of 'printk') and the output of: module load, interface
start on a gentoo system (association through wpa_supplicant) and module
unload.
The most interesing lines are, in my opinion, l82-84:
get_highest_rix called, rtlmac->opmode = 2, rtlmac->mode = 0
get_highest_rix called, sta not null, mode 4
BAND_ON_2_4G, mode 0, rf_type == RF_2T2R: 15
First, we are in opmode 2, NL80211_IFTYPE_STATION, which seems normal.
At the same time 'sta' is not NULL. From reading this part of the code,
it seems not to be correct with the opmode, as 'sta' is only read if the
opmode is 1, 3 or 7.
Then, as rtlmac->mode is 0, wireless_mode is set to 0, which is
'WIRELESS_MODE_UNKNOWN' and does not really seems to be right. As a
result, 15 is return as the max rate idx, which will directly cause the
overflow warning at line 89 (the max is 12).
I don't know the code well enough to understand why 'sta' is not null
will it contains the correct mode. I'll try to read more code but though
that you might be interested by this.
Thanks in advance,
Vincent Brillault
On 03/08/2013 03:58 PM, Vincent Brillault wrote:
> Hi again,
>
> I forgot to mention that those warning from mac80211 (the associated
> comments in the code are 'RC is busted' or 'uh huh?') seems to somehow
> disable completely the rate control: 'iw wlan0 link' gives 'tx bitrate:'
> with nothing after. Furthermore, I loose the network from time to time
> on reason 7. I went back to kernel 3.8.0: if there is enough traffic
> continuously, the link is stable but I loose it randomly when there is
> no traffic.
>
> I made more debug on the 3.8.0 kernel, the first warning correspond to
> the following test:
> (info->control.rates[i].idx) 15 >= (sband->n_bitrates) 12
>
> Please tell me what test I can make to find the source of this problem.
From what I remember, that problem has been fixed. The correct code should be
in 3.8.2 and in 3.9-rc1.
The firmware in all the cards that use the rtlwifi family of drivers its own
rate control. The drivers do not pay any attention to any rate-setting calls
from user space.
I also see reason 7 disconnects; however, with NetworkManager, the network is
reconnects. If you are using ifup or similar method, it probably does not reconnect.
Larry
On 03/09/2013 05:32 AM, Vincent Brillault wrote:
> Thanks for your email, please find my comments inline
>
> On Fri 8.Mar'13 at 19:53:15 -0600, Larry Finger wrote:
>> The firmware in all the cards that use the rtlwifi family of drivers its own
>> rate control. The drivers do not pay any attention to any rate-setting calls
>> from user space.
> Do you mean that those warnings are only cosmetic and I should not care
> about those ?
You can safely ignore them, but I wonder why I have not seen them. What is the
configuration of your AP? Is it g or n?
>> I also see reason 7 disconnects; however, with NetworkManager, the network is
>> reconnects. If you are using ifup or similar method, it probably does not reconnect.
> It does reconnect, but some higher level daemon (e.g. openvpn) suffer
> from those disconnect/reconnect.
I have been doing tests on rtl8723ae for the past week, and I do not get those
disconnects. Obviously, I need to find what differs between the two drivers in
that respect. I suspect something in the rekeying part of TKIP.
Larry
Hi again,
I forgot to mention that those warning from mac80211 (the associated
comments in the code are 'RC is busted' or 'uh huh?') seems to somehow
disable completely the rate control: 'iw wlan0 link' gives 'tx bitrate:'
with nothing after. Furthermore, I loose the network from time to time
on reason 7. I went back to kernel 3.8.0: if there is enough traffic
continuously, the link is stable but I loose it randomly when there is
no traffic.
I made more debug on the 3.8.0 kernel, the first warning correspond to
the following test:
(info->control.rates[i].idx) 15 >= (sband->n_bitrates) 12
Please tell me what test I can make to find the source of this problem.
Thanks in advance,
Vincent Brillault
On 03/25/2013 02:51 PM, Vincent Brillault wrote:
> Thanks for your quick response, comments inline.
>
> On Mon 25.Mar'13 at 14:11:27 -0500, Larry Finger wrote:
>> I think the difference in our two systems is in the use of NetworkManager and
>> the associated applet. With it, rtl_op_bss_info_changed() does not seem to be
>> called before sta is ready.
>>
>> Attached is a patch that will force mac->mode when sta has not been established.
>> Perhaps that will be enough.
> I does work. I don't have any warning when loading the module and
> establishing the connection. What will happen if the network is not
> really a WIRELESS_MODE_G but a WIRELESS_MODE_B ?
It should not matter, but I will make it B instead of G. Once the connection is
established, then the handshaking with the AP will set sta and the mode to
whatever the AP supports.
>> It not, I will need to set up your distro and run the wireless exactly the way
>> you do to duplicate your results. Please provide the distro name and version,
>> the architecture, the sequence of commands, and the contents of any special
>> scripts you run.
> If you want to duplicate my system, here are those information:
> Distribution: Gentoo Linux (profile hardened/linux/x86)
> Architecture: i686
> Current Kernel: manually installed wireless-testing 3.9.0-rc3+ with your
> patches
>
> I've attached my kernel .config, a emerge --info (contains
> information about my system configuration). It's a stable gentoo system,
> with the following unstables packages:
> '''
> =sys-kernel/linux-firmware-99999999 **
> =net-wireless/wpa_supplicant-2.0 ~x86
> =dev-libs/libnl-3.2.21 ~x86
> '''
>
> wpa_supplicant is using the following USE flags:
> '''
> net-wireless/wpa_supplicant -ssl fasteap wps ap wimax p2p eap-sim
> '''
>
> I did not modified the standard init scripts from Gentoo, my
> configuration of the interface (/etc/conf.d/net) is:
> '''
> config_wlan0="dhcp"
> wpa_supplicant_wlan0="-f /var/log/wpa_supplicant.log -W nl80211 -t"
> '''
>
> The uncommented part of my wpa_supplicant configuration file only
> contains the following:
> '''
> ctrl_interface=/var/run/wpa_supplicant
> eapol_version=1
> ap_scan=1
> fast_reauth=1
> country=FR
> network={
> ssid="${myssid}"
> scan_ssid=1
> proto=WPA RSN
> key_mgmt=WPA-PSK
> pairwise=CCMP
> group=TKIP
> psk=${mypsk}
> }
> '''
>
> In order to have the errors I mention, I run the following:
> (inside a compat-drivers pull, just for unloading the module)
> '''
> /etc/init.d/net.wlan0 stop && make wlunload; dmesg -c > /dev/null;
> modprobe rtl8192ce; /etc/init.d/net.wlan0 start;
> '''
>
>
> I know this is not a standard distribution and that's why, if you have
> any idea of things I can do to help you, please tell me.
I will let you change that G to a B and test some more. If all goes well, then I
will not need to set up that test bed, but at least I have the necessary details
if ever required.
Larry
Thanks for your email, please find my comments inline
On Fri 8.Mar'13 at 19:53:15 -0600, Larry Finger wrote:
> From what I remember, that problem has been fixed. The correct code should be
> in 3.8.2 and in 3.9-rc1.
mmm, it does not seem to be fully fixed. I've re-tested 3.9-rc1+ from
git/linville/wireless-testing.git at
14c8aaa01066072600b13b9825c571e4ecf7c0e9 and I still have those
warnings. I have attached the module initialization/warnings to this
mail, with a small patch I applied on the source to make it more
verbose. (As always I've also attached my kernel configuration)
> The firmware in all the cards that use the rtlwifi family of drivers its own
> rate control. The drivers do not pay any attention to any rate-setting calls
> from user space.
Do you mean that those warnings are only cosmetic and I should not care
about those ?
> I also see reason 7 disconnects; however, with NetworkManager, the network is
> reconnects. If you are using ifup or similar method, it probably does not reconnect.
It does reconnect, but some higher level daemon (e.g. openvpn) suffer
from those disconnect/reconnect.
Again, thanks for you explanations,
Vincent
Thanks for your quick response, comments inline.
On Mon 25.Mar'13 at 14:11:27 -0500, Larry Finger wrote:
> I think the difference in our two systems is in the use of NetworkManager and
> the associated applet. With it, rtl_op_bss_info_changed() does not seem to be
> called before sta is ready.
>
> Attached is a patch that will force mac->mode when sta has not been established.
> Perhaps that will be enough.
I does work. I don't have any warning when loading the module and
establishing the connection. What will happen if the network is not
really a WIRELESS_MODE_G but a WIRELESS_MODE_B ?
> It not, I will need to set up your distro and run the wireless exactly the way
> you do to duplicate your results. Please provide the distro name and version,
> the architecture, the sequence of commands, and the contents of any special
> scripts you run.
If you want to duplicate my system, here are those information:
Distribution: Gentoo Linux (profile hardened/linux/x86)
Architecture: i686
Current Kernel: manually installed wireless-testing 3.9.0-rc3+ with your
patches
I've attached my kernel .config, a emerge --info (contains
information about my system configuration). It's a stable gentoo system,
with the following unstables packages:
'''
=sys-kernel/linux-firmware-99999999 **
=net-wireless/wpa_supplicant-2.0 ~x86
=dev-libs/libnl-3.2.21 ~x86
'''
wpa_supplicant is using the following USE flags:
'''
net-wireless/wpa_supplicant -ssl fasteap wps ap wimax p2p eap-sim
'''
I did not modified the standard init scripts from Gentoo, my
configuration of the interface (/etc/conf.d/net) is:
'''
config_wlan0="dhcp"
wpa_supplicant_wlan0="-f /var/log/wpa_supplicant.log -W nl80211 -t"
'''
The uncommented part of my wpa_supplicant configuration file only
contains the following:
'''
ctrl_interface=/var/run/wpa_supplicant
eapol_version=1
ap_scan=1
fast_reauth=1
country=FR
network={
ssid="${myssid}"
scan_ssid=1
proto=WPA RSN
key_mgmt=WPA-PSK
pairwise=CCMP
group=TKIP
psk=${mypsk}
}
'''
In order to have the errors I mention, I run the following:
(inside a compat-drivers pull, just for unloading the module)
'''
/etc/init.d/net.wlan0 stop && make wlunload; dmesg -c > /dev/null;
modprobe rtl8192ce; /etc/init.d/net.wlan0 start;
'''
I know this is not a standard distribution and that's why, if you have
any idea of things I can do to help you, please tell me.
Sincerely yours,
Vincent Brillault
Hi Larry and everyone else on the list,
I've seen your 25 patches and applied them in hope my problems were
resolved. They are not :'(
I've tried to look further, I think that the root of this problem is in
core.c, in the rtl_op_bss_info_changed function. This function make a
call to get_sta on the new bssid. The problem is that at this point, the
sta is still not inserted, thus cannot be accessed by this method. As
far as I understand the code, this specific rtl_op_bss_info_changed is
responsible for setting rtlmac->mode, which explains why this mode is
never set on my system.
Example of logs (I've added some printk myself):
[ 1468.664159] rtl8192ce: Using firmware rtlwifi/rtl8192cfw.bin
[ 1468.664271] cfg80211: Ignoring regulatory request Set by core since
the driver uses its own custom regulatory domain
[ 1468.664334] ieee80211 phy0: Selected rate control algorithm 'rtl_rc'
[ 1468.664612] rtlwifi: wireless switch is on
[ 1476.203273] rtl_op_add_interface called: opmode 2, addr
30:85:a9:f4:ac:50
[ 1476.213917] IPv6: ADDRCONF(NETDEV_UP): wlan0: link is not ready
[ 1477.330146] wlan0: authenticate with 00:21:1e:4d:57:60
[ 1477.330154] wlan0: Allocated STA 00:21:1e:4d:57:60
[ 1477.349758] rtl_op_bss_info_changed: changed & BSS_CHANGED_BSSID:
calling get_sta on 0:21:1e:4d:57:60
[ 1477.349758] Sta not found !
[ 1477.349758] wlan0: Inserted STA 00:21:1e:4d:57:60
[ 1477.349758] wlan0: send auth to 00:21:1e:4d:57:60 (try 1/3)
[ 1477.353936] wlan0: authenticated
[ 1477.353942] wlan0: moving STA 00:21:1e:4d:57:60 to state 2
[ 1477.353963] rtl8192ce 0000:03:00.0 wlan0: disabling HT as WMM/QoS is
not supported by the AP
[ 1477.353967] rtl8192ce 0000:03:00.0 wlan0: disabling VHT as WMM/QoS is
not supported by the AP
[ 1477.354903] wlan0: associate with 00:21:1e:4d:57:60 (try 1/3)
[ 1477.360928] wlan0: RX AssocResp from 00:21:1e:4d:57:60 (capab=0x451
status=0 aid=2)
[ 1477.360934] wlan0: moving STA 00:21:1e:4d:57:60 to state 3
[ 1477.360938] rtl_op_sta_add: sta 0:21:1e:4d:57:60
[ 1477.360957] wlan0: moving STA 00:21:1e:4d:57:60 to state 4
[ 1477.360975] wlan0: associated
[ 1477.360983] IPv6: ADDRCONF(NETDEV_CHANGE): wlan0: link becomes ready
[ 1477.363615] get_highest_rix called, rtlmac->opmode = 2, rtlmac->mode
= 0
[ 1477.363619] get_highest_rix called, sta not null, mode 4
[ 1477.363623] ------------[ cut here ]------------
[ 1477.363660] WARNING: at net/mac80211/tx.c:771
ieee80211_tx_h_rate_ctrl+0x3a4/0x48a [mac80211]()
[ 1477.363663] Hardware name: To Be Filled By O.E.M.
The problem seems to be at 1477.349758.
My system is using the latest wireless-testing version, plus your 25
patches. For the authentication, net-wireless/wpa_supplicant-2.0 with
libnl-3.2.21 is used.
Please contact me of you need any more debug information or if you need
me to run other tests.
Sincerely yours,
Vincent Brillault
Hi,
I've achieved to capture more data. I've attached the result of a 'tail'
on both kernel logs and wpa_supplicant logs. The problem seems to be
related to those warnings on replay counters:
'wlan0: WPA: EAPOL-Key Replay Counter did not increase - dropping
packet'
Best,
Vincent
On 03/25/2013 01:29 PM, Vincent Brillault wrote:
> Hi Larry and everyone else on the list,
>
> I've seen your 25 patches and applied them in hope my problems were
> resolved. They are not :'(
>
> I've tried to look further, I think that the root of this problem is in
> core.c, in the rtl_op_bss_info_changed function. This function make a
> call to get_sta on the new bssid. The problem is that at this point, the
> sta is still not inserted, thus cannot be accessed by this method. As
> far as I understand the code, this specific rtl_op_bss_info_changed is
> responsible for setting rtlmac->mode, which explains why this mode is
> never set on my system.
I think the difference in our two systems is in the use of NetworkManager and
the associated applet. With it, rtl_op_bss_info_changed() does not seem to be
called before sta is ready.
Attached is a patch that will force mac->mode when sta has not been established.
Perhaps that will be enough.
It not, I will need to set up your distro and run the wireless exactly the way
you do to duplicate your results. Please provide the distro name and version,
the architecture, the sequence of commands, and the contents of any special
scripts you run.
Larry
Sorry for the delay.
On Sat 9.Mar'13 at 12:24:24 -0600, Larry Finger wrote:
> On 03/09/2013 05:32 AM, Vincent Brillault wrote:
> You can safely ignore them, but I wonder why I have not seen them. What is the
> configuration of your AP? Is it g or n?
It's a b/g AP.
> I have been doing tests on rtl8723ae for the past week, and I do not get those
> disconnects. Obviously, I need to find what differs between the two drivers in
> that respect. I suspect something in the rekeying part of TKIP.
I confirm that I'm using TKIP on that network.
If I can help you in any way, please tell me,
Vincent
On Tue 9.Apr'13 at 10:32:33 -0500, Larry Finger wrote:
> On 04/09/2013 04:47 AM, Vincent Brillault wrote:
> > I still have the deconnection/reconnection issue. After looking on the
> > reason, I think I have found a bug. Please look at the patched included
> > in this mail: I think the rtlpriv->link_info.num_rx_inperiod is set to 0
> > too early, as the '/* <4> roaming */' part uses it to see if the AP is
> > still alive. What do you think ?
>
> Does that change help your issue?
I cannot say for sure that it helped. I have now disactivated the
powersave features of the driver and all my problems disappeared.
The only thing I can say for sure is that my deconnections were detected
by this part of the code, as the error message was
"rtlwifi:rtl_watchdog_wq_callback():<0-0> AP off, try to reconnect now",
and that this bugs seems to increase the probability to take the 'wrong'
branch.
Anyway, I think this line is missplaced: why would lines 1433-1434 use
rtlpriv->link_info.num_rx_inperiod if its value is always 0 ?
Vincent
Hi again :)
On Mon 25.Mar'13 at 15:05:35 -0500, Larry Finger wrote:
> I will let you change that G to a B and test some more. If all goes well, then I
> will not need to set up that test bed, but at least I have the necessary details
> if ever required.
I changed it from G to B. Now the rate (in iwconfig) is fixed to 11
Mb/s, but that's not a problem as you said it's not the real rate. I
didn't see any warning on module loading since that modification :)
I still have the deconnection/reconnection issue. After looking on the
reason, I think I have found a bug. Please look at the patched included
in this mail: I think the rtlpriv->link_info.num_rx_inperiod is set to 0
too early, as the '/* <4> roaming */' part uses it to see if the AP is
still alive. What do you think ?
Best,
Vincent
On 04/09/2013 11:04 AM, Vincent Brillault wrote:
> On Tue 9.Apr'13 at 10:32:33 -0500, Larry Finger wrote:
>> On 04/09/2013 04:47 AM, Vincent Brillault wrote:
>>> I still have the deconnection/reconnection issue. After looking on the
>>> reason, I think I have found a bug. Please look at the patched included
>>> in this mail: I think the rtlpriv->link_info.num_rx_inperiod is set to 0
>>> too early, as the '/* <4> roaming */' part uses it to see if the AP is
>>> still alive. What do you think ?
>>
>> Does that change help your issue?
> I cannot say for sure that it helped. I have now disactivated the
> powersave features of the driver and all my problems disappeared.
> The only thing I can say for sure is that my deconnections were detected
> by this part of the code, as the error message was
> "rtlwifi:rtl_watchdog_wq_callback():<0-0> AP off, try to reconnect now",
> and that this bugs seems to increase the probability to take the 'wrong'
> branch.
>
> Anyway, I think this line is missplaced: why would lines 1433-1434 use
> rtlpriv->link_info.num_rx_inperiod if its value is always 0 ?
As all of the disconnects disappeared in my system with the latest fixes that
will be in kernel 3.10, I am reluctant to make any changes in the code *unless*
you can prove that they fix a particular issue.
I agree that the code looks strange, but I did not write it.
In any case, it seems that power save is your problem.
Larry
On 04/09/2013 04:47 AM, Vincent Brillault wrote:
> Hi again :)
>
> On Mon 25.Mar'13 at 15:05:35 -0500, Larry Finger wrote:
>> I will let you change that G to a B and test some more. If all goes well, then I
>> will not need to set up that test bed, but at least I have the necessary details
>> if ever required.
>
> I changed it from G to B. Now the rate (in iwconfig) is fixed to 11
> Mb/s, but that's not a problem as you said it's not the real rate. I
> didn't see any warning on module loading since that modification :)
>
> I still have the deconnection/reconnection issue. After looking on the
> reason, I think I have found a bug. Please look at the patched included
> in this mail: I think the rtlpriv->link_info.num_rx_inperiod is set to 0
> too early, as the '/* <4> roaming */' part uses it to see if the AP is
> still alive. What do you think ?
Does that change help your issue?
Larry