Connection to a WPA2 Enterprise network drops intermittently

[yzhernand]

Referencing a comment I made on an earlier thread: my RTL8723AU card in my Lenovo Yoga experiences intermittent network communication when connected to a WPA2 Enterprise network. Every minute or so, network traffic stops for around 10-15 seconds, while Network Manager shows the connection still active. The network in question uses PEAP for authentication with MSCHAPv2 for inner auth.

The laptop is running Kubuntu 12.10 64-bit Linux Kernel 3.8.8 (although this happens with the stock 3.5.0 kernel as well). The driver was built from source from this repository.

Relevant output from /var/log/syslog:

May 17 08:55:39 uzume kernel: [101877.699012] RTL8723AU: rtw_wx_get_rts, rts_thresh=2347
May 17 08:55:39 uzume kernel: [101877.699015] RTL8723AU: rtw_wx_get_frag, frag_len=2346
May 17 08:55:56 uzume kernel: [101894.688334] RTL8723AU: rtw_wx_get_rts, rts_thresh=2347
May 17 08:55:56 uzume kernel: [101894.688338] RTL8723AU: rtw_wx_get_frag, frag_len=2346
May 17 08:56:05 uzume kernel: [101903.459854] RTL8723AU: IW_SCAN_THIS_ESSID, ssid=<NETWORK NAME REDACTED>, len=11
May 17 08:56:05 uzume kernel: [101903.966778] RTL8723AU: rtw_sctx_wait timeout
May 17 08:56:06 uzume kernel: [101904.969582] RTL8723AU: rtw_sctx_wait timeout
May 17 08:56:07 uzume kernel: [101905.972381] RTL8723AU: rtw_sctx_wait timeout
May 17 08:56:08 uzume kernel: [101906.475809] RTL8723AU: ERROR issue_nulldata, FAIL!, try_cnt =3, wait_ms =500
May 17 08:56:08 uzume kernel: [101906.476057] RTL8723AU: rtw_ack_tx_done ack_tx not set
May 17 08:56:08 uzume kernel: [101906.484219] RTL8723AU: rtw_ack_tx_done ack_tx not set
May 17 08:56:08 uzume kernel: [101906.484839] RTL8723AU: rtw_ack_tx_done ack_tx not set
May 17 08:56:10 uzume kernel: [101908.361548] RTL8723AU: rtw_sctx_wait timeout
May 17 08:56:11 uzume kernel: [101909.364291] RTL8723AU: rtw_sctx_wait timeout
May 17 08:56:12 uzume kernel: [101910.367108] RTL8723AU: rtw_sctx_wait timeout
May 17 08:56:12 uzume kernel: [101910.690765] RTL8723AU: rtw_wx_get_rts, rts_thresh=2347
May 17 08:56:12 uzume kernel: [101910.690774] RTL8723AU: rtw_wx_get_frag, frag_len=2346
May 17 08:56:12 uzume kernel: [101910.870520] RTL8723AU: ERROR issue_nulldata, FAIL!, try_cnt =3, wait_ms =500
May 17 08:56:12 uzume kernel: [101910.871545] RTL8723AU: survey done event(50)
May 17 08:56:12 uzume kernel: [101910.871758] RTL8723AU: rtw_ack_tx_done ack_tx not set
May 17 08:56:12 uzume kernel: [101910.885057] RTL8723AU: rtw_ack_tx_done ack_tx not set
May 17 08:56:12 uzume kernel: [101910.885555] RTL8723AU: rtw_ack_tx_done ack_tx not set
May 17 08:56:12 uzume kernel: [101910.887114] RTL8723AU: rtw_ack_tx_done ack_tx not set
May 17 08:56:13 uzume kernel: [101912.093033] RTL8723AU: rtw_sctx_wait timeout
May 17 08:56:14 uzume kernel: [101913.095876] RTL8723AU: rtw_sctx_wait timeout
May 17 08:56:15 uzume kernel: [101914.098701] RTL8723AU: rtw_sctx_wait timeout
May 17 08:56:16 uzume kernel: [101914.602034] RTL8723AU: ERROR issue_nulldata, FAIL!, try_cnt =3, wait_ms =500
May 17 08:56:16 uzume kernel: [101914.602241] RTL8723AU: rtw_ack_tx_done ack_tx not set
May 17 08:56:16 uzume kernel: [101914.615063] RTL8723AU: rtw_ack_tx_done ack_tx not set
May 17 08:56:16 uzume kernel: [101914.615681] RTL8723AU: rtw_ack_tx_done ack_tx not set
May 17 08:56:18 uzume kernel: [101916.475844] RTL8723AU: rtw_sctx_wait timeout
May 17 08:56:19 uzume kernel: [101917.478604] RTL8723AU: rtw_sctx_wait timeout
May 17 08:56:20 uzume kernel: [101918.481446] RTL8723AU: rtw_sctx_wait timeout
May 17 08:56:20 uzume kernel: [101918.984868] RTL8723AU: ERROR issue_nulldata, FAIL!, try_cnt =3, wait_ms =500
May 17 08:56:20 uzume kernel: [101918.986141] RTL8723AU: survey done event(34)
May 17 08:56:20 uzume kernel: [101918.986369] RTL8723AU: rtw_ack_tx_done ack_tx not set
May 17 08:56:20 uzume kernel: [101918.999492] RTL8723AU: rtw_ack_tx_done ack_tx not set
May 17 08:56:20 uzume kernel: [101919.002046] RTL8723AU: rtw_ack_tx_done ack_tx not set
May 17 08:56:29 uzume kernel: [101927.688870] RTL8723AU: rtw_wx_get_rts, rts_thresh=2347
May 17 08:56:29 uzume kernel: [101927.688880] RTL8723AU: rtw_wx_get_frag, frag_len=2346

In the example above, it looks like my traffic degraded starting at 08:56:05 and then resumed shortly after 08:56:20.

[tmclaugh]

I have a Yoga as well running Fedora 19 pre-release. Do you have the bluetooth driver loaded and bluetooth enabled? If so then see the following which may help reduce the disconnects. Just having my iPhone going into discovery was causing problems with my WIFI connection.

lwfinger/rtl8723au_bt#2

I'm getting periodic disconnects this morning at my coffee shop but I'm not sure if it's the driver or the shop's WIFI being w0nky. I don't have drops like this at home.

[tmclaugh]

FWIW, here's some complaints about the laptop's WIFI. It may not just be this driver.

• https://forums.lenovo.com/t5/IdeaPad-IdeaTab-Slate-Tablets/yoga-13-wifi-issues/td-p/914595
• http://forums.lenovo.com/t5/IdeaPad-IdeaTab-Slate-Tablets/Yoga-13-WiFi-issues/td-p/947869
• http://forums.lenovo.com/t5/IdeaPad-IdeaTab-Slate-Tablets/Yoga-13-wifi-is-extremely-poor/td-p/960163

[yzhernand]

Thanks for the links. So from the looks of it, most people posting on those threads have no connection (like in issue #2), or lowered reception. I'm getting full bars, but it just cuts out for a few seconds at a time without actually disconnecting (or rather, without Network Manager notifying me of losing connection).

I agree that there's every possibility it's a hardware issue, though. I installed a 2nd SSD in mine and left Windows 8 installed. When I get a chance, I'll test my connection with that to see if it really is a driver issue and post an update.

[yzhernand]

So I've tested this on Windows: I connected to a remote host via SSH, used byobu (screen/tmux frontend with a status bar with a clock) and noticed no slowdown or interruption at all. Usually when I am connected over SSH, I notice what I am typing is no longer showing up on screen, or the clock on the byobu status bar is frozen. When the connection issue is over, it all works again. This time, under Windows, I did not experience this. I'm guessing it must be a driver bug then.

[yzhernand]

@tmclaugh Sorry, I didn't answer your previous question: I do not have Bluetooth enabled, but I do have the driver installed.

I updated and reinstalled the Wi-Fi driver to get the changes that fixed the issue in your report, but I still get these drops, unfortunately. Even after a reboot, and with BT off, same issue.

[tmclaugh]

I just brought my laptop into work with WPA2 Enterprise. I'll have to try it out and see if I get issues.

[pavels]

I hav exactly same problem, here is log

[ 5069.473900] RTL8723AU: rtw_sctx_wait timeout
[ 5070.478419] RTL8723AU: rtw_sctx_wait timeout
[ 5071.482928] RTL8723AU: rtw_sctx_wait timeout
[ 5071.986880] RTL8723AU: ERROR issue_nulldata, FAIL!, try_cnt =3, wait_ms =500
[ 5071.992650] UpdateHalRAMask8192CUsb => mac_id:0, networkType:0x0b, mask:0x000fffff
     ==> rssi_level:3, rate_bitmap:0x000ff015
[ 5071.994266] RTL8723AU: rtw_ack_tx_done ack_tx not set
[ 5072.001533] RTL8723AU: rtw_ack_tx_done ack_tx not set
[ 5072.002166] RTL8723AU: rtw_ack_tx_done ack_tx not set
[ 5073.889133] RTL8723AU: rtw_sctx_wait timeout
[ 5074.098164] RTL8723AU: OnAction_back
[ 5074.098206] RTL8723AU: OnAction_back, action =2
[ 5074.098217] RTL8723AU: OnAction_back(): DELBA: 0(27)
[ 5074.893622] RTL8723AU: rtw_sctx_wait timeout
[ 5075.898190] RTL8723AU: rtw_sctx_wait timeout
[ 5076.402090] RTL8723AU: ERROR issue_nulldata, FAIL!, try_cnt =3, wait_ms =500
[ 5076.403611] RTL8723AU: survey done event(39)
[ 5078.652922] RTL8723AU: rtw_issue_addbareq_cmd, p =0
[ 5078.653018] RTL8723AU: issue_action_BA, category =3, action =0, status =0
[ 5078.653036] RTL8723AU: BA_starting_seqctrl = 1452 for TID =0
[ 5078.655138] RTL8723AU: OnAction_back
[ 5078.655159] RTL8723AU: OnAction_back, action =1
[ 5078.655166] RTL8723AU: agg_enable for TID =0
[ 5078.655716] RTL8723AU: Drop duplicate management frame with seq_num = 1119.

tried on WPA2 (not enterprise), WPA and no encryption at all, always the same result

seems to me that the cause is somewhere rtw_sctx_wait timeout and then ERROR issue_nulldata, FAIL!, try_cnt =3, wait_ms =500

Also, on some forums, that on windows the connection problems is caused by USB power management, tried to play arround with this in linux but that didn't help - maybe i just did it wrong ath that is the way to go, but i don't know

[donpdonp]

I too have a Yoga 13, with Ubuntu 13.03 and the RTL8723AU driver.

It seems pretty clear that the driver does a periodic scan for access points, probably driven by NetworkManager. During these scans wifi traffic stops. So during regular use the network appears to cut out every couple of minutes. I believe its normal for a driver to be able to do a passive-scan but maybe there is a limitation on this hardware? If thats the case, disabling these scans would be best, which is probably a NetworkManager configuration issue.

I simply run dmesg everytime there is a dropout and at the same time as the dropout I see the messages listed in previous comments: "rtw_sctx_wait... survey done event(2e)"

[yzhernand]

@donpdonp I had the same suspicion, but didn't think of it in terms of a hardware limitation. I found this blog post where the author talks about patching NM to disable the periodic scans while connected (it's from 2010, so it may be outdated). But they also point out it being an issue with some drivers not doing background scans, which are supposed to help alleviate the lag seen during a periodic scan.

Anyway I am happy to report that, so far, after installing the latest version of the driver from the last commit, I am no longer seeing noticeable lags. I think the issue should be kept open unless everyone else who has posted here has also seen their problem go away.

[donpdonp]

Wow the whole codebase changed! The driver works as well as before, and no better :(

Leaving a ping running in one window

64 bytes from 4.2.2.2: icmp_req=166 ttl=53 time=25.4 ms
64 bytes from 4.2.2.2: icmp_req=167 ttl=53 time=47.6 ms
64 bytes from 4.2.2.2: icmp_req=168 ttl=53 time=184 ms
64 bytes from 4.2.2.2: icmp_req=169 ttl=53 time=21.9 ms
64 bytes from 4.2.2.2: icmp_req=170 ttl=53 time=22.3 ms
64 bytes from 4.2.2.2: icmp_req=171 ttl=53 time=114 ms
64 bytes from 4.2.2.2: icmp_req=172 ttl=53 time=6698 ms
64 bytes from 4.2.2.2: icmp_req=173 ttl=53 time=5689 ms
64 bytes from 4.2.2.2: icmp_req=174 ttl=53 time=4681 ms
64 bytes from 4.2.2.2: icmp_req=175 ttl=53 time=3673 ms
64 bytes from 4.2.2.2: icmp_req=176 ttl=53 time=2665 ms
64 bytes from 4.2.2.2: icmp_req=177 ttl=53 time=1657 ms
64 bytes from 4.2.2.2: icmp_req=178 ttl=53 time=21.7 ms

The 6 second round trip times are correlated with the dmesg output
[ 440.608699] RTL8723AU: rtw_sctx_wait timeout
[ 441.612901] RTL8723AU: rtw_sctx_wait timeout
[ 442.117265] RTL8723AU: rtw_ack_tx_done ack_tx not set
[ 442.126558] RTL8723AU: rtw_ack_tx_done ack_tx not set
[ 442.127302] RTL8723AU: rtw_ack_tx_done ack_tx not set
[ 444.009347] RTL8723AU: rtw_sctx_wait timeout
[ 445.013556] RTL8723AU: rtw_sctx_wait timeout
[ 446.017749] RTL8723AU: rtw_sctx_wait timeout
[ 446.522581] RTL8723AU: survey done event(35)

Version:
[ 2.135395] RTL8723AU: rtl8723as-vau driver version=v4.1.3_6044.20121224

[yzhernand]

@donpdonp I get a different version:

[    8.155107] RTL8723AU: rtl8723as-vau driver version=v4.1.6_7336.20130426

Maybe you should remove the module first, make clean, make, install and then modprobe the driver again, or reboot.

For convenience for novices, and clarity in general, I meant this:

# cd to the driver source directory
git pull
sudo modprobe -r 8723au
make clean
make
sudo make install
sudo modprobe 8723au

[jeffdoubleyou]

For what it's worth, I have been having this same issue on my Yoga 13 until today.

I made these changes and haven't been having any issues today ( Please note, I have no idea what I'm doing, just messing around with things ):

--- a/core/rtw_mlme_ext.c

@@ -6897,17 +6897,17 @@ void site_survey(_adapter padapter)
/ turn on dynamic functions */
Restore_DM_Func_Flag(padapter);
if (is_client_associated_to_ap(padapter) == true) {

•                           issue_nulldata(padapter, NULL, 0, 3, 500);
  

•                           //issue_nulldata(padapter, NULL, 0, 3, 500);
  

  #ifdef CONFIG_CONCURRENT_MODE

//I wonder, should that line be inside of the ifdef block?

--- a/include/rtw_mlme.h

// Commented by Albert 20101105
// Increase the scanning timeout because of increasing the SURVEY_TO value.

-#define SCANNING_TIMEOUT 8000
+#define SCANNING_TIMEOUT 50

[donpdonp]

I am seriously confused by my setup :(. I have rebooted after building and make install with the new driver.

code is up to date

root@wafer:~# cd /usr/src/wifi/rtl8723au/
root@wafer:/usr/src/wifi/rtl8723au# git pull
Already up-to-date.

latest version 4.1.6

root@wafer:/usr/src/wifi/rtl8723au# cat include/rtw_version.h
#define DRIVERVERSION "v4.1.6_7336.20130426"

module exists in 3.8.0-22 directory

root@wafer:/usr/src/wifi/rtl8723au# locate 8723|grep modules
/lib/modules/3.8.0-22-generic/kernel/drivers/net/wireless/8723au.ko
/lib/modules/3.8.0-22-generic/kernel/drivers/net/wireless/rtlwifi/rtl8723ae
/lib/modules/3.8.0-22-generic/kernel/drivers/net/wireless/rtlwifi/rtl8723ae/rtl8723ae.ko
/lib/modules/3.8.0-22-generic/kernel/drivers/staging/8723au.ko
/usr/src/wifi/rtl8723au/modules.order
root@wafer:/usr/src/wifi/rtl8723au# uname
Linux
root@wafer:/usr/src/wifi/rtl8723au# uname -a
Linux wafer 3.8.0-22-generic #33-Ubuntu SMP Thu May 16 15:17:14 UTC 2013 x86_64 x86_64 x86_64 GNU/Linux
root@wafer:/usr/src/wifi/rtl8723au#

binary module shows 4.1.6

root@wafer:/usr/src/wifi/rtl8723au# strings /lib/modules/3.8.0-22-generic/kernel/drivers/net/wireless/8723au.ko |grep version=
6RTL8723AU: rtl8723as-vau driver version=%s
6RTL8723AU: rtw driver version=%s
version=v4.1.6_7336.20130426

after reboot, dmesg still shows 4.1.3!

root@wafer:/usr/src/wifi/rtl8723au# lsmod|grep 8723
8723au 1050328 0
root@wafer:/usr/src/wifi/rtl8723au# dmesg|grep version=
[ 2.126767] RTL8723AU: rtl8723as-vau driver version=v4.1.3_6044.20121224

The problem will come to me once I've poked around more but right now Im stumped as to where 4.1.3 is coming from.

[jeffdoubleyou]

@donpdonp - You have 3 versions of the module on your system.

I would bet that 4.1.3 is /lib/modules/3.8.0-22-generic/kernel/drivers/net/wireless/8723au.ko

Just do # modinfo 8723au | grep filename

I had the same issue ( but not that location ). Although, after fixing it...I'm still having the same problem unfortunately.

[lwfinger]

OK, the rtl8723ae.ko entries above are for the PCI device and can be ignored.

With any out of kernel driver, you need to be careful about out of date drivers. My version will install in /lib/modules/uname -r/kerneldrivers/net/wireless/, as shown below:

finger@larrylap:/rtl8723au> sudo make install
install -p -m 644 8723au.ko /lib/modules/3.10.0-rc3-wl+/kernel/drivers/net/wireless/
/sbin/depmod -a 3.10.0-rc3-wl+
finger@larrylap:/rtl8723au>

You should delete the 8723au.ko file in ..../staging/.
If you have any other versions, then they are old and should be deleted. You can find them with

find /lib/modules/uname -r -name 8723au.ko

Those are backticks around the "uname -r" part of the command.

@jeffdoubleyou - I don't follow what you are saying about the changes. Please post any changes as a patch file, which will help me understand what you are saying.

[donpdonp]

@jeffdoubleyou thx I removed the driver in /staging as it was 4.1.3.

I had to wait til I was back at work to test the driver under the same circumstances. Driver 4.1.6 seems to be the fix! I've got a ping going, and dmesg shows scan events that do not affect the performance of the ping responses. yea!

[lwfinger]

Good to hear. We are making progress.

[jeffdoubleyou]

I'll rebuild and try again after work today, perhaps I did something wrong. I will report back and let you know if it's solved for me too.

[pavels]

Ok, for me 4.1.6 solved the issue.

[fagzal]

Not solved here. :(

I am running v4.1.6_7336.20130426 on Fedora 19 (kernel 3.10.10-200, also failing with 3.9.5 and 3.9.9-302). This is an Ideapad Yoga 13 i3, and all is well under Win8.

Max. download speed is about 1mbit/s on the local net. Interestingly upload is higher, sometimes goes up to 5mbit/s... but it's all very hectic.

There is a random packet loss (1% ... 25%), and deviation in ping times (1ms ~ 2s!)

When running the module with debug 9, I see a lot of these:
recv_func: validate_recv_frame fail! drop pkt
and
rtw_recv_entry: recv_func return fail!!!

Actually it looks like that the more the traffic the higher the packet loss rate. A simple ping, even a flood ping runs with 0% packet loss. When running speedtest.net in the background, packet loss goes up to 4%.

[lwfinger]

As I don't have one of these devices, I cannot test; however, similar problems with the RTL8188EU were helped by increasing the maximum RX gain. I just committed that same change here. Please test.

[ckuethe]

I see this on my i7 Yoga13 with Xubuntu 13.04 too.

I was going to say "I'll test this at work on monday" but I'm getting compile warnings right now.

CC [M] /home/ckuethe/Development/rtl8723au/os_dep/mlme_linux.o
/home/ckuethe/Development/rtl8723au/os_dep/mlme_linux.c: In function ‘_dynamic_check_timer_handlder’:
/home/ckuethe/Development/rtl8723au/os_dep/mlme_linux.c:102:2: error: implicit declaration of function ‘rtw_dynamic_check_timer_handlder’ [-Werror=implicit-function-declaration]

[ckuethe]

Small typo... "handlder" instead of "handler"

[lwfinger]

I just committed code that will compile OK, or at least it does here.

[ckuethe]

Working pretty well so far.

[yzhernand]

Looks good here too. Thanks for all the hard work!

Sorry; accidentally closed it without waiting for more confirmation.

[fagzal]

Works without a problem after the RX gain change.

However, it might be interesting to note that the issue also went away after a sleep/wake-up cycle in the previous version.

[Linefader]

I am am running Fedora 20 on a Lenovo Yoga 11s (i7-3689Y) and I am still facing the problems described above:
Every few minutes, the network traffic stops (or is slowed down dramatically) for some seconds.

Will it help if I comment out anything in the site_survey function in rtw_mlme_ext.c and recompile?
How can I "increase the maximum RX gain"? (I am already using the latest version of the driver)
Is there another solution for Fedora?

Any help would be greatly appreciated!

[lwfinger]

I doubt that site_survey has anything to do with the problem, but you certainly can try it.

The maximum gain for TX and RX is already as large as allowed. I am assuming that you would rather not burn out your device.

Your only other option would be to find the Realtek driver somewhere on the web, but then you would have to fix all the places that do not build. BTW, one of the RedHat engineers is working on fixing up the code to get it ready for integration into the kernel. He has not said, but I expect that he is also running Fedora, probably F20. He does not have a problem.

Does the channel you are using have much interference in your environment? What make/model of AP do you have? Does it have the latest firmware? Are you running 802.11n, or 802.11g?

[Linefader]

Hi lwfinger, thanks for your reply!

Here is the information you requested (as far as I knew it)

1. I don't plan to burn my device ;-)
2. Why should I search the Web for the driver sources?
   I already cloned them from your GIT-repo.
   My question is if it makes sense to change anything in there (and what) to solve the problem
3. How can I find out, if there is much interference on the channel that I am using?
   I have many other WLAN devices in my house (PC, Macs, Home Entertainment Stuff ..) but none of them has problems with the WiFi, except the Yoga Ultrabook
   Can I change the channel somehow and see if it improves anything?
4. I have two access points:
   One Vodaphone router (produced by Arcadyan) and a Netgear range extender.
   Both devices have the latest firmware installed (they update automatically) and the problems occurs with both devices (although the network is generally stronger when I connect to the extender)
5. Actually, I don't know whether I am running 802.11n or 802.11g
   According to my router manual, both should be supported. How can I find out what I am using and change it?

I also searched the Web for this problem and found out that some other Yoga users have reported networking problems in Windows which they could fix by turning off "selective suspend" (forums.lenovo.com). Can I alter the power saving behaviour for Linux in a similar manner?

p.s. maybe you can point that RedHat engineer to fedoraforum.org
I opened a thread on my networking problems there, but I didn't get any reply so far.
This thread can be easily found by searching FedoraForum for "rtl8723au"
It would be great, if that engineer sent me a PM and we can have a look into my syslogs together

[lwfinger]

1. Good.
2. I thought you wanted a different driver than the one in the repo.
3. You can determine the amount of interference with a scan. For 802.11g, any other station within +- two channels will interfere. For 802.11n, the total width is 8 channels. The extra width may be above or below the center.
4. If the listed connection rate is higher than 54 Mbps, it is 802.11n.

You can disable power saving by loading the driver with the "rtw_ips_mode=0" module option. That should be the same thing; however, as Windows always has its own terminology, who knows?

You can see all the module options with "modinfo 8723au".

[markp-mckinney]

I'm using a Lenovo Yoga 13 and am experiencing these drops so often that I can't really even use the wifi. I'm connecting to my university's wifi which is WPA2 Enterprise. The wifi works fine on my phone (Samsung Galaxy S IV) and on my laptop when in Windows, but not when running Linux Mint 16. The longest it'll connect for is under a minute it seems. All of my configuration for connecting should be correct. I'll try changing the power saving setting and see what happens...

[maggieroxas]

Hi - I've been encountering this issue using the version as of Dec. 09, 2013. Connection drops intermittently and even disconnects sometimes, as tested in 3m, 10m range. My Linux kernel version is v3.10.24, and have been cross compiling your driver across ARM compiler. In any case, I thought it was just the antenna, however, this connection issue happen only during 8723AU being the AP mode. The connection's stable when it's in Client mode. If there's anything you need from me to debug this issue, ie, my board-specific patches, logs, screenshots - I'd be happy to provide, just say so. Thank you very much for your support.

[Linefader]

Hi Maggieroxas! This sounds interesting. I had already given up with this: I bought a USB-to-Ethernet adapter (D-Link DUB-E100) and started using a wired connection. This works, but I would still be happy, if you could show me a way to get a stable wireless connection. How do I switch the network adapter from AP to client mode?

[maggieroxas]

@Linefader, sorry, I'm not sure if I will be able to help you. I'm switching from AP to client and vice versa via console commands (I have access to my wireless device's serial port and this device's a mini comp). I switch from AP to client via "iwconfig"; and switch client to AP by manually turning wlan0 up via "ifconfig" and running of "dnsmasq" service.

For the stable wireless connection, mine was resolved by disabling a flag in the installation of the rtl8723au driver, which, I assume, you didn't use for your D-Link DUB-E100,

[Linefader]

just ignore that I am using this D-Link adapter. It has nothing to do with the Realtek driver. It allows to set up a WIRED connection (and works on the Lenovo Yoga with Fedora 20 and without any additional driver software).

Please let me know what flag you had to disable in the driver code to get a stable WIRELESS connection.

[DoktorMike]

I get similar problems and it's gotten a lot worse over time. Now I'm lucky if I get access a few minutes at a time. I've updated to the latest source and compiled it and installed it from the git repository. My output from dmesg:

[42252.239488] RTL8723AU: ERROR start auth
[42252.242592] RTL8723AU: ERROR auth success, start assoc
[42252.246313] RTL8723AU: ERROR indicate disassoc
[42253.636411] RTL8723AU: ERROR set ssid [Blackwood] fw_state=0x00000008
[42253.636452] RTL8723AU: ERROR set bssid:88:1f:a1:36:f1:08
[42253.775744] RTL8723AU: ERROR start auth
[42253.782335] RTL8723AU: ERROR auth success, start assoc
[42253.787106] RTL8723AU: ERROR assoc success
[42253.799978] RTL8723AU: ERROR send eapol packet
[42253.804577] RTL8723AU: ERROR send eapol packet
[42253.804710] RTL8723AU: ERROR set pairwise key to hw: alg:4(WEP40-1 WEP104-5 TKIP-2 AES-4) camid:4
[42253.810895] RTL8723AU: ERROR set group key to hw: alg:4(WEP40-1 WEP104-5 TKIP-2 AES-4) keyid:2
[42278.485595] RTL8723AU: ERROR set group key to hw: alg:4(WEP40-1 WEP104-5 TKIP-2 AES-4) keyid:1
[42278.485605] RTL8723AU: ERROR send eapol packet
[42281.467080] RTL8723AU: ERROR set group key to hw: alg:4(WEP40-1 WEP104-5 TKIP-2 AES-4) keyid:2
[42281.467091] RTL8723AU: ERROR send eapol packet
[42354.555601] RTL8723AU: ERROR set group key to hw: alg:4(WEP40-1 WEP104-5 TKIP-2 AES-4) keyid:1
[42354.555673] RTL8723AU: ERROR send eapol packet

Does anyone know how to fix this?

[CaptainFuzzyFace]

I have the Lenovo Yoga 13 running Ubuntu 14.04 and also have the same issue. Wifi icon stays as connected but no data traffic at all for minutes at a time. I'm still looking for a solution.

[nfischer]

Does anyone have any tips about this? I'm using the 3.16 kernel and my computer crashes (freezes, sometimes screen goes black, sysreq key doesn't help, etc.) whenever I switch access points on my network. The problem might be related to what's going on here. I see lots of dnsmasq failures, and I know that I disabled dnsmasq for my home access points