On 09/09/13 15:57, Larry Finger wrote:
I think your user space is exactly the problem. As I am writing this, my
device, which lsusb reports as "ID 7392:7811 Edimax Technology Co., Ltd
EW-7811Un 802.11n Wireless Adapter [Realtek RTL8188CUS]" has been up for
a little over 20 hours. During that time, there have been 23
deauthentications for reason 7, but 0 of the "connection to AP lost"
variety.
I've just tried building wpa_supplicant 2.0 from source and it sadly
doesn't make any difference here.
I do still however see the following in dmesg output:
rtlwifi:rtl_watchdog_wq_callback():<0-0> AP off, try to reconnect now
Briefly looking through the code in rtlwifi/base.c I see that the
watchdog message above is triggered by the condition
(rtlpriv->link_info.bcn_rx_inperiod +
rtlpriv->link_info.num_rx_inperiod) == 0).
The bcn_rx_inperiod value is only incremented by rtl_beacon_statistic()
in base.c, which is in turn called from _rtl_usb_rx_process_noagg() (but
not _rtl_usb_rx_process_agg() for some reason?). Shall I try adding some
debugging printk() statements in there to get a feel for what is going
on? Or would it be better to attempt a trace with debug=0x5?
My system is running version 1.1 of wpa_supplicant, 0.9.6.4 of
NetworkManager, and 0.9.0.7 of the KDE applet.
None of my wireless connections are made automatically. When I select a
particular AP from the KDE applet, it is roughly 2 seconds until the
interface has gotten an IP and reports its state as connected.
I will switch my system from NM to manual control to see what happens.
Interesting. Did it make any difference in the end?
ATB,
Mark.
--
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
