Speed of RTL8723be slow because of many lost TCP packages

[ghost]

Hi,

i'm trying to get a stable and fast wifi connection with the RTL8723be wifi adapter in my Lenovo G50-70 notebook since 1,5 month and i still have the problem of low speed and many lost TCP packages, when i analyse the connection by pinging the AP with Ping.

When i use my notebook at the same place (my office table with a distance of 15 meters to the AP) with Win7, the connection is stable and i don't have the problems.

When i decrease the distance between the notebook and the AP, the connection becomes better and better so that surfing the internet becomes fast and stable at one point (1,5 meters away from my office table). That means, that the driver is working. But when i put the notebook back on my office table, the problems starts again after a while or immediatly.

It seems to me, that the driver for my RTL8723be adapter from here doesn't have the quality of the Win7 driver.

I use Ubuntu 14.10 with Linux Kernel 3.16.0-29 and the newest rtlwifi_new drivers from here. I also have switched the module parameters to "ips=N fwlps=N disable_watchdog=Y msi=0".

Is this a known problem with this wlan adapter/driver and is there a chance to solve such problems in the near future ?

What informations do you need for analysis ? I'm new to Linux and don't know, what kind of informations are neccessary for helping me.

Thanks in advance for your interest and support !!!

I'll try my best to speak/write in English-please try to understand me!

[lwfinger]

Your English is fine. In fact, it is so good that I cannot even guess your native language.

Thank you for the careful and detailed analysis of your situation. It seems that the rate setting mechanism is failing. It is also possible that the radio gain is not being increased as you move further from the access point. With my current setup, my computer is about 2m from the AP, and it would be very difficult to move. I see no reason that this situation cannot be fixed.

Please post the output of the command 'iw dev xxxxxx station dump' in the two locations. Replace xxxxxx with the actual name of the device as shown in the "ip link" command.

[ghost]

Hi Larry,

many thanks for the compliment about my english :-) I'm from germany and writing has cost me a lot of time. But it's a good practice for me :-)

Ok. Let's see, what i have found out. I ran Ping for a duration of 4 minutes. During this time, the command 'iw dev wlan0 station dump' printed this to the console:

Station d8:eb:97:ba:4d:b4 (on wlan0)
    inactive time:    32 ms
    rx bytes:    3117538
    rx packets:    12679
    tx bytes:    304146
    tx packets:    2781
    tx retries:    0
    tx failed:    0
    signal:      -42 dBm
    signal avg:    -40 dBm
    tx bitrate:    150.0 MBit/s MCS 7 40MHz short GI
    rx bitrate:    1.0 MBit/s
    authorized:    yes
    authenticated:    yes
    preamble:    long
    WMM/WME:    yes
    MFP:        no
    TDLS peer:    no

I think, that the signal strength is not the problem. I ran the 'iw' command during the Ping every 5 seconds. The signal strength was between 40 and 46.

The following Ping result

---

--- 192.168.10.1 ping statistics ---
245 packets transmitted, 202 received, 17% packet loss, time 244568ms

rtt min/avg/max/mdev = 1.243/304.459/2021.401/540.640 ms, pipe 3

shows, that there are lot's of TCP packeges lost and the average responsetime is bad (304 ms).

The question is, what causes this problems and i'm very courious, if you have any ideas or you can find a solution.

Finally i put the Ping output to this message and marked the first bad response times in the protocol. I hope that the output is helpfully for you :-)

PING 192.168.10.1 (192.168.10.1) 56(84) bytes of data.
64 bytes from 192.168.10.1: icmp_seq=1 ttl=64 time=7.39 ms
64 bytes from 192.168.10.1: icmp_seq=2 ttl=64 time=848 ms <<
64 bytes from 192.168.10.1: icmp_seq=3 ttl=64 time=21.2 ms
64 bytes from 192.168.10.1: icmp_seq=4 ttl=64 time=1.88 ms
64 bytes from 192.168.10.1: icmp_seq=6 ttl=64 time=1012 ms
64 bytes from 192.168.10.1: icmp_seq=7 ttl=64 time=4.66 ms
64 bytes from 192.168.10.1: icmp_seq=8 ttl=64 time=23.3 ms
64 bytes from 192.168.10.1: icmp_seq=9 ttl=64 time=7.12 ms
64 bytes from 192.168.10.1: icmp_seq=10 ttl=64 time=7.47 ms
64 bytes from 192.168.10.1: icmp_seq=11 ttl=64 time=13.6 ms
64 bytes from 192.168.10.1: icmp_seq=13 ttl=64 time=36.3 ms
64 bytes from 192.168.10.1: icmp_seq=14 ttl=64 time=10.7 ms
64 bytes from 192.168.10.1: icmp_seq=16 ttl=64 time=1867 ms <<
64 bytes from 192.168.10.1: icmp_seq=17 ttl=64 time=859 ms <<
64 bytes from 192.168.10.1: icmp_seq=18 ttl=64 time=2.92 ms
64 bytes from 192.168.10.1: icmp_seq=19 ttl=64 time=7.26 ms
64 bytes from 192.168.10.1: icmp_seq=21 ttl=64 time=877 ms <<
64 bytes from 192.168.10.1: icmp_seq=22 ttl=64 time=10.2 ms
64 bytes from 192.168.10.1: icmp_seq=23 ttl=64 time=5.16 ms
64 bytes from 192.168.10.1: icmp_seq=24 ttl=64 time=7.28 ms
64 bytes from 192.168.10.1: icmp_seq=25 ttl=64 time=13.7 ms
64 bytes from 192.168.10.1: icmp_seq=26 ttl=64 time=3.04 ms
64 bytes from 192.168.10.1: icmp_seq=27 ttl=64 time=6.83 ms
64 bytes from 192.168.10.1: icmp_seq=28 ttl=64 time=12.5 ms
64 bytes from 192.168.10.1: icmp_seq=29 ttl=64 time=18.8 ms
64 bytes from 192.168.10.1: icmp_seq=31 ttl=64 time=12.3 ms
64 bytes from 192.168.10.1: icmp_seq=32 ttl=64 time=874 ms <<
64 bytes from 192.168.10.1: icmp_seq=33 ttl=64 time=5.02 ms
64 bytes from 192.168.10.1: icmp_seq=34 ttl=64 time=1.90 ms
64 bytes from 192.168.10.1: icmp_seq=35 ttl=64 time=6.19 ms
64 bytes from 192.168.10.1: icmp_seq=36 ttl=64 time=13.3 ms
64 bytes from 192.168.10.1: icmp_seq=37 ttl=64 time=1.29 ms
64 bytes from 192.168.10.1: icmp_seq=38 ttl=64 time=4.56 ms
64 bytes from 192.168.10.1: icmp_seq=39 ttl=64 time=6.02 ms
64 bytes from 192.168.10.1: icmp_seq=40 ttl=64 time=30.3 ms
64 bytes from 192.168.10.1: icmp_seq=41 ttl=64 time=1.97 ms
64 bytes from 192.168.10.1: icmp_seq=42 ttl=64 time=881 ms <<
64 bytes from 192.168.10.1: icmp_seq=43 ttl=64 time=4.46 ms
64 bytes from 192.168.10.1: icmp_seq=46 ttl=64 time=874 ms <<
64 bytes from 192.168.10.1: icmp_seq=47 ttl=64 time=2.26 ms
64 bytes from 192.168.10.1: icmp_seq=49 ttl=64 time=1.87 ms
64 bytes from 192.168.10.1: icmp_seq=50 ttl=64 time=12.4 ms
64 bytes from 192.168.10.1: icmp_seq=51 ttl=64 time=6.66 ms
64 bytes from 192.168.10.1: icmp_seq=52 ttl=64 time=1.43 ms
64 bytes from 192.168.10.1: icmp_seq=53 ttl=64 time=1.64 ms
64 bytes from 192.168.10.1: icmp_seq=55 ttl=64 time=27.4 ms
64 bytes from 192.168.10.1: icmp_seq=56 ttl=64 time=2.69 ms
64 bytes from 192.168.10.1: icmp_seq=57 ttl=64 time=10.1 ms
64 bytes from 192.168.10.1: icmp_seq=58 ttl=64 time=5.67 ms
64 bytes from 192.168.10.1: icmp_seq=59 ttl=64 time=3.09 ms
64 bytes from 192.168.10.1: icmp_seq=61 ttl=64 time=866 ms
64 bytes from 192.168.10.1: icmp_seq=62 ttl=64 time=2.96 ms
64 bytes from 192.168.10.1: icmp_seq=65 ttl=64 time=7.18 ms
64 bytes from 192.168.10.1: icmp_seq=66 ttl=64 time=2.87 ms
64 bytes from 192.168.10.1: icmp_seq=67 ttl=64 time=225 ms
64 bytes from 192.168.10.1: icmp_seq=68 ttl=64 time=6.28 ms
64 bytes from 192.168.10.1: icmp_seq=69 ttl=64 time=3.53 ms
64 bytes from 192.168.10.1: icmp_seq=71 ttl=64 time=1889 ms
64 bytes from 192.168.10.1: icmp_seq=72 ttl=64 time=889 ms
64 bytes from 192.168.10.1: icmp_seq=73 ttl=64 time=5.76 ms
64 bytes from 192.168.10.1: icmp_seq=75 ttl=64 time=906 ms
64 bytes from 192.168.10.1: icmp_seq=76 ttl=64 time=1.83 ms
64 bytes from 192.168.10.1: icmp_seq=79 ttl=64 time=914 ms
64 bytes from 192.168.10.1: icmp_seq=80 ttl=64 time=2.72 ms
64 bytes from 192.168.10.1: icmp_seq=81 ttl=64 time=1.77 ms
64 bytes from 192.168.10.1: icmp_seq=82 ttl=64 time=2.28 ms
64 bytes from 192.168.10.1: icmp_seq=83 ttl=64 time=4.20 ms
64 bytes from 192.168.10.1: icmp_seq=84 ttl=64 time=5.37 ms
64 bytes from 192.168.10.1: icmp_seq=85 ttl=64 time=2.78 ms
64 bytes from 192.168.10.1: icmp_seq=86 ttl=64 time=3.93 ms
64 bytes from 192.168.10.1: icmp_seq=87 ttl=64 time=2.75 ms
64 bytes from 192.168.10.1: icmp_seq=88 ttl=64 time=4.80 ms
64 bytes from 192.168.10.1: icmp_seq=89 ttl=64 time=1.85 ms
64 bytes from 192.168.10.1: icmp_seq=90 ttl=64 time=1.74 ms
64 bytes from 192.168.10.1: icmp_seq=91 ttl=64 time=908 ms
64 bytes from 192.168.10.1: icmp_seq=93 ttl=64 time=1014 ms
64 bytes from 192.168.10.1: icmp_seq=94 ttl=64 time=7.04 ms
64 bytes from 192.168.10.1: icmp_seq=95 ttl=64 time=4.02 ms
64 bytes from 192.168.10.1: icmp_seq=96 ttl=64 time=16.4 ms
64 bytes from 192.168.10.1: icmp_seq=98 ttl=64 time=1009 ms
64 bytes from 192.168.10.1: icmp_seq=99 ttl=64 time=1.96 ms
64 bytes from 192.168.10.1: icmp_seq=101 ttl=64 time=8.92 ms
64 bytes from 192.168.10.1: icmp_seq=103 ttl=64 time=889 ms
64 bytes from 192.168.10.1: icmp_seq=104 ttl=64 time=4.82 ms
64 bytes from 192.168.10.1: icmp_seq=105 ttl=64 time=882 ms
64 bytes from 192.168.10.1: icmp_seq=106 ttl=64 time=3.75 ms
64 bytes from 192.168.10.1: icmp_seq=107 ttl=64 time=6.35 ms
64 bytes from 192.168.10.1: icmp_seq=108 ttl=64 time=1.98 ms
64 bytes from 192.168.10.1: icmp_seq=109 ttl=64 time=2.45 ms
64 bytes from 192.168.10.1: icmp_seq=110 ttl=64 time=1.91 ms
64 bytes from 192.168.10.1: icmp_seq=111 ttl=64 time=2.63 ms
64 bytes from 192.168.10.1: icmp_seq=112 ttl=64 time=2.18 ms
64 bytes from 192.168.10.1: icmp_seq=113 ttl=64 time=2.36 ms
64 bytes from 192.168.10.1: icmp_seq=115 ttl=64 time=1009 ms
64 bytes from 192.168.10.1: icmp_seq=116 ttl=64 time=1.81 ms
64 bytes from 192.168.10.1: icmp_seq=118 ttl=64 time=2002 ms
64 bytes from 192.168.10.1: icmp_seq=120 ttl=64 time=1909 ms
64 bytes from 192.168.10.1: icmp_seq=122 ttl=64 time=5.11 ms
64 bytes from 192.168.10.1: icmp_seq=123 ttl=64 time=7.47 ms
64 bytes from 192.168.10.1: icmp_seq=126 ttl=64 time=2005 ms
64 bytes from 192.168.10.1: icmp_seq=127 ttl=64 time=1005 ms
64 bytes from 192.168.10.1: icmp_seq=128 ttl=64 time=5.71 ms
64 bytes from 192.168.10.1: icmp_seq=129 ttl=64 time=1.50 ms
64 bytes from 192.168.10.1: icmp_seq=131 ttl=64 time=918 ms
64 bytes from 192.168.10.1: icmp_seq=133 ttl=64 time=918 ms
64 bytes from 192.168.10.1: icmp_seq=134 ttl=64 time=1.80 ms
64 bytes from 192.168.10.1: icmp_seq=135 ttl=64 time=9.43 ms
64 bytes from 192.168.10.1: icmp_seq=136 ttl=64 time=1.50 ms
64 bytes from 192.168.10.1: icmp_seq=137 ttl=64 time=2.20 ms
64 bytes from 192.168.10.1: icmp_seq=138 ttl=64 time=1.76 ms
64 bytes from 192.168.10.1: icmp_seq=139 ttl=64 time=2.90 ms
64 bytes from 192.168.10.1: icmp_seq=140 ttl=64 time=6.72 ms
64 bytes from 192.168.10.1: icmp_seq=141 ttl=64 time=1.65 ms
64 bytes from 192.168.10.1: icmp_seq=142 ttl=64 time=921 ms
64 bytes from 192.168.10.1: icmp_seq=143 ttl=64 time=12.3 ms
64 bytes from 192.168.10.1: icmp_seq=144 ttl=64 time=4.34 ms
64 bytes from 192.168.10.1: icmp_seq=146 ttl=64 time=1940 ms
64 bytes from 192.168.10.1: icmp_seq=150 ttl=64 time=919 ms
64 bytes from 192.168.10.1: icmp_seq=152 ttl=64 time=900 ms
64 bytes from 192.168.10.1: icmp_seq=153 ttl=64 time=6.03 ms
64 bytes from 192.168.10.1: icmp_seq=154 ttl=64 time=12.5 ms
64 bytes from 192.168.10.1: icmp_seq=155 ttl=64 time=7.00 ms
64 bytes from 192.168.10.1: icmp_seq=156 ttl=64 time=1.74 ms
64 bytes from 192.168.10.1: icmp_seq=157 ttl=64 time=1.82 ms
64 bytes from 192.168.10.1: icmp_seq=158 ttl=64 time=916 ms
64 bytes from 192.168.10.1: icmp_seq=159 ttl=64 time=1.51 ms
64 bytes from 192.168.10.1: icmp_seq=160 ttl=64 time=2.59 ms
64 bytes from 192.168.10.1: icmp_seq=161 ttl=64 time=5.10 ms
64 bytes from 192.168.10.1: icmp_seq=162 ttl=64 time=2.90 ms
64 bytes from 192.168.10.1: icmp_seq=164 ttl=64 time=2021 ms
64 bytes from 192.168.10.1: icmp_seq=165 ttl=64 time=1013 ms
64 bytes from 192.168.10.1: icmp_seq=166 ttl=64 time=5.47 ms
64 bytes from 192.168.10.1: icmp_seq=167 ttl=64 time=5.94 ms
64 bytes from 192.168.10.1: icmp_seq=168 ttl=64 time=919 ms
64 bytes from 192.168.10.1: icmp_seq=169 ttl=64 time=4.06 ms
64 bytes from 192.168.10.1: icmp_seq=170 ttl=64 time=923 ms
64 bytes from 192.168.10.1: icmp_seq=171 ttl=64 time=3.31 ms
64 bytes from 192.168.10.1: icmp_seq=172 ttl=64 time=7.08 ms
64 bytes from 192.168.10.1: icmp_seq=173 ttl=64 time=2.32 ms
64 bytes from 192.168.10.1: icmp_seq=174 ttl=64 time=97.8 ms
64 bytes from 192.168.10.1: icmp_seq=176 ttl=64 time=1916 ms
64 bytes from 192.168.10.1: icmp_seq=177 ttl=64 time=908 ms
64 bytes from 192.168.10.1: icmp_seq=178 ttl=64 time=1.96 ms
64 bytes from 192.168.10.1: icmp_seq=179 ttl=64 time=925 ms
64 bytes from 192.168.10.1: icmp_seq=180 ttl=64 time=1.51 ms
64 bytes from 192.168.10.1: icmp_seq=181 ttl=64 time=1.71 ms
64 bytes from 192.168.10.1: icmp_seq=182 ttl=64 time=3.73 ms
64 bytes from 192.168.10.1: icmp_seq=183 ttl=64 time=1.54 ms
64 bytes from 192.168.10.1: icmp_seq=184 ttl=64 time=6.23 ms
64 bytes from 192.168.10.1: icmp_seq=185 ttl=64 time=1.54 ms
64 bytes from 192.168.10.1: icmp_seq=186 ttl=64 time=4.60 ms
64 bytes from 192.168.10.1: icmp_seq=188 ttl=64 time=907 ms
64 bytes from 192.168.10.1: icmp_seq=189 ttl=64 time=1012 ms
64 bytes from 192.168.10.1: icmp_seq=190 ttl=64 time=918 ms
64 bytes from 192.168.10.1: icmp_seq=191 ttl=64 time=6.22 ms
64 bytes from 192.168.10.1: icmp_seq=192 ttl=64 time=1.43 ms
64 bytes from 192.168.10.1: icmp_seq=194 ttl=64 time=927 ms
64 bytes from 192.168.10.1: icmp_seq=195 ttl=64 time=2.40 ms
64 bytes from 192.168.10.1: icmp_seq=197 ttl=64 time=1919 ms
64 bytes from 192.168.10.1: icmp_seq=198 ttl=64 time=917 ms
64 bytes from 192.168.10.1: icmp_seq=199 ttl=64 time=1.44 ms
64 bytes from 192.168.10.1: icmp_seq=200 ttl=64 time=8.07 ms
64 bytes from 192.168.10.1: icmp_seq=201 ttl=64 time=1.70 ms
64 bytes from 192.168.10.1: icmp_seq=202 ttl=64 time=3.18 ms
64 bytes from 192.168.10.1: icmp_seq=203 ttl=64 time=1.50 ms
64 bytes from 192.168.10.1: icmp_seq=204 ttl=64 time=911 ms
64 bytes from 192.168.10.1: icmp_seq=205 ttl=64 time=1.76 ms
64 bytes from 192.168.10.1: icmp_seq=206 ttl=64 time=1.97 ms
64 bytes from 192.168.10.1: icmp_seq=208 ttl=64 time=929 ms
64 bytes from 192.168.10.1: icmp_seq=210 ttl=64 time=1941 ms
64 bytes from 192.168.10.1: icmp_seq=211 ttl=64 time=933 ms
64 bytes from 192.168.10.1: icmp_seq=212 ttl=64 time=1.66 ms
64 bytes from 192.168.10.1: icmp_seq=213 ttl=64 time=6.94 ms
64 bytes from 192.168.10.1: icmp_seq=214 ttl=64 time=1.24 ms
64 bytes from 192.168.10.1: icmp_seq=215 ttl=64 time=3.18 ms
64 bytes from 192.168.10.1: icmp_seq=216 ttl=64 time=1.43 ms
64 bytes from 192.168.10.1: icmp_seq=217 ttl=64 time=1.80 ms
64 bytes from 192.168.10.1: icmp_seq=218 ttl=64 time=4.24 ms
64 bytes from 192.168.10.1: icmp_seq=219 ttl=64 time=2.25 ms
64 bytes from 192.168.10.1: icmp_seq=220 ttl=64 time=5.60 ms
64 bytes from 192.168.10.1: icmp_seq=221 ttl=64 time=2.28 ms
64 bytes from 192.168.10.1: icmp_seq=222 ttl=64 time=1.49 ms
64 bytes from 192.168.10.1: icmp_seq=223 ttl=64 time=940 ms
64 bytes from 192.168.10.1: icmp_seq=225 ttl=64 time=1011 ms
64 bytes from 192.168.10.1: icmp_seq=226 ttl=64 time=3.49 ms
64 bytes from 192.168.10.1: icmp_seq=227 ttl=64 time=1.80 ms
64 bytes from 192.168.10.1: icmp_seq=228 ttl=64 time=1.47 ms
64 bytes from 192.168.10.1: icmp_seq=229 ttl=64 time=53.3 ms
64 bytes from 192.168.10.1: icmp_seq=230 ttl=64 time=49.0 ms
64 bytes from 192.168.10.1: icmp_seq=232 ttl=64 time=1942 ms
64 bytes from 192.168.10.1: icmp_seq=233 ttl=64 time=934 ms
64 bytes from 192.168.10.1: icmp_seq=234 ttl=64 time=3.37 ms
64 bytes from 192.168.10.1: icmp_seq=235 ttl=64 time=2.73 ms
64 bytes from 192.168.10.1: icmp_seq=236 ttl=64 time=942 ms
64 bytes from 192.168.10.1: icmp_seq=237 ttl=64 time=2.55 ms
64 bytes from 192.168.10.1: icmp_seq=239 ttl=64 time=949 ms
64 bytes from 192.168.10.1: icmp_seq=240 ttl=64 time=2.18 ms
64 bytes from 192.168.10.1: icmp_seq=241 ttl=64 time=1.91 ms
64 bytes from 192.168.10.1: icmp_seq=242 ttl=64 time=10.6 ms
64 bytes from 192.168.10.1: icmp_seq=243 ttl=64 time=1.62 ms
64 bytes from 192.168.10.1: icmp_seq=244 ttl=64 time=2.59 ms
64 bytes from 192.168.10.1: icmp_seq=245 ttl=64 time=1.64 ms

--- 192.168.10.1 ping statistics ---
245 packets transmitted, 202 received, 17% packet loss, time 244568ms
rtt min/avg/max/mdev = 1.243/304.459/2021.401/540.640 ms, pipe 3

45 minutes later the count of lost TCP Packages causes horrible response times and makes surfing the internt horrible. Look at this:

PING 192.168.10.1 (192.168.10.1) 56(84) bytes of data.
64 bytes from 192.168.10.1: icmp_seq=3 ttl=64 time=31.9 ms
64 bytes from 192.168.10.1: icmp_seq=5 ttl=64 time=1049 ms
64 bytes from 192.168.10.1: icmp_seq=6 ttl=64 time=336 ms
64 bytes from 192.168.10.1: icmp_seq=9 ttl=64 time=2592 ms
64 bytes from 192.168.10.1: icmp_seq=11 ttl=64 time=592 ms
64 bytes from 192.168.10.1: icmp_seq=12 ttl=64 time=73.8 ms
64 bytes from 192.168.10.1: icmp_seq=14 ttl=64 time=1012 ms
64 bytes from 192.168.10.1: icmp_seq=15 ttl=64 time=4.22 ms
64 bytes from 192.168.10.1: icmp_seq=16 ttl=64 time=40.3 ms
64 bytes from 192.168.10.1: icmp_seq=17 ttl=64 time=10.0 ms
^C
--- 192.168.10.1 ping statistics ---
17 packets transmitted, 10 received, 41% packet loss, time 16054ms
rtt min/avg/max/mdev = 4.221/574.302/2592.102/775.815 ms, pipe 3

This are the current output from the iw Command:

Station d8:eb:97:ba:4d:b4 (on wlan0)
inactive time: 12660 ms
rx bytes: 32529585
rx packets: 107811
tx bytes: 6160324
tx packets: 36856
tx retries: 0
tx failed: 0
signal: -36 dBm
signal avg: -37 dBm
tx bitrate: 150.0 MBit/s MCS 7 40MHz short GI
rx bitrate: 1.0 MBit/s
authorized: yes
authenticated: yes
preamble: long
WMM/WME: yes
MFP: no
TDLS peer: no

[winter-bear]

hi:
lwfinger,i have a 11-inch core-m win8 pad.and the pad The WiFi model is rtl 8723b。dear lwfinger can you share the linux 64bit driver for this wfi moudle

[lwfinger]

I have no Windows drivers. I do not use any version of Windows in anything but a virtual machine, thus I do not use any wireless drivers there. A Google search for rtl8723b driver found links for all versions of Windows.

By the way, this repo is for the RTL8723BE, which is a PCIe device. I suspect you have a USB device.

[winter-bear]

lwfinger:
first,thanks a lot for your reply .
i just need the linux driver for RTL8723B
and i try install ubuntu on this win8 core-m pad.
it's not usb device

[lwfinger]

What does the ;lspci -nn' show?

[winter-bear]

this is the commamd "lspci -nn" show:
00:00.0 Host bridge [0600]: Intel Corporation Broadwell-U Host Bridge -OPI [8086:1604](rev 09)
00:02.0 VGA compatible controller [0300]: Intel Corporation Broadwell-U Integrated Graphics [8086:161e](rev 09)
00:03.0 Audio device [0403]: Intel Corporation Broadwell-U Audio Controller [8086:160c](rev 09)
00:04.0 Signal processing controller [1180]: Intel Corporation Broadwell-U Camarillo Device [8086:1603](rev 09)
00:14.0 USB controller [0c03]: Intel Corporation Wildcat Point-LP USB xHCI Controller [8086:9cb1](rev 03)
00:16.0 Communication controller [0780]: Intel Corporation Wildcat Point-LP MEI Controller #1 [8086:9cba](rev 03)
00:1b.0 Audio device [0403]: Intel Corporation Wildcat Point-LP High Definition Audio Controller [8086:9ca0](rev 03)
00:1f.0 ISA bridge [0601]: Intel Corporation Wildcat Point-LP LPC Controller [8086:9cc7](rev 03)
00:1f.2 SATA controller [0106]: Intel Corporation Wildcat Point-LP SATA Controller [AHCI Mode] [8086:9c83](rev 03)
00:1f.3 SMBus [0c05]: Intel Corporation Wildcat Point-LP SMBus Controller [8086:9ca2](rev 03)
00:1f.6 Signal processing controller [1180]: Intel Corporation Wildcat Point-LP Thermal Management Controller [8086:9ca4](rev 03)

there is no information about wifi moudle. so i need the liunx driver for rtl8723b(fuck RTL)

[troy-tan]

I think you may have a sdio wifi device on your pad. I think it is more likely to
have a sdio wifi device in a small pad than usb or PCIE device.
This means you can try rtl8723bs.

[ghost]

I hope that the questions from user winter-bear doesn't have blured the problems, for what i started this issue (Speed of RTL8723be slow because of many lost TCP packages).

Is it possible, that my last comment respectivly the 'Ping' and 'iw' logs i reported here, has lost ?

Please give me hope, that one can solve the problems i have with my notebook and the RTL8723be card.

Could it be helpful to set the debug Parameter of the module to 1,2,3,4 or 5 and show an output here ?

I have a new question:

How can i check, wether i use the newest driver or not ?

When i look at my current module informations (look below), i'm not sure, if the driver, which i installed 4 days ago, is really active or if there works an older version and the 'make install' didnt't work correctly.

Is there (look below) an information, that shows the version of module driver ? I'm wondering why the author info doesn't say, that larry finger is the author.

How can i interprete the scr version (F690F57D5768E7A4CD573DD in my example) and can i find this info in any release notes of the kernel versions from here or something like that ?

modinfo rtl8723be

filename: /lib/modules/3.16.0-29-generic/kernel/drivers/net/wireless/rtlwifi/rtl8723be/rtl8723be.ko
firmware: rtlwifi/rtl8723befw.bin
description: Realtek 8723BE 802.11n PCI wireless
license: GPL
author: Realtek WlanFAE wlanfae@realtek.com
author: PageHe page_he@realsil.com.cn
srcversion: F690F57D5768E7A4CD573DD
alias: pci:v000010ECd0000B723sv_sd_bc_sc_i*
depends: rtlwifi,rtl_pci,btcoexist,mac80211
vermagic: 3.16.0-29-generic SMP mod_unload modversions 686
parm: swlps:bool
parm: swenc:using hardware crypto (default 0 [hardware])
(bool)
parm: ips:using no link power save (default 1 is open)
(bool)
parm: fwlps:using linked fw control power save (default 1 is open)
(bool)
parm: msi:Set to 1 to use MSI interrupts mode (default 0)

parm: debug:Set debug level (0-5) (default 0) (int)
parm: disable_watchdog:Set to 1 to disable the watchdog (default 0)
(bool)

[bluish-x]

I was also experiencing packet loss, high latency, I think I've found a solution.

kernel: 3.19-rc7 with rtlwifi_new, fwlps, ips, swenc, swlps were all 0

Before rtlwifi_new, the card was dropping wpa connections, with rtlwifi_new, it looks like it just loses packets and lags.

Right now, while inspecting "systool -v -m rtl8723be" I've noticed swenc was 0, meaning it was doing hardware encryption(?), so changed it to 1, forcing software encryption, everything looks ok right now, no high ping or packet loss. Flooded my router with ~200k pings, not a single one was lost.

This might be a temporary solution till hardware encrytion is fixed. Could anybody test this and comment please?

[bluish-x]

False alarm, it suddenly gone back to losing packets and high ping.

But it kind of looks improved, or maybe it's a placebo.

[svenmeier]

As you can see in issue #22, I'm too struggling to get improved connection with RTL8723be.

Ping times to my router range from 1.5ms to 150ms, in extreme cases this can increase to over 2 seconds. I'm sitting 6m away from my wifi router, just a single wall between.

Two station dumps:

sven@SvenBlack:~/Downloads/wifi/rtlwifi_new$ iw dev wlan1 station dump
Station c0:25:06:ea:4c:8a (on wlan1)
    inactive time:  76 ms
    rx bytes:   699240
    rx packets: 6119
    tx bytes:   79434
    tx packets: 802
    tx retries: 0
    tx failed:  0
    signal:     -50 dBm
    signal avg: -52 dBm
    tx bitrate: 150.0 MBit/s MCS 7 40MHz short GI
    rx bitrate: 1.0 MBit/s
    authorized: yes
    authenticated:  yes
    preamble:   long
    WMM/WME:    yes
    MFP:        no
    TDLS peer:  no

... and:

sven@SvenBlack:~/Downloads/wifi/rtlwifi_new$ iw dev wlan1 station dump
Station c0:25:06:ea:4c:8a (on wlan1)
    inactive time:  600 ms
    rx bytes:   752606
    rx packets: 6613
    tx bytes:   83022
    tx packets: 836
    tx retries: 0
    tx failed:  0
    signal:     -46 dBm
    signal avg: -50 dBm
    tx bitrate: 150.0 MBit/s MCS 7 40MHz short GI
    rx bitrate: 1.0 MBit/s
    authorized: yes
    authenticated:  yes
    preamble:   long
    WMM/WME:    yes
    MFP:        no
    TDLS peer:  no

[lwfinger]

Patches are welcome.

[geromek]

What worked for me was enabling the MSI parameter [message signal interupt ]. I have a lenovo Z50 laptop. My wifi would work with all wifi laptop manufacturers but i was having a problem with a Lancorm wifi router at a Hotel I once stayed.

what i did was this. I scrowled to the file "sw.c" in the folder

"/home/peter/rtlwifi_new/rtl8723be"

Then in the sw.c file, I initiated the variable "msi_support" to "false" under the data type "rtl_mod_params rtl8723be_mod_params" i.e

static struct rtl_mod_params rtl8723be_mod_params = {
.sw_crypto = false,
.inactiveps = true,
.swctrl_lps = false,
.fwctrl_lps = true,
.msi_support = false,
};

Since msi_support is by default disabled, we have to appropriately initialize it as disabled,

I then complied the code, ie

cd rtl8723be
make clean
sudo make install
sudo modprobe rtl8723be

after that I set the msi parameter to 1, in the file "rtl8723be.conf" which can be found under
"/etc/modprobe.d"
i.e
options rtl8723be fwlps=N ips=N swenc=Y msi=1

You may have to reboot the computer and wait after a couple of minutes after restarting the browser for the msi to be triggered.

This worked for a lenovo z50. Depending on your pc, you may toggle and choose instead an msi of 0

[lwfinger]

By now I'm sure that you know about the "modinfo" command and that it lists all the module parameters, and their default values. I have no idea why one connecting to a particular AP could be affected by the interrupt method, but I do know that Lenovo boxes sometimes have strange interfacing.

An msi of zero is the default. Nothing needs to be done.

[ghost]

I have a solution for you people.
Let me explain:

The RTL8723be is a 2 antennae card
1 antennae is main,
1 is auxiliary.

Now some manufacturers like hp and lenovo are only attaching one wire to these cards ( at main).

Now this driver uses the secondary auxiliary antennae 2 for signals. Though windows one I think uses the main.

This is the reason why you people are having packet losses and horrible poor signal .

See the pictures here:
http://i68.tinypic.com/52ifxt.jpg

http://i65.tinypic.com/vql568.jpg

[lwfinger]

Are you saying that the Linux driver works better when a single antenna is connected to #2 than when connected to #1?

In my testing, I use both antennas, but I could easily use only 1.

[ghost]

yes my signal is now showing 90% before it was like 30%

[lwfinger]

Thanks for the info. I will test single-antenna configurations.

[ghost]

Thank you,

Also I wanted to clarify something ie, my laptop hp ab030tx doesn't even have second antennae.

At first i was thought about buying a different card then I tried the above and I just had to notify you
( thus ,made the github account)

[braykov]

@lwfinger, please publish a commit you will test with. Let us, people with Lenovo, also test this solution.

[lwfinger]

I do not have one at the moment, but I will publish it here and push a patch to mainline WHEN I have one.

[JerryGorland]

I have a new HP Stream 11 laptop and needed to move the single Wi-Fi cable from the "1" position to the "2" position. The original Windoze install worked fine when it was in the "1" position, but the default driver for the RTL8723BE for Linux didn't. With the moved cable and the rtlwifi_new driver, it works very well. I did this, but not sure if it is still needed:
"To stop Wi-Fi from periodically dropping, I executed echo "options rtl8723be fwlps=N ips=N" | sudo tee /etc/modprobe.d/rtl8723be.conf per http://ubuntuforums.org/showthread.php?t=2243978 and used network manager to set IPV6 to "ignore"."
Refer to http://ubuntuforums.org/showthread.php?t=1543006&page=165&p=13403380#post13403380 for more details. A software fix would be welcome by many, I am sure!

[lwfinger]

Seasons greetings. Yes, I am also sure that a software fix would be welcome; however, it can only be be provided by someone whose hardware has the problem. My systems gets the same throughput and packet loss when I connect antennas to connector 1, 2, or 1 and 2. Thus, it would be impossible for me to know if a change to the antenna diversity routines would help. My previous experiences with remote debugging in any form have been huge time wasters. As a result, this problem will be fixed when you do it.

[inigodm]

Well, I can try it, but I'll need help because I've no experience on developing drivers...

What must I try? where can I change those antenna diversity routines? What must I change to force the driver to use one antenna or the other?

Anyway I bougth my laptop yesterday, so I'll return it seller son (next week) if I cannot fix it... I would not be a huge waste of time in any case :P

[modev32]

any upcoming solution for this issue ?

[lwfinger]

Have you read this thread? I cannot reproduce it, thus I cannot fix it!

[modev32]

Yes i did read it all. so there's no way to force driver to use the right antenna ? because looking at the other solution by switching the connector is something we all can't do :(

Thank you anyway .

[lwfinger]

In the "test" branch, there is some code that attempts to set the antenna. Build that and load the module with "ant_sel=1" or "ant_sel=2" option.

Disclaimer: This code will build, but it is completely untested.

[modev32]

@inigodm there you got a good hint from the owner

[inigodm]

Sorry but its not working, at least in my case....

I've test the following:

1- sudo apt-get install linux-headers-generic build-essential git
2- Download the code (downloaded it as zip because I don't manage git usually :( ):
https://github.com/lwfinger/rtlwifi_new/archive/test.zip
3- cd rtlwifi_new
4- make
5- sudo make install ant_sel=1
6- Reload with:
sudo modprobe -r rtl8723be
sudo modprobe -r rtlwifi
sudo modprobe rtlwifi ant_sel=1
sudo modprobe rtl8723be ant_sel=1

And the same with ant_sel=2....

Im doing something wrong?

:'(

[lwfinger]

The advantage of using git is that when there is a one-line change in the source, only the changes need to be downloaded. With zip, the entire source needs to be downloaded again. As I just changed a few lines, that is the situation now.

The "ant_sel" part is not needed for the "make install" part.

You do not need to run modprobe for rtlwifi. The system knows the dependencies and will take care of them. If you add "-v" to the modprobe command, you will see what I mean.

Module rtlwifi will have no idea what to do with the ant_sel option and just ignore it.

The Realtek engineer was following our discussion, and told me a place in the code that I missed. I just pushed a change.

[inigodm]

Well, I downloaded the code because I didn't knew how to get a branch :p

Also I put the parameter in each order because I didn't find any diference between compile with it or without it and I thougth that I was doing something wrong....

Now I have checkout the branch and update it (I've check the code to be sure, the last changes) and test with ant_sel=1 and 2....

There no change between using one or another in the signal strength :(

(modprobe -r rtl8723be, modprobe rtl8723be ant_sel=X)

Anyway, been a new laptop with a ubuntu that I'll delete anyway (its a new instalation make today, I was ready to return it) and a laptop that I'll return if I cannot fix this, I could let you do whatever you want to do in it via SSH if you want (connecting it via cable to the internet, obviously)....

[mkhuramj]

@ghost is right. I was using Ubuntu 15.04. WiFi signals were week and don't works even from a distance of few feet. I upgraded Ubuntu to 15.10 but this didn't do any thing. Changing wire from connector 1 to connector 2 on the WiFi card did the trick for me. Not perfect but very much acceptable. 90 out of 100 percent is the result for me.

[lwfinger]

Be aware that the setting of signal strength is arbitrary. A number of wireless drivers contain the comment "make it pretty for the customers".

The Realtek engineer says that their group is working on code that will detect which connector has the antenna. Until that is ready, switching the connector is the only option as long as your vendor is not matching the connected pin to the EEPROM on the card.

[marakame]

Good to hear Realtek getting involved in the issue, I tried the antenna option with the test branch in a HP laptop (The star wars one) and it didn't work, the laptop still can't find AP's unless they are extremely close so we'll have to wait for the new code, until then, if there's any useful test that you'd be interested in, I'd be happy to help.

[grenzor]

Hi @lwfinger and others, just chiming in that RTL8723AE users also face this exact same WiFi speed/disconnecting/weak signal problem as the *BE.

Installing the driver (with additional modprobe power options?) does seem to help with stability as it does with the *BE but it still does disconnect and speed is considerably lower than the speed that is on Windows.

When a solution is found, please fix it for both RTL8723AE + RTL8723BE users (as it seems to be the same issue)!

[bgjoseluis]

Hello all,

thanks for your effort.

I bought an HP (Pavilion x360 13-s100ns) laptop with rtl8723be chipset, and I'm pretty sure that I suffering the same issue.

I've tried to install the new module with the "ant_sel" options and it didn't work, the option is not available.

##MODULE UNLOAD##
root@pavilion:~/temporal/rtlwifi_new/rtl8723be# modprobe -rv rtl8723be
rmmod rtl8723be
rmmod rtl_pci
rmmod btcoexist
rmmod rtlwifi
rmmod mac80211
rmmod cfg80211

##MODULE LOAD##
root@pavilion:~/temporal/rtlwifi_new/rtl8723be# modprobe -v rtl8723be ant_sel=1
insmod /lib/modules/4.3.0-1-amd64/kernel/net/wireless/cfg80211.ko
insmod /lib/modules/4.3.0-1-amd64/kernel/net/mac80211/mac80211.ko
insmod /lib/modules/4.3.0-1-amd64/kernel/drivers/net/wireless/rtlwifi/rtlwifi.ko
insmod /lib/modules/4.3.0-1-amd64/kernel/drivers/net/wireless/rtlwifi/rtl_pci.ko
insmod /lib/modules/4.3.0-1-amd64/kernel/drivers/net/wireless/rtlwifi/btcoexist/btcoexist.ko
insmod /lib/modules/4.3.0-1-amd64/kernel/drivers/net/wireless/rtlwifi/rtl8723be/rtl8723be.ko ant_sel=1

#MESSAGES WITH PARAMETER ERROR##
root@pavilion:/etc/modprobe.d# tail /var/log/syslog
Jan 4 19:05:16 pavilion kernel: [14290.044544] cfg80211: (57240000 KHz - 63720000 KHz @ 2160000 KHz), (N/A, 0 mBm), (N/A)
Jan 4 19:05:16 pavilion kernel: [14290.050742] rtl8723be: unknown parameter 'ant_sel' ignored
Jan 4 19:05:16 pavilion kernel: [14290.064995] Using firmware rtlwifi/rtl8723befw.bin
Jan 4 19:05:16 pavilion kernel: [14290.065195] rtl8723be 0000:02:00.0: firmware: direct-loading firmware rtlwifi/rtl8723befw.bin
Jan 4 19:05:16 pavilion systemd[1]: Starting Load/Save RF Kill Switch Status...
Jan 4 19:05:16 pavilion kernel: [14290.065849] ieee80211 phy0: Selected rate control algorithm 'rtl_rc'
Jan 4 19:05:16 pavilion kernel: [14290.066644] rtlwifi: wireless switch is on
Jan 4 19:05:16 pavilion systemd[1]: Started Load/Save RF Kill Switch Status.
Jan 4 19:05:16 pavilion kernel: [14290.069150] rtl8723be 0000:02:00.0 wlp2s0: renamed from wlan0
Jan 4 19:05:19 pavilion ModemManager[615]: Couldn't find support for device at '/sys/devices/pci0000:00/0000:00:1c.4/0000:02:00.0': not supported by any plugin

##MODULE HASH VERIFICATION##
root@pavilion:~/temporal/rtlwifi_new/rtl8723be# md5sum ./rtl8723be.ko
7dc1f6fc46bed1cb559d967be1f8d2dd ./rtl8723be.ko

root@pavilion:/# md5sum /lib/modules/4.3.0-1-amd64/kernel/drivers/net/wireless/rtlwifi/rtl8723be/rtl8723be.ko
7dc1f6fc46bed1cb559d967be1f8d2dd /lib/modules/4.3.0-1-amd64/kernel/drivers/net/wireless/rtlwifi/rtl8723be/rtl8723be.ko

root@pavilion:/# modinfo rtl8723be
filename: /lib/modules/4.3.0-1-amd64/kernel/drivers/net/wireless/rtlwifi/rtl8723be/rtl8723be.ko
firmware: rtlwifi/rtl8723befw.bin
description: Realtek 8723BE 802.11n PCI wireless
license: GPL
author: Realtek WlanFAE wlanfae@realtek.com
author: PageHe page_he@realsil.com.cn
alias: pci:v000010ECd0000B723sv_sd_bc_sc_i*
depends: rtlwifi,rtl_pci,btcoexist,mac80211
vermagic: 4.3.0-1-amd64 SMP mod_unload modversions
parm: swlps:bool
parm: swenc:using hardware crypto (default 0 [hardware]) (bool)
parm: ips:using no link power save (default 1 is open) (bool)
parm: fwlps:using linked fw control power save (default 1 is open) (bool)
parm: msi:Set to 1 to use MSI interrupts mode (default 0) (bool)
parm: debug:Set debug level (0-5) (default 0) (int)
parm: disable_watchdog:Set to 1 to disable the watchdog (default 0) (bool)

@JerryGorland I'm impressed with what you did in the antenna, was it difficult?, why you didn't try to attach a new one in the other connector?.

Thanks.
Jose Luis Barquin Guerola

[modev32]

@bgjoseluis I have the exact same laptop and i have changed the antenna to the other port. that was the only solution i could came up with after a long search with no success.

My comment here #80 (comment) shows how the connector looks and where it locates.. good luck

[lwfinger]

@bgjoseluis Please read carefully. The ant_sel option is in the test branch, not new! In any case it does not work.

[lwfinger]

@grenzor The 8723A chips are very different from the 8723B variety and a fix for one is unlikely to work for the other, but I will keep your request in mind.

[bgjoseluis]

@lwfinger thanks, I've already clone the test branch....

[JerryGorland]

For those with the BE who have moved their connector, my experience was that the default driver in Xubuntu 14.04.3 resulted in good powers but low TX speed (as measured by wavemon). When I built & installed rtlwifi_new, the TX speed went up about 10-fold (per http://askubuntu.com/questions/623001/how-to-install-realtek-rtl8723be-wifi-pcie-wireless-network-adapter).

[pjc123]

So I gather that the gist of all this is that if I don't want to tear apart my brand new HP Stream 11 (Model r010nr) laptop and switch the antenna connections around, is that I need to wait for Realtek to come up with a fix? Fortunately I have a temporary workaround. I installed a TP-Link TL-WN722N USB network adapter (I had to steal it from one of my Raspberry Pis), which works as perfectly in Linux Mint 17.3 as it does in Windows 10 on the same HP Stream laptop (Same exact speed and a solid connection).

[alistairc]

Hi,

I have this issue on a new HP Pavilion too

I've tried the 'test' branch, but it doesn't seem to add the ant_sel param to the module. Looking at rtl8723be/sw.c it doesn't seem to declare that param at all. I'm trying to workout how to add it and wire it in, but I don't really know what I'm doing (I do know a bit of C, but nothing about kernel modules). I'll send a pull request if i figure it out, or if anyone else does it I'm happy to test

[alistairc]

Oh, ignore me, I'm being dumb! Have the wrong branch, doh

[alistairc]

I've tried the correct branch now, and it also doesn't work for me. Tried ant_sel values of 0,1,2, and it seems to make no difference

[lwfinger]

Yes, we already know the option does no good. Obviously, something in the antenna selection code was missed.

[ryanvisual]

I am dealing with range issues on my HP Stream 11. Tried everything but nothing worked, I need a software option, I do not want to open up my laptop and possibly brake it or loose the screws.

[pabloRA]

Hi all, same problem here with a HP Notebook - 14-ac105ns, but before losing warranty.. I would like to ask to those who switched antennas if it makes any effect on Windows, I have a dual boot with W10.
Thanks

[andrew771211]

Hello all,
I have the same problem with my HP250g4
I solved the problem by opening it and solder a piece of coaxial at the place of the second connector terminating with a peeled "whip" (connected at the coax inner) 29 mm long (in order to act as a monopole antenna)
now works stable for higher signals

[lwfinger]

Switch to the rock.new_btcoex branch of this repo, and load rtl8723be with the "ant_sel=2" option. If that does not make your signal strengths be better, then try "ant_sel=1". There should be no need to solder anything on the device. In fact, the ant_sel option should give better signals than your coax.

[andrew771211]

for pabloRA
switching the antennas makes effect on Windows of course! I tested!

[pjc123]

@lwfinger. So the code works now?

[pabloRA]

@andrew771211 thank you for your info, but do you mean it works better also in Windows??

[andrew771211]

No sorry
I have to test yet
What I tested is that I opened the PC and I used the other connector (without any software change), so that for linux worked but for windows no more reception,
just to test that it was an antenna issue
Now I will try the new sw

[pabloRA]

@andrew771211 ok thanks any way
@lwfinger could you to tell us where to find the rock.new_btcoex, tried with little succes

[lwfinger]

You need to "git clone" the repo and "git checkout rock.new_btcoex". I never recommend downloading the zip file from GitHub.com. If you do, and I have to change 1 character in the source, then you need a completely new zip; however, a simple "git pull" handles ALL updates.

Yes, the code works now.

[enriiquee]

@Jonnytj Thank youuu very much!!! Now works perfectly. 😄

[Jonnytj]

@enriiquee - no problem. All credit to @iwfinger for his work on this though.

[quicoju]

I can confirm that with this fix, the wifi card in my ThinkPad E555 works like a charm using ant_sel=1. Just read the whole thread and it's amazing how you guys worked this out. Thank you much!

[Domistr]

lwfinger is the one who worked it out!
 Marek Domanski
+61 (0)416812309

  From: Francisco Jurado <notifications@github.com>

To: lwfinger/rtlwifi_new rtlwifi_new@noreply.github.com
Cc: Domistr marekdo@yahoo.com
Sent: Thursday, 28 January 2016, 17:06
Subject: Re: [rtlwifi_new] Speed of RTL8723be slow because of many lost TCP packages (#28)

I can confirm that with this fix, the wifi card in my ThinkPad E555 works like a charm using ant_sel=1. Just read the whole thread and it's amazing how you guys worked this out. Thank you much!—
Reply to this email directly or view it on GitHub.

[briauc]

At last got round to adding the 50-rtl8723be.conf file. Works a treat. Thanks for all your help especially lwfinger for all your work on this.

[rishabhsethi]

@lwfinger Hi. I have tried the solution with ant_sel=1 and ant_sel=0 keeping ips=0 but the selection of antena doesn't seem to make any difference on the wifi reception. What else could be done?
Thanks

[pabloRA]

Hi, have you tried with ant_sel=2 ?? It worked for me!!

El 02/02/16 a las 08:10, rishabhsethi escribió:

@lwfinger https://github.com/lwfinger Hi. I have tried the solution
with ant_sel=1 and ant_sel=0 keeping ips=0 but the selection of antena
doesn't seem to make any difference on the wifi reception. What else
could be done?
Thanks

—
Reply to this email directly or view it on GitHub
#28 (comment).

Re: Gracias

---

Pablo Romera Alonso

promeraa@gmail.com

[Domistr]

Yes Pablo, it is working fine for me.
M Marek Domanski
+61 (0)416812309

  From: pabloRA <notifications@github.com>

To: lwfinger/rtlwifi_new rtlwifi_new@noreply.github.com
Cc: Domistr marekdo@yahoo.com
Sent: Tuesday, 2 February 2016, 19:10
Subject: Re: [rtlwifi_new] Speed of RTL8723be slow because of many lost TCP packages (#28)

Hi, have you tried with ant_sel=2 ?? It worked for me!!

El 02/02/16 a las 08:10, rishabhsethi escribió:

@lwfinger https://github.com/lwfinger Hi. I have tried the solution
with ant_sel=1 and ant_sel=0 keeping ips=0 but the selection of antena
doesn't seem to make any difference on the wifi reception. What else
could be done?
Thanks

—
Reply to this email directly or view it on GitHub
#28 (comment).

Re: Gracias

---

Pablo Romera Alonso

promeraa@gmail.com

—
Reply to this email directly or view it on GitHub.

[lwfinger]

OK, ant_sel=0 does NOTHING!!!! When you use ant_sel=1, you are saying that the antenna is connected to connector 1. When you use ant_sel=2, that means it is connected to connector 2.

In fact, all of the HP laptops with the incorrectly programmed EEPROM apparently have the EEPROM coded for the antenna to be connected to #1, but actually have it on #2. Use ant_sel=2!!!!!!!!

[rishabhsethi]

@lwfinger I am really sorry, I meant to write ant_sel=2 instead of 0, my bad. I tried setting it to ant_sel=2 and not 0. Also, I just realised that when I see modinfo, it doesn't show ant_sel as a parameter. This is the output I am getting.

filename: /lib/modules/4.2.0-16-generic/updates/dkms/rtl8723be.ko firmware: rtlwifi/rtl8723befw.bin description: Realtek 8723BE 802.11n PCI wireless license: GPL author: Realtek WlanFAE <wlanfae@realtek.com> author: PageHe <page_he@realsil.com.cn> srcversion: 1A35907BCCEF84FE28F988D alias: pci:v000010ECd0000B723sv*sd*bc*sc*i* depends: rtlwifi,rtl_pci,btcoexist,mac80211 vermagic: 4.2.0-16-generic SMP mod_unload modversions parm: swlps:bool parm: swenc:using hardware crypto (default 0 [hardware]) (bool) parm: ips:using no link power save (default 1 is open) (bool) parm: fwlps:using linked fw control power save (default 1 is open) (bool) parm: msi:Set to 1 to use MSI interrupts mode (default 0) (bool) parm: debug:Set debug level (0-5) (default 0) (int) parm: disable_watchdog:Set to 1 to disable the watchdog (default 0) (bool)

This is what I have set in my conf file:
options rtl8723be ips=0 msi=0 fwlps=0 swlps=0 swenc=Y

Just to clarify, my problem is that I can connect to wifi if it is placed nearby but majority of the networks are not visible.

Please tell me what else I could try.

Thanks a lot for helping.

[pjc123]

For one thing you didn't select the antenna in the config file:

ant_sel=2

or

ant_sel=1

And reboot after you are done.

I use only "options rtl8723be ant_sel=2 ips=0" myself and it does the trick. And I have to say this, without the quotes.

[rishabhsethi]

@pjc123 I had tried that before with no avail and later realised that my there is no parameter for ant_sel. Does yours show ant_sel as a parameter when you run modinfo?

Thanks!

[pjc123]

I am running that laptop under windows currently. If I have some time
I will try it later today.

On 2/2/2016 11:05 AM, rishabhsethi wrote:

@pjc123 https://github.com/pjc123 I had tried that before with no
avail and later realised that my there is no parameter for ant_sel.
Does yours show ant_sel as a parameter when you run modinfo?

Thanks!

—
Reply to this email directly or view it on GitHub
#28 (comment).

[rishabhsethi]

@pjc123 and @lwfinger Thanks a lot for your help. It's working now. I reinstalled it again and set ant_sel=2 and rebooted.

@lwfinger You are awesome.

[vstress]

Excellent! This post was incredibly helpful!

Thanks lwfinger and all the others also involved.

Now to resolve a bloody hardware microphone issue that I have just reared it's head through actually having wireless internet and trying to call people...

[lwfinger]

That is what is called "progress".

[nukedathlonman]

Finally getting around to doing up my new HP laptop with Kubuntu when I discovered I had this issue. Installed your updated driver, and 100% smooth sailing now that I've ant_set=2. I did not have to use any other parameters.

[j2schmit]

It worked for me!!! HP 15t on Ubuntu 15.10
Note that I did have to create the file with "ant_sel=2". Typing it in manually each time into terminal wasn't working.
Thanks for the tremendous effort!

[enriiquee]

@lwfinger Thank you for your contributions. I fixed the problems with the WiFi, but now at 2-3 minutes of connection, the wireless network disappears and disconnects.

Do you know what could be the problem?

[laithshadeed]

in my case software crypto solve it
echo 'options rtl8723be swenc=1' | sudo tee /etc/modprobe.d/rtl8723be.conf
sudo modprobe -r rtl8723be && sudo modprobe rtl8723be

default was 0:
modinfo -p rtl8723be | grep swenc
swenc:Set to 1 for software crypto (default 0)

[clsco]

@lwfinger Hello Sir thank you for your awesome work on rtl wifi you saved a lot of people me included, 2 years without wifi dude, now it's perfect, thank you ! Best regards from Belgium ;-) keep up the good work

[georgeanz]

I am using the Fedora 23 distro.

I find the driver works, however the /etc/modprobe.d directory only
seems to be used when doing a manual module load. Putting the same
rtl8723be.conf file in /usr/lib/modprobe.d works on boot, while the
/etc... location does not.

I am not sure how modinfo works, but if it gets 'live' info from the
driver, it would be nice if it indicated which options the driver is
currently using. I think modinfo/the driver should also indicate the
driver version.

Fedora uses signed modules. This means I have to rebuild the kernel (as
well as the driver) each time it is updated. Is there any hope that
these fixes will get into the Fedora distro and if so, when?

And least I forget, your work has allowed me to use my new HP360. Thank
you very much.

George Anzinger george@wildturkeyranch.net

[lwfinger]

Most distros get their module parameters from /etc/modprobe.d/. Apparently Fedora 23 is one of them that does not. Loading the module is the same no matter if the kernel does it when the bus devices are scanned, or when a module is manually loaded.

The utility modinfo gets its information from the driver file, not from the loaded version. There is no way to scan the version in memory to see what options are loaded.

Linux does not really use driver versions. In particular, Linus Torvalds would have a fit if I submitted patches that updated a driver version.

If you want to submit patches to sign the modules, I will incorporate them. The patch to add antenna selection to the mainline kernel was submitted last week. The earliest it would be added will be kernel 4.7. I did give it the notation for it to be backported to all stable kernels 4.0 or newer. I would not expect it to make it into a Fedora kernel for 3-4 months.

[georgeanz]

On 03/19/16 22:27, lwfinger wrote:

Most distros get their module parameters from /etc/modprobe.d/.
Apparently Fedora 23 is one of them that does not. Loading the module
is the same no matter if the kernel does it when the bus devices are
scanned, or when a module is manually loaded.

This leads to an interesting observation. When I loaded the driver
manually I did see the antenna info being picked up prior to putting the
/lib/modprobe.d location. I have also noticed that sometimes the driver
does not work. For this reason I wrote a short 3 line script:
#! /bin/sh
sudo modprobe -vr ...
sudo modprobe -r ...

This fixes the problem. Of course, one then wonders why. I think I
have noticed others on the list saying that things worked fine for a
while and then quit. I find myself wondering if the driver is getting
wedged in some way and what I noticed in using the /lib/modeprobe.d was
just a random outcome.

The utility modinfo gets its information from the driver file, not
from the loaded version. There is no way to scan the version in memory
to see what options are loaded.

Linux does not really use driver versions. In particular, Linus
Torvalds would have a fit if I submitted patches that updated a driver
version.

I would be temped to put the last modify date somewhere in that info (it
does included the author after all) but then Linus might throw a fit at
that as well. One is then left with checksums to figure out what driver
is in uses.

Long ago, in a land far away, I was doing work for HP on a Fortran 4
compiler. I put the last change date in the info line it printed with
the number of errors at the end of the compile. Some time later, but
prior to release, I got a bug report from the field with a listing
showing a date for a version that was yet to be released. The detective
work was figuring out how this version got out of the lab, the bug
having been found and fixed prior to the report.

If you want to submit patches to sign the modules, I will incorporate
them.

I think this requires a key that is generated when the kernel is built.
Understandably, Red Hat will not make this key available.

On the other hand, after reading the kernel doc file on module signing,
it turns out that module signing can be compiled into the kernel in such
a way that it can be turned on/off with a kernel parameter in the boot
line. At least with the current kernel, this is the way it is
compiled. As long as CONFIG_MODULE_SIG_FORCE is not set
enforcemodulesig=1 is needed on the kernel command line to enforce signing.

The patch to add antenna selection to the mainline kernel was
submitted last week. The earliest it would be added will be kernel
4.7. I did give it the notation for it to be backported to all stable
kernels 4.0 or newer. I would not expect it to make it into a Fedora
kernel for 3-4 months.

Thank you. I will use modinfo. (looking for the ant... option) to see
when it arrives.

Again, thank you for your work. It has saved me a lot of work that
would have diverted me from other work.

George

—
You are receiving this because you commented.
Reply to this email directly or view it on GitHub
#28 (comment)

George Anzinger george@wildturkeyranch.net

[ArcEye]

Thank you very much for this repo.

I have got my completely dead HP Pavillion 15-AK085SA working on wifi, using the replacement modules and ant_set=2 on a 4.1.13-rt15 kernel running on Jessie.

I still have range issues that are not present using windoze. Currently solving using a homeplug extender if more than 10m away from the router

The card takes about 60 secs at boot to connect to wifi and emits a continuous stream of errors to /var/log/messages, which makes tail unusable for any other purpose 😦
But other than that it is usable.

Will try the software encryption setting later to see if that improves anything

Thank you too HP and Realtek, for screwing up something very simple to get right 😜

[ArcEye]

Update:
On HP Pavillion 15-AK085S

Added the swenc=1 option to my /etc/modprobe.d/50-rtl8723be.conf file
Full line is now
options rtl8723be ips=0 ant_sel=2 swenc=1

This appears to have improved performance when at a distance from the router.
The reported signal strength is no different, that was not the problem, it was as noted previously that away from the router, it seemed unable to resolve packets and took a long time rendering pages in a browser etc.

I can now use my laptop in the kitchen at a quoted 85 - 71% signal strength in wicd, with no appreciable drop in speed from that when in the same room as the router (when used for browsing anyway).

However broadband speed tests:
1.5m from the router - 33.1Mb/s down 7.6 Mb/s up
Kitchen ( 10m & several brick walls away)
6.9Mb/s down and 7.4Mb/s up

So there is still an issue, just not as much of one as previously.

The card takes about 60 secs at boot to connect to wifi and emits a continuous stream of errors to /var/log/messages, which makes tail unusable for any other purpose 😦

and here is a 1 second excerpt

Apr 18 13:51:11 I7-Laptop kernel: [ 1649.966569] pcieport 0000:00:1c.5: AER: Multiple Corrected error received: id=00e5
Apr 18 13:51:11 I7-Laptop kernel: [ 1649.967230] pcieport 0000:00:1c.5: AER: Corrected error received: id=00e5
Apr 18 13:51:11 I7-Laptop kernel: [ 1649.967247] pcieport 0000:00:1c.5: AER: Corrected error received: id=00e5
Apr 18 13:51:11 I7-Laptop kernel: [ 1650.064999] pcieport 0000:00:1c.5: AER: Multiple Corrected error received: id=00e5
Apr 18 13:51:11 I7-Laptop kernel: [ 1650.065683] pcieport 0000:00:1c.5: AER: Corrected error received: id=00e5
Apr 18 13:51:11 I7-Laptop kernel: [ 1650.066193] pcieport 0000:00:1c.5: AER: Multiple Corrected error received: id=00e5
Apr 18 13:51:11 I7-Laptop kernel: [ 1650.066867] pcieport 0000:00:1c.5: AER: Corrected error received: id=00e5
Apr 18 13:51:11 I7-Laptop kernel: [ 1650.066877] pcieport 0000:00:1c.5: AER: Corrected error received: id=00e5
Apr 18 13:51:11 I7-Laptop kernel: [ 1650.066899] pcieport 0000:00:1c.5: AER: Corrected error received: id=00e5
Apr 18 13:51:11 I7-Laptop kernel: [ 1650.067567] pcieport 0000:00:1c.5: AER: Corrected error received: id=00e5
Apr 18 13:51:11 I7-Laptop kernel: [ 1650.167355] pcieport 0000:00:1c.5: AER: Multiple Corrected error received: id=00e5
Apr 18 13:51:11 I7-Laptop kernel: [ 1650.168018] pcieport 0000:00:1c.5: AER: Corrected error received: id=00e5
Apr 18 13:51:11 I7-Laptop kernel: [ 1650.168035] pcieport 0000:00:1c.5: AER: Corrected error received: id=00e5
Apr 18 13:51:11 I7-Laptop kernel: [ 1650.270365] pcieport 0000:00:1c.5: AER: Multiple Corrected error received: id=00e5
Apr 18 13:51:11 I7-Laptop kernel: [ 1650.271686] pcieport 0000:00:1c.5: AER: Corrected error received: id=00e5
Apr 18 13:51:11 I7-Laptop kernel: [ 1650.272326] pcieport 0000:00:1c.5: AER: Corrected error received: id=00e5
Apr 18 13:51:11 I7-Laptop kernel: [ 1650.272333] pcieport 0000:00:1c.5: AER: Corrected error received: id=00e5
Apr 18 13:51:11 I7-Laptop kernel: [ 1650.272351] pcieport 0000:00:1c.5: AER: Multiple Corrected error received: id=00e5
Apr 18 13:51:11 I7-Laptop kernel: [ 1650.273072] pcieport 0000:00:1c.5: AER: Multiple Corrected error received: id=00e5
Apr 18 13:51:11 I7-Laptop kernel: [ 1650.273816] pcieport 0000:00:1c.5: AER: Multiple Corrected error received: id=00e5
Apr 18 13:51:11 I7-Laptop kernel: [ 1650.274479] pcieport 0000:00:1c.5: AER: Corrected error received: id=00e5
Apr 18 13:51:11 I7-Laptop kernel: [ 1650.274496] pcieport 0000:00:1c.5: AER: Corrected error received: id=00e5
Apr 18 13:51:11 I7-Laptop kernel: [ 1650.372823] pcieport 0000:00:1c.5: AER: Multiple Corrected error received: id=00e5
Apr 18 13:51:11 I7-Laptop kernel: [ 1650.373995] pcieport 0000:00:1c.5: AER: Multiple Corrected error received: id=00e5
Apr 18 13:51:11 I7-Laptop kernel: [ 1650.374635] pcieport 0000:00:1c.5: AER: Corrected error received: id=00e5
Apr 18 13:51:11 I7-Laptop kernel: [ 1650.374642] pcieport 0000:00:1c.5: AER: Corrected error received: id=00e5
Apr 18 13:51:11 I7-Laptop kernel: [ 1650.374660] pcieport 0000:00:1c.5: AER: Corrected error received: id=00e5
Apr 18 13:51:11 I7-Laptop kernel: [ 1650.375408] pcieport 0000:00:1c.5: AER: Multiple Corrected error received: id=00e5
Apr 18 13:51:11 I7-Laptop kernel: [ 1650.376066] pcieport 0000:00:1c.5: AER: Corrected error received: id=00e5
Apr 18 13:51:11 I7-Laptop kernel: [ 1650.376083] pcieport 0000:00:1c.5: AER: Corrected error received: id=00e5
Apr 18 13:51:11 I7-Laptop kernel: [ 1650.474895] pcieport 0000:00:1c.5: AER: Multiple Corrected error received: id=00e5
Apr 18 13:51:11 I7-Laptop kernel: [ 1650.475562] pcieport 0000:00:1c.5: AER: Corrected error received: id=00e5
Apr 18 13:51:11 I7-Laptop kernel: [ 1650.475580] pcieport 0000:00:1c.5: AER: Corrected error received: id=00e5
Apr 18 13:51:11 I7-Laptop kernel: [ 1650.476224] pcieport 0000:00:1c.5: AER: Corrected error received: id=00e5
Apr 18 13:51:11 I7-Laptop kernel: [ 1650.476241] pcieport 0000:00:1c.5: AER: Corrected error received: id=00e5
Apr 18 13:51:11 I7-Laptop kernel: [ 1650.577296] pcieport 0000:00:1c.5: AER: Multiple Corrected error received: id=00e5
Apr 18 13:51:11 I7-Laptop kernel: [ 1650.577979] pcieport 0000:00:1c.5: AER: Corrected error received: id=00e5
Apr 18 13:51:11 I7-Laptop kernel: [ 1650.578628] pcieport 0000:00:1c.5: AER: Multiple Corrected error received: id=00e5
Apr 18 13:51:11 I7-Laptop kernel: [ 1650.578647] pcieport 0000:00:1c.5: AER: Multiple Corrected error received: id=00e5
Apr 18 13:51:11 I7-Laptop kernel: [ 1650.579394] pcieport 0000:00:1c.5: AER: Multiple Corrected error received: id=00e5
Apr 18 13:51:11 I7-Laptop kernel: [ 1650.580063] pcieport 0000:00:1c.5: AER: Corrected error received: id=00e5
Apr 18 13:51:11 I7-Laptop kernel: [ 1650.580080] pcieport 0000:00:1c.5: AER: Corrected error received: id=00e5
Apr 18 13:51:11 I7-Laptop kernel: [ 1650.646554] pcieport 0000:00:1c.5: AER: Multiple Corrected error received: id=00e5
Apr 18 13:51:11 I7-Laptop kernel: [ 1650.647219] pcieport 0000:00:1c.5: AER: Corrected error received: id=00e5
Apr 18 13:51:11 I7-Laptop kernel: [ 1650.647237] pcieport 0000:00:1c.5: AER: Corrected error received: id=00e5
Apr 18 13:51:11 I7-Laptop kernel: [ 1650.680159] pcieport 0000:00:1c.5: AER: Multiple Corrected error received: id=00e5
Apr 18 13:51:11 I7-Laptop kernel: [ 1650.680825] pcieport 0000:00:1c.5: AER: Multiple Corrected error received: id=00e5
Apr 18 13:51:11 I7-Laptop kernel: [ 1650.680839] pcieport 0000:00:1c.5: AER: Corrected error received: id=00e5
Apr 18 13:51:11 I7-Laptop kernel: [ 1650.680854] pcieport 0000:00:1c.5: AER: Corrected error received: id=00e5
Apr 18 13:51:11 I7-Laptop kernel: [ 1650.681504] pcieport 0000:00:1c.5: AER: Corrected error received: id=00e5
Apr 18 13:51:11 I7-Laptop kernel: [ 1650.681511] pcieport 0000:00:1c.5: AER: Corrected error received: id=00e5
Apr 18 13:51:11 I7-Laptop kernel: [ 1650.681528] pcieport 0000:00:1c.5: AER: Corrected error received: id=00e5
Apr 18 13:51:11 I7-Laptop kernel: [ 1650.682188] pcieport 0000:00:1c.5: AER: Corrected error received: id=00e5
Apr 18 13:51:11 I7-Laptop kernel: [ 1650.682206] pcieport 0000:00:1c.5: AER: Corrected error received: id=00e5
Apr 18 13:51:11 I7-Laptop kernel: [ 1650.682918] pcieport 0000:00:1c.5: AER: Multiple Corrected error received: id=00e5
Apr 18 13:51:11 I7-Laptop kernel: [ 1650.683582] pcieport 0000:00:1c.5: AER: Corrected error received: id=00e5
Apr 18 13:51:11 I7-Laptop kernel: [ 1650.683599] pcieport 0000:00:1c.5: AER: Corrected error received: id=00e5
Apr 18 13:51:11 I7-Laptop kernel: [ 1650.782281] pcieport 0000:00:1c.5: AER: Multiple Corrected error received: id=00e5
Apr 18 13:51:11 I7-Laptop kernel: [ 1650.782937] pcieport 0000:00:1c.5: AER: Multiple Corrected error received: id=00e5
Apr 18 13:51:11 I7-Laptop kernel: [ 1650.782973] pcieport 0000:00:1c.5: AER: Multiple Corrected error received: id=00e5
Apr 18 13:51:11 I7-Laptop kernel: [ 1650.783651] pcieport 0000:00:1c.5: AER: Corrected error received: id=00e5
Apr 18 13:51:11 I7-Laptop kernel: [ 1650.784355] pcieport 0000:00:1c.5: AER: Multiple Corrected error received: id=00e5
Apr 18 13:51:11 I7-Laptop kernel: [ 1650.785014] pcieport 0000:00:1c.5: AER: Corrected error received: id=00e5
Apr 18 13:51:11 I7-Laptop kernel: [ 1650.785030] pcieport 0000:00:1c.5: AER: Corrected error received: id=00e5
Apr 18 13:51:11 I7-Laptop kernel: [ 1650.884493] pcieport 0000:00:1c.5: AER: Multiple Corrected error received: id=00e5
Apr 18 13:51:11 I7-Laptop kernel: [ 1650.885162] pcieport 0000:00:1c.5: AER: Corrected error received: id=00e5
Apr 18 13:51:11 I7-Laptop kernel: [ 1650.885840] pcieport 0000:00:1c.5: AER: Corrected error received: id=00e5
Apr 18 13:51:11 I7-Laptop kernel: [ 1650.885859] pcieport 0000:00:1c.5: AER: Corrected error received: id=00e5
Apr 18 13:51:11 I7-Laptop kernel: [ 1650.886500] pcieport 0000:00:1c.5: AER: Multiple Corrected error received: id=00e5
Apr 18 13:51:11 I7-Laptop kernel: [ 1650.886506] pcieport 0000:00:1c.5: AER: Corrected error received: id=00e5
Apr 18 13:51:11 I7-Laptop kernel: [ 1650.886524] pcieport 0000:00:1c.5: AER: Corrected error received: id=00e5
Apr 18 13:51:11 I7-Laptop kernel: [ 1650.887239] pcieport 0000:00:1c.5: AER: Multiple Corrected error received: id=00e5
Apr 18 13:51:11 I7-Laptop kernel: [ 1650.887901] pcieport 0000:00:1c.5: AER: Corrected error received: id=00e5
Apr 18 13:51:11 I7-Laptop kernel: [ 1650.887917] pcieport 0000:00:1c.5: AER: Corrected error received: id=00e5

[lwfinger]

I do not expect that PCI device 0000:00:1c.5 has anything to do with the wifi card, but post the output of 'lspci -nn' so that we can see your bus layout.

[ArcEye]

No, you are right, it is a PCI bridge, because it came up throughout the wifi errors I just assumed the origin.

00:00.0 Host bridge [0600]: Intel Corporation Device [8086:1910] (rev 07)
00:02.0 VGA compatible controller [0300]: Intel Corporation Device [8086:191b] (rev 06)
00:04.0 Signal processing controller [1180]: Intel Corporation Device [8086:1903] (rev 07)
00:14.0 USB controller [0c03]: Intel Corporation Device [8086:a12f] (rev 31)
00:14.2 Signal processing controller [1180]: Intel Corporation Device [8086:a131] (rev 31)
00:16.0 Communication controller [0780]: Intel Corporation Device [8086:a13a] (rev 31)
00:17.0 SATA controller [0106]: Intel Corporation Device [8086:a103] (rev 31)
00:1c.0 PCI bridge [0604]: Intel Corporation Device [8086:a114] (rev f1)
00:1c.5 PCI bridge [0604]: Intel Corporation Device [8086:a115] (rev f1)
00:1c.6 PCI bridge [0604]: Intel Corporation Device [8086:a116] (rev f1)
00:1f.0 ISA bridge [0601]: Intel Corporation Device [8086:a14e] (rev 31)
00:1f.2 Memory controller [0580]: Intel Corporation Device [8086:a121] (rev 31)
00:1f.3 Audio device [0403]: Intel Corporation Device [8086:a170] (rev 31)
00:1f.4 SMBus [0c05]: Intel Corporation Device [8086:a123] (rev 31)
01:00.0 Unassigned class [ff00]: Realtek Semiconductor Co., Ltd. Device [10ec:522a] (rev 01)
02:00.0 Network controller [0280]: Realtek Semiconductor Co., Ltd. RTL8723BE PCIe Wireless Network Adapter [10ec:b723]
03:00.0 Ethernet controller [0200]: Realtek Semiconductor Co., Ltd. RTL8101E/RTL8102E PCI Express Fast Ethernet controller [10ec:8136] (rev 0a)

The actual device from the vendor:model ID looks like

Device 8086:A115 Sunrise Point-H PCI Express Root Port #6

[ArcEye]

pci=nomsi kernel param has taken care of the verbiage regards 0000:00.1c.05

Now just have the 60s wait for LSB job bringing up network interface

At least I can read dmesg now 😆

[ArcEye]

Now just have the 60s wait for LSB job bringing up network interface

For sake of completeness for anyone searching, this one was simple.

When commissioning the laptop Linux partition I used ethernet, as the correct firmware would not be available for the wifi from the distro CD
(Installing Debian Jessie and needed firmware-realtek from sid.)

This caused /etc/network/interfaces to be written with

auto eth0
iface eth0 inet dhcp

whilst this makes no difference to the wicd network manager I use, which ignores /etc/network/interfaces contents and uses its own configuration, the boot process uses /etc/network/ifup.d, which tries to bring up the non-existent ethernet interface listed.

Simply commenting out the reference to eth0 and replacing with

auto wlan0
iface wlan0 inet dchp
        wireless-essid  [my ssid]
        wireless-mode managed

solves the problem and gives a normal boot.

[lwfinger]

If firmware cannot be redistributed, then not having on the installation medium is acceptable. Such an example would be older Broadcom wifi hardware that uses b43 as its driver. On the other hand, all of the Realtek firmware can be redistributed; therefore, not having it available at installation is a bug and should be reported to Debian.

I am glad to hear that your issues are resolved.

[pfee]

Fedora 22 and 23 now have kernels in testing with a patch applied to enable antenna selection using the ant_sel module option.

Here's the Fedora bug report: https://bugzilla.redhat.com/show_bug.cgi?id=1309487

If your readying this in the next few days, you can help by testing the kernel and providing feedback.

F23 kernel-4.4.8-300.fc23 available here: http://koji.fedoraproject.org/koji/buildinfo?buildID=756309
Report your results (give karma) here: https://bodhi.fedoraproject.org/updates/FEDORA-2016-8a1f49149e

F22 kernel-4.4.8-200.fc22 available here: http://koji.fedoraproject.org/koji/buildinfo?buildID=756310
Report your results (give karma) here: https://bodhi.fedoraproject.org/updates/FEDORA-2016-373c063e79

[Ozileyes]

hello everyone I have hp laptop.I am also facing this problem tried all the above steps but still not able to fix that but I found alternate way to connect to Internet just connect usb cable to u r mob and laptop and start usb tethering and u r mobile will do the job of u r wifi chip its a noobs solutions but until proper fix am using it,just posted this might help to ppl like me (newbie) :)

[manihere]

@lwfinger Thank you so much! your github repo worked brilliantly! I did each step and tada!
I wasted so many days and Linuxes to get this issue fixed..U r a genius! Many thanks! :)

[free-soul]

I followed the steps. But when trying to load the driver I am getting this error:

free-soul@yadhu-hp-linux:~/rtlwifi_new$ sudo modprobe -v rtl8723be ant_sel=2
insmod /lib/modules/4.4.0-21-generic/kernel/drivers/net/wireless/realtek/rtlwifi/rtlwifi.ko 
modprobe: ERROR: could not insert 'rtl8723be': Required key not available

git branch says:

  master
* rock.new_btcoex

make says:

make -C /lib/modules/4.4.0-21-generic/build M=/home/free-soul/rtlwifi_new modules
make[1]: Entering directory '/usr/src/linux-headers-4.4.0-21-generic'
  CC [M]  /home/free-soul/rtlwifi_new/base.o
  CC [M]  /home/free-soul/rtlwifi_new/cam.o
  CC [M]  /home/free-soul/rtlwifi_new/core.o
  CC [M]  /home/free-soul/rtlwifi_new/debug.o
  CC [M]  /home/free-soul/rtlwifi_new/efuse.o
  CC [M]  /home/free-soul/rtlwifi_new/ps.o
  CC [M]  /home/free-soul/rtlwifi_new/rc.o
  CC [M]  /home/free-soul/rtlwifi_new/regd.o
  CC [M]  /home/free-soul/rtlwifi_new/stats.o
  LD [M]  /home/free-soul/rtlwifi_new/rtlwifi.o
  CC [M]  /home/free-soul/rtlwifi_new/pci.o
  LD [M]  /home/free-soul/rtlwifi_new/rtl_pci.o
  CC [M]  /home/free-soul/rtlwifi_new/usb.o
  LD [M]  /home/free-soul/rtlwifi_new/rtl_usb.o
  CC [M]  /home/free-soul/rtlwifi_new/btcoexist/halbtc8723b2ant.o
  CC [M]  /home/free-soul/rtlwifi_new/btcoexist/halbtcoutsrc.o
  CC [M]  /home/free-soul/rtlwifi_new/btcoexist/halbtc8192e2ant.o
  CC [M]  /home/free-soul/rtlwifi_new/btcoexist/halbtc8723b1ant.o
  CC [M]  /home/free-soul/rtlwifi_new/btcoexist/halbtc8821a1ant.o
  CC [M]  /home/free-soul/rtlwifi_new/btcoexist/halbtc8821a2ant.o
  CC [M]  /home/free-soul/rtlwifi_new/btcoexist/halbtc8812a1ant.o
  CC [M]  /home/free-soul/rtlwifi_new/btcoexist/halbtc8812a2ant.o
  CC [M]  /home/free-soul/rtlwifi_new/btcoexist/halbtc8812a_ext.o
  CC [M]  /home/free-soul/rtlwifi_new/btcoexist/rtl_btc.o
  LD [M]  /home/free-soul/rtlwifi_new/btcoexist/btcoexist.o
  CC [M]  /home/free-soul/rtlwifi_new/rtl8188ee/dm.o
  CC [M]  /home/free-soul/rtlwifi_new/rtl8188ee/fw.o
  CC [M]  /home/free-soul/rtlwifi_new/rtl8188ee/hw.o
  CC [M]  /home/free-soul/rtlwifi_new/rtl8188ee/led.o
  CC [M]  /home/free-soul/rtlwifi_new/rtl8188ee/phy.o
  CC [M]  /home/free-soul/rtlwifi_new/rtl8188ee/pwrseq.o
  CC [M]  /home/free-soul/rtlwifi_new/rtl8188ee/pwrseqcmd.o
  CC [M]  /home/free-soul/rtlwifi_new/rtl8188ee/rf.o
  CC [M]  /home/free-soul/rtlwifi_new/rtl8188ee/sw.o
  CC [M]  /home/free-soul/rtlwifi_new/rtl8188ee/table.o
  CC [M]  /home/free-soul/rtlwifi_new/rtl8188ee/trx.o
  LD [M]  /home/free-soul/rtlwifi_new/rtl8188ee/rtl8188ee.o
  CC [M]  /home/free-soul/rtlwifi_new/rtl8192c/main.o
  CC [M]  /home/free-soul/rtlwifi_new/rtl8192c/dm_common.o
  CC [M]  /home/free-soul/rtlwifi_new/rtl8192c/fw_common.o
  CC [M]  /home/free-soul/rtlwifi_new/rtl8192c/phy_common.o
  LD [M]  /home/free-soul/rtlwifi_new/rtl8192c/rtl8192c-common.o
  CC [M]  /home/free-soul/rtlwifi_new/rtl8192ce/dm.o
  CC [M]  /home/free-soul/rtlwifi_new/rtl8192ce/fw.o
  CC [M]  /home/free-soul/rtlwifi_new/rtl8192ce/hw.o
  CC [M]  /home/free-soul/rtlwifi_new/rtl8192ce/led.o
  CC [M]  /home/free-soul/rtlwifi_new/rtl8192ce/phy.o
  CC [M]  /home/free-soul/rtlwifi_new/rtl8192ce/rf.o
  CC [M]  /home/free-soul/rtlwifi_new/rtl8192ce/sw.o
  CC [M]  /home/free-soul/rtlwifi_new/rtl8192ce/table.o
  CC [M]  /home/free-soul/rtlwifi_new/rtl8192ce/trx.o
  LD [M]  /home/free-soul/rtlwifi_new/rtl8192ce/rtl8192ce.o
  CC [M]  /home/free-soul/rtlwifi_new/rtl8192cu/dm.o
  CC [M]  /home/free-soul/rtlwifi_new/rtl8192cu/hw.o
  CC [M]  /home/free-soul/rtlwifi_new/rtl8192cu/led.o
  CC [M]  /home/free-soul/rtlwifi_new/rtl8192cu/mac.o
  CC [M]  /home/free-soul/rtlwifi_new/rtl8192cu/phy.o
  CC [M]  /home/free-soul/rtlwifi_new/rtl8192cu/rf.o
  CC [M]  /home/free-soul/rtlwifi_new/rtl8192cu/sw.o
  CC [M]  /home/free-soul/rtlwifi_new/rtl8192cu/table.o
  CC [M]  /home/free-soul/rtlwifi_new/rtl8192cu/trx.o
  LD [M]  /home/free-soul/rtlwifi_new/rtl8192cu/rtl8192cu.o
  CC [M]  /home/free-soul/rtlwifi_new/rtl8192de/dm.o
  CC [M]  /home/free-soul/rtlwifi_new/rtl8192de/fw.o
  CC [M]  /home/free-soul/rtlwifi_new/rtl8192de/hw.o
  CC [M]  /home/free-soul/rtlwifi_new/rtl8192de/led.o
  CC [M]  /home/free-soul/rtlwifi_new/rtl8192de/phy.o
  CC [M]  /home/free-soul/rtlwifi_new/rtl8192de/rf.o
  CC [M]  /home/free-soul/rtlwifi_new/rtl8192de/sw.o
  CC [M]  /home/free-soul/rtlwifi_new/rtl8192de/table.o
  CC [M]  /home/free-soul/rtlwifi_new/rtl8192de/trx.o
  LD [M]  /home/free-soul/rtlwifi_new/rtl8192de/rtl8192de.o
  CC [M]  /home/free-soul/rtlwifi_new/rtl8192ee/dm.o
  CC [M]  /home/free-soul/rtlwifi_new/rtl8192ee/fw.o
  CC [M]  /home/free-soul/rtlwifi_new/rtl8192ee/hw.o
  CC [M]  /home/free-soul/rtlwifi_new/rtl8192ee/led.o
  CC [M]  /home/free-soul/rtlwifi_new/rtl8192ee/phy.o
  CC [M]  /home/free-soul/rtlwifi_new/rtl8192ee/pwrseq.o
  CC [M]  /home/free-soul/rtlwifi_new/rtl8192ee/pwrseqcmd.o
  CC [M]  /home/free-soul/rtlwifi_new/rtl8192ee/rf.o
  CC [M]  /home/free-soul/rtlwifi_new/rtl8192ee/sw.o
  CC [M]  /home/free-soul/rtlwifi_new/rtl8192ee/table.o
  CC [M]  /home/free-soul/rtlwifi_new/rtl8192ee/trx.o
  LD [M]  /home/free-soul/rtlwifi_new/rtl8192ee/rtl8192ee.o
  CC [M]  /home/free-soul/rtlwifi_new/rtl8192se/dm.o
  CC [M]  /home/free-soul/rtlwifi_new/rtl8192se/fw.o
  CC [M]  /home/free-soul/rtlwifi_new/rtl8192se/hw.o
  CC [M]  /home/free-soul/rtlwifi_new/rtl8192se/led.o
  CC [M]  /home/free-soul/rtlwifi_new/rtl8192se/phy.o
  CC [M]  /home/free-soul/rtlwifi_new/rtl8192se/rf.o
  CC [M]  /home/free-soul/rtlwifi_new/rtl8192se/sw.o
  CC [M]  /home/free-soul/rtlwifi_new/rtl8192se/table.o
  CC [M]  /home/free-soul/rtlwifi_new/rtl8192se/trx.o
  LD [M]  /home/free-soul/rtlwifi_new/rtl8192se/rtl8192se.o
  CC [M]  /home/free-soul/rtlwifi_new/rtl8723ae/dm.o
  CC [M]  /home/free-soul/rtlwifi_new/rtl8723ae/fw.o
  CC [M]  /home/free-soul/rtlwifi_new/rtl8723ae/hal_btc.o
  CC [M]  /home/free-soul/rtlwifi_new/rtl8723ae/hal_bt_coexist.o
  CC [M]  /home/free-soul/rtlwifi_new/rtl8723ae/hw.o
  CC [M]  /home/free-soul/rtlwifi_new/rtl8723ae/led.o
  CC [M]  /home/free-soul/rtlwifi_new/rtl8723ae/phy.o
  CC [M]  /home/free-soul/rtlwifi_new/rtl8723ae/pwrseq.o
  CC [M]  /home/free-soul/rtlwifi_new/rtl8723ae/pwrseqcmd.o
  CC [M]  /home/free-soul/rtlwifi_new/rtl8723ae/rf.o
  CC [M]  /home/free-soul/rtlwifi_new/rtl8723ae/sw.o
  CC [M]  /home/free-soul/rtlwifi_new/rtl8723ae/table.o
  CC [M]  /home/free-soul/rtlwifi_new/rtl8723ae/trx.o
  LD [M]  /home/free-soul/rtlwifi_new/rtl8723ae/rtl8723ae.o
  CC [M]  /home/free-soul/rtlwifi_new/rtl8723be/dm.o
  CC [M]  /home/free-soul/rtlwifi_new/rtl8723be/fw.o
  CC [M]  /home/free-soul/rtlwifi_new/rtl8723be/hw.o
  CC [M]  /home/free-soul/rtlwifi_new/rtl8723be/led.o
  CC [M]  /home/free-soul/rtlwifi_new/rtl8723be/phy.o
  CC [M]  /home/free-soul/rtlwifi_new/rtl8723be/pwrseq.o
  CC [M]  /home/free-soul/rtlwifi_new/rtl8723be/pwrseqcmd.o
  CC [M]  /home/free-soul/rtlwifi_new/rtl8723be/rf.o
  CC [M]  /home/free-soul/rtlwifi_new/rtl8723be/sw.o
  CC [M]  /home/free-soul/rtlwifi_new/rtl8723be/table.o
  CC [M]  /home/free-soul/rtlwifi_new/rtl8723be/trx.o
  LD [M]  /home/free-soul/rtlwifi_new/rtl8723be/rtl8723be.o
  CC [M]  /home/free-soul/rtlwifi_new/rtl8821ae/dm.o
  CC [M]  /home/free-soul/rtlwifi_new/rtl8821ae/fw.o
  CC [M]  /home/free-soul/rtlwifi_new/rtl8821ae/hw.o
  CC [M]  /home/free-soul/rtlwifi_new/rtl8821ae/led.o
  CC [M]  /home/free-soul/rtlwifi_new/rtl8821ae/phy.o
  CC [M]  /home/free-soul/rtlwifi_new/rtl8821ae/pwrseq.o
  CC [M]  /home/free-soul/rtlwifi_new/rtl8821ae/pwrseqcmd.o
  CC [M]  /home/free-soul/rtlwifi_new/rtl8821ae/rf.o
  CC [M]  /home/free-soul/rtlwifi_new/rtl8821ae/sw.o
  CC [M]  /home/free-soul/rtlwifi_new/rtl8821ae/table.o
  CC [M]  /home/free-soul/rtlwifi_new/rtl8821ae/trx.o
  LD [M]  /home/free-soul/rtlwifi_new/rtl8821ae/rtl8821ae.o
  Building modules, stage 2.
  MODPOST 14 modules
  CC      /home/free-soul/rtlwifi_new/btcoexist/btcoexist.mod.o
  LD [M]  /home/free-soul/rtlwifi_new/btcoexist/btcoexist.ko
  CC      /home/free-soul/rtlwifi_new/rtl8188ee/rtl8188ee.mod.o
  LD [M]  /home/free-soul/rtlwifi_new/rtl8188ee/rtl8188ee.ko
  CC      /home/free-soul/rtlwifi_new/rtl8192c/rtl8192c-common.mod.o
  LD [M]  /home/free-soul/rtlwifi_new/rtl8192c/rtl8192c-common.ko
  CC      /home/free-soul/rtlwifi_new/rtl8192ce/rtl8192ce.mod.o
  LD [M]  /home/free-soul/rtlwifi_new/rtl8192ce/rtl8192ce.ko
  CC      /home/free-soul/rtlwifi_new/rtl8192cu/rtl8192cu.mod.o
  LD [M]  /home/free-soul/rtlwifi_new/rtl8192cu/rtl8192cu.ko
  CC      /home/free-soul/rtlwifi_new/rtl8192de/rtl8192de.mod.o
  LD [M]  /home/free-soul/rtlwifi_new/rtl8192de/rtl8192de.ko
  CC      /home/free-soul/rtlwifi_new/rtl8192ee/rtl8192ee.mod.o
  LD [M]  /home/free-soul/rtlwifi_new/rtl8192ee/rtl8192ee.ko
  CC      /home/free-soul/rtlwifi_new/rtl8192se/rtl8192se.mod.o
  LD [M]  /home/free-soul/rtlwifi_new/rtl8192se/rtl8192se.ko
  CC      /home/free-soul/rtlwifi_new/rtl8723ae/rtl8723ae.mod.o
  LD [M]  /home/free-soul/rtlwifi_new/rtl8723ae/rtl8723ae.ko
  CC      /home/free-soul/rtlwifi_new/rtl8723be/rtl8723be.mod.o
  LD [M]  /home/free-soul/rtlwifi_new/rtl8723be/rtl8723be.ko
  CC      /home/free-soul/rtlwifi_new/rtl8821ae/rtl8821ae.mod.o
  LD [M]  /home/free-soul/rtlwifi_new/rtl8821ae/rtl8821ae.ko
  CC      /home/free-soul/rtlwifi_new/rtl_pci.mod.o
  LD [M]  /home/free-soul/rtlwifi_new/rtl_pci.ko
  CC      /home/free-soul/rtlwifi_new/rtl_usb.mod.o
  LD [M]  /home/free-soul/rtlwifi_new/rtl_usb.ko
  CC      /home/free-soul/rtlwifi_new/rtlwifi.mod.o
  LD [M]  /home/free-soul/rtlwifi_new/rtlwifi.ko
make[1]: Leaving directory '/usr/src/linux-headers-4.4.0-21-generic'

make install says:

free-soul@yadhu-hp-linux:~/rtlwifi_new$ sudo make install
make -C /lib/modules/4.4.0-21-generic/build M=/home/free-soul/rtlwifi_new modules
make[1]: Entering directory '/usr/src/linux-headers-4.4.0-21-generic'
  Building modules, stage 2.
  MODPOST 14 modules
make[1]: Leaving directory '/usr/src/linux-headers-4.4.0-21-generic'
Install rtlwifi SUCCESS

and grep -r ant_sel * shows this:

Binary file backup_drivers.tar matches
README.md:Added March 16, 2016: All branches of this repo now support the ant_sel module option
rtl8188ee/dm.h:void rtl88e_dm_ant_sel_statistics(struct ieee80211_hw *hw,
Binary file rtl8188ee/trx.o matches
Binary file rtl8188ee/dm.o matches
rtl8188ee/trx.h:    u8  ant_sel_b:1;
rtl8188ee/trx.h:    u8  ant_sel:1;
rtl8188ee/trx.h:    u8  ant_sel:1;
rtl8188ee/trx.h:    u8  ant_sel_b:1;
rtl8188ee/trx.h:    u32 ant_sela:1;
rtl8188ee/trx.h:    u32 ant_selb:1;
rtl8188ee/trx.c:    rtldm->fat_table.antsel_rx_keep_0 = p_phystRpt->ant_sel;
rtl8188ee/trx.c:    rtldm->fat_table.antsel_rx_keep_1 = p_phystRpt->ant_sel_b;
rtl8188ee/trx.c:            rtl88e_dm_ant_sel_statistics(hw, antsel_tr_mux, 0,
rtl8188ee/dm.c:void rtl88e_dm_ant_sel_statistics(struct ieee80211_hw *hw,
Binary file rtl8188ee/rtl8188ee.ko matches
Binary file rtl8188ee/rtl8188ee.o matches
rtl8192ce/trx.h:    u32 ant_sela:1;
rtl8192ce/trx.h:    u32 ant_selb:1;
rtl8192de/trx.h:    u32 ant_sela:1;
rtl8192de/trx.h:    u32 ant_selb:1;
rtl8192ee/trx.h:    u8 ant_sel_b:1;
rtl8192ee/trx.h:    u8 ant_sel:1;
rtl8192ee/trx.h:    u8 ant_sel:1;
rtl8192ee/trx.h:    u8 ant_sel_b:1;
rtl8192ee/trx.h:    u32 ant_sela:1;
rtl8192ee/trx.h:    u32 ant_selb:1;
rtl8723ae/trx.h:    u32 ant_sela:1;
rtl8723ae/trx.h:    u32 ant_selb:1;
Binary file rtl8723be/rtl8723be.ko matches
rtl8723be/dm.h:void rtl8723be_dm_ant_sel_statistics(struct ieee80211_hw *hw, u8 antsel_tr_mux,
rtl8723be/sw.c: .ant_sel = 0,
rtl8723be/sw.c:module_param_named(ant_sel, rtl8723be_mod_params.ant_sel, int, 0444);
rtl8723be/sw.c:MODULE_PARM_DESC(ant_sel, "Set to 1 or 2 to force antenna number (default 0)\n");
Binary file rtl8723be/sw.o matches
rtl8723be/hw.c: if (mod_params->ant_sel) {
rtl8723be/hw.c:             (mod_params->ant_sel == 1 ? ANT_X2 : ANT_X1);
rtl8723be/hw.c:             (mod_params->ant_sel == 1 ? 0 : 1);
rtl8723be/trx.h:    u8 ant_sel_b:1;
rtl8723be/trx.h:    u8 ant_sel:1;
rtl8723be/trx.h:    u8 ant_sel:1;
rtl8723be/trx.h:    u8 ant_sel_b:1;
rtl8723be/trx.h:    u32 ant_sela:1;
rtl8723be/trx.h:    u32 ant_selb:1;
Binary file rtl8723be/rtl8723be.o matches
rtl8821ae/dm.h:void rtl8821ae_dm_ant_sel_statistics(struct ieee80211_hw *hw,
rtl8821ae/trx.h:    u8  ant_sel_b:1;
rtl8821ae/trx.h:    u8  ant_sel:1;
rtl8821ae/trx.h:    u8  ant_sel:1;
rtl8821ae/trx.h:    u8  ant_sel_b:1;
rtl8821ae/trx.h:    u32 ant_sela:1;
rtl8821ae/trx.h:    u32 ant_selb:1;
wifi.h: int ant_sel;

Am I doing something wrong here or am I missing something? Please help @lwfinger.

[lwfinger]

Turn off secure boot.

[nukedathlonman]

Yea, you got it right.... For system with secure boot enabled, *buntu 16.04 won't load drivers with out a signature. So option one (easiest and lwfinger already suggested it)), disable UEFI Secure boot. Option 2 (the absolute most total PIA way) get the kernel source, update it with the RTL source from here, then compile your own kernel and then further sign it... Suppose I could say option 3, and just use *buntu 15.10 or 15.04....

[ArcEye]

The 3rd option is completely disable UEFI / 'secure boot' and don't use any OS's that require it.

It is nothing more than a microsoft revenue protection scheme, making loading any other OS beyond the capabilities of the majority of computer users, who have to buy computers pre-loaded with microsofts latest bloatware.

[georgeanz]

On 05/26/16 08:46, free-soul wrote:

I followed the steps. But when trying to load the driver I am getting
this error:

|free-soul@yadhu-hp-linux:~/rtlwifi_new$ sudo modprobe -v rtl8723be
ant_sel=2 insmod
/lib/modules/4.4.0-21-generic/kernel/drivers/net/wireless/realtek/rtlwifi/rtlwifi.ko
modprobe: ERROR: could not insert 'rtl8723be': Required key not
available |

You left out the distro. The problem is that your kernel was compiled
to require "signed kernel modules".
The only answer I found is to compile your dirstro's kernel with the
signed kernel module option turned off.

You might also see if the newer kernels from your distro have relaxed
this requirement. Early Fedora 23 kernels required it while newer ones
have made it optional.

A google search on "modprobe required key not available" will give you a
lot of detail on this.

And, no, the required key is not to be found as that would defeat the
purpose of signing.

George Anzinger george@wildturkeyranch.net

[georgeanz]

I built and installed the code on a HP x360. I am assuming the antenna
problem was the required fix. On booting the wifi comes up and seems to
work well.

The problem is, if I let the system sleep (suspend, not hibernate),
about 75% of the time wifi does not reconnect.
Sometimes I can fix this by disabling wifi and re-enableing it. If this
fails I run a script that removes the module and reinstalls it:

#!/bin/sh
sudo modprobe -rv rt8723be
sleep 2
sudo modprobe -v rt8723be

Most of the time this works, however, lately running the script has
crashed the system (no response, reboot required).

If I understood git better I would provide the version I am using. The
best I can do is to say I asked git to update on 6/18/16. The kernel is
4.4.9-300.fc23.x86_64

To me it looks like the driver is failing to reset something on waking
from suspend.

George Anzinger george@wildturkeyranch.net

[lwfinger]

You can always see the latest commit using 'git log'.

I'm not sure it is the driver. On my openSUSE Leap 42.1 system, the connection is reliably redone after restore from suspend. What I suspect is that your user-space components are not restoring the connection. I use the KDE desktop and control the connection with NetworkManager.

You should be able to add scripts to the suspend and resume steps, but that is also distro dependent.

[georgeanz]

On 07/18/16 14:20, lwfinger wrote:

You can always see the latest commit using 'git log'.

Looks like 6/10/16 at 10:52:59

I'm not sure it is the driver. On my openSUSE Leap 42.1 system, the
connection is reliably redone after restore from suspend. What I
suspect is that your user-space components are not restoring the
connection. I use the KDE desktop and control the connection with
NetworkManager.

I am using fedpra LXDE. It puts a widget in the panel. When things are
failing, the widget has two little circles chasing each other in a tight
circle. On success it changes to a set of blue bars indicating the
signal level (a stair case if you will). When the circles are active a
mouse 1 click shows all the possible connections and even shows that it
is connected to my wifi, but the chase continues and no traffic is
passed. Mouse 3 on the widget I have the option to disable networking
or the disable wifi (as well as a few other options). About 10% of the
time, if I disable wifi and the re-enable the connection is restored. I
guess what I am saying is that its not that it is not trying to bring up
wifi again, but that it is trying and failing. Only after trying the
down/up with the widget and failing do I try the uninstall, reinstall of
the module. (I suspect that the system crash I sometimes experience is
due to uninstalling an active driver. I try not to do that.)

Just in case this matters, I do not password protect my wifi, but rather
the router (used as a wofo access point and not a router) is configured
to only allow selected MAC address to connect. One other thing, the IP
address is not provided by the router, but by a raspberry pi running
dnsmasq. This allows me to address all the devices by name.

I suppose the problem could be in one of these, but all the android
devices and another linux box just work.

You should be able to add scripts to the suspend and resume steps, but
that is also distro dependent.

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
#28 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/AQBr5CkePhwQRBkQ7TDc4HLo4FVmGzvvks5qW-AYgaJpZM4DVyGK.

George Anzinger george@wildturkeyranch.net

[manihere]

Hi Everyone,

This is the best fix available..Confirmed working on Ubuntu however there was random frequent breakdowns. Tried it on fedora but the make command gives errors.
Now installed elementary OS 0.3.2 Freya (64-bit) and did as @lwfinger suggested and Wifi works as a charm, the wifi issues reduced to once a day/2 days. Really happy so i am gonna summarize you:

A. Install elementaryOS
B. Follow the exact process:

git clone git://github.com/lwfinger/rtlwifi_new.git
cd rtlwifi_new
git checkout rock.new_btcoex
make
sudo make install

Reboot. After the system comes up:
sudo modprobe -rv rtl8723be
sudo modprobe -v rtl8723be ant_sel=1

Now test. If that still does not work, then try

sudo modprobe -rv rtl8723be
sudo modprobe -v rtl8723be ant_sel=2

Important:
One or the other should work. Once you know, then add that ant_sel part to the options when rtl8723be is loaded:
As root and using your favorite editor, create a file named /etc/modprobe.d/50-rtl8723be.conf. In that file, add a single line that says "options rtl8723be ips=0 ant_sel=2". That will do the antenna selection and disable power saving. The latter has been found to improve connection reliability.

Note: Turn off Fast Boot option in Windows 10-> COntrol Panel ->Power Options -> Choose what Power Button does -> FastBoot(uncheck all options), if you face random wifi disconnection.
Note: Do not use blankspace in folder name or the make command wont compile.

Hope this helps :)

[ashish289]

@manihere @lwfinger this is the best solution full wifi speed , no disconnection ,wifi switching off all problem solved thanks
HP rtl8723be

[pjc123]

I just wanted to confirm that this is required and also works with the HP Stream 11 and Linux Mint 18 (Was previously using it with Mint 17.3). I was hoping that this would be fixed by now in Linux, but I see it will not be added until a later kernel.

[lwfinger]

If you are talking about the "ant_sel" option, it was fixed in kernel 4.6. For your info, mainline is now working on kernel 4.8. If Mint still has kernels older than 4.6, that is not my fault. If you are talking about that abominable "fast boot" option in Windows, how could Linux ever fix that?

[pjc123]

Yes, I am totally aware of all that.  I was just letting people know it was necessary to apply these drivers on the HP Stream and Mint 18 (The antenna issue), because of what you stated, the kernel is older (4.0 as I recall) on Mint 18. I am really thankful for the work involved im supplying these drivers and making my laptop usable with Limux..
Sent from Yahoo Mail on Android

On Mon, Aug 15, 2016 at 11:47 AM, lwfingernotifications@github.com wrote:
If you are talking about the "ant_sel" option, it was fixed in kernel 4.6. For your info, mainline is now working on kernel 4.8. If Mint still has kernels older than 4.6, that is not my fault. If you are talking about that abominable "fast boot" option in Windows, how could Linux ever fix that?

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or mute the thread.

[georgeanz]

I have yet to find a Fedora kernel with the updated drivers (last
attempt about 1.5 weeks ago). This is not much of a bother as I can
easily replace them once the new kernel is installed. (It would be good
if I could remember to do the git update first:( ). So, from me, many
thanks.

Just one thing: Took a trip to see my grandson and thus used a wifi
with a password (I use MAC address only, at home). Almost every time my
HP360 woke up (from sleep) the wifi would fail to do a proper
connection. It seemed to find the server but, it would appear to not be
doing the password handshake. My "fixwifi" code caused immediate
connection with out the need to re-enter the password so the password is
known by the system, it just appeared to not be passed to the server.

The "fixwifi" code is s script that uses modprobe to uninstall and then
reinstall the drivers:

#!/bin/sh
echo "remove"
sudo modprobe -rv rtl8723be
sleep 1
echo "now restart"
sudo modprobe -v rtl8723be#!/bin/sh

George Anzinger george@wildturkeyranch.net

[jspolancor]

Thank you very much @lwfinger this works perfectly on my hp 14ac116la.

[grenzor]

Hi @lwfinger, wondering if it's possible to implement a similar fix for RTL8723AE users. I faced the exact same issues that users of RTL8723BE had and judging from the positive responses from your antenna fix it looks like a similar fix could also solve RTL8723AE internet slowness/connectivity problems!

[lwfinger]

You first need to prove to me that your problem is due to low signal strength before I attempt an antenna select code change.

[grenzor]

user@user ~ $ iw dev wlan0 station dump
Station dc:1a:41:b6:1c:56 (on wlan0)
inactive time: 124 ms
rx bytes: 6401119
rx packets: 9759
tx bytes: 534841
tx packets: 4490
tx retries: 0
tx failed: 0
signal: -72 dBm
signal avg: -72 dBm
tx bitrate: 72.2 MBit/s MCS 7 short GI
authorized: yes
authenticated: yes
preamble: long
WMM/WME: yes
MFP: no

Is this helpful to determine signal strength? I'm not sure what kind of info you need, just let me know a what I need to look for/what command I need to run

[lwfinger]

Does "signal: -72 dBm" seem like a clue? If that AP is closer than 20 m, then you are not using an antenna! Investigate the "ant_sel=X" option, where X might be 1 or 2.

[grenzor]

I was under the impression the "ant_sel=" option was only available for RTL8723be. Will it take effect under RTL8723ae?

[lwfinger]

No, it will not. I did not read the thread before I replied.

It is possible that you have an RTL8723AE with the same antenna issue. What is your device, and is it possible to gain access to the wifi card?

[lwfinger]

At first glance, it seems easy to implement ant_sel for the RTL8723AE.

Please do a 'git pull' and try the ant_sel options. When you report back, please open a new issue so that the title doesn't confuse me again.

[grenzor]

By device do you mean my computer? Currently using a laptop connecting wirelessly to a router that is about 5-10m away. Not sure how to see if I have access to the wifi card (unless you mean just if I can connect to the internet using my laptop which I can)

My AP (wlan0) station dump is the one I posted above. Some more (maybe) helpful info from iwconfig:
Retry short limit:7 RTS thr=2347 B Fragment thr:off
Power Management:off
Link Quality=38/70 Signal level=-68 dBm

EDIT: New thread: #188

[hsali]

This driver worked. I set ant_set=1 for this driver for my HP Pavilion 8093 rtl8723be driver.