Wifi being dropped randomly on T520

[TihSon]

The problem is just as I've stated. The wifi works but will disconnect randomly, and when it does disconnect the status remains displayed as connected. Disconnecting and reconnecting solves the problem until the next disconnect, which can be a few seconds, or a few hours, later. Coming back from sleep is also unpredictable. This issue appeared when I upgraded from 16 to 17, and I should mention the wifi under 16 was rock solid. I have found threads discussing my network card, but so far nothing has helped, and Google has not been my friend on this one.

Thank you in advance to anyone who can point me in the correct direction. Here is the data ...

uname -a
Linux michael-ThinkPad-T520 3.13.0-24-generic #47-Ubuntu SMP Fri May 2 23:31:42 UTC 2014 i686 i686 i686 GNU/Linux

MintWifi.py
* I. scanning WIFI PCI devices...
-- Realtek Semiconductor Co., Ltd. RTL8188CE 802.11b/g/n WiFi Adapter (rev 01)
==> PCI ID = 10ec:8176 (rev 01)
-------------------------
* II. querying ndiswrapper...
-------------------------
* III. querying iwconfig...
wlan0 IEEE 802.11bgn ESSID:"SAM"
Mode:Managed Frequency:2.447 GHz Access Point: 00:25:9C:3B:CF:A4
Bit Rate=18 Mb/s Tx-Power=20 dBm
Retry long limit:7 RTS thr=2347 B Fragment thr:off
Encryption key:off
Power Management:off
Link Quality=58/70 Signal level=-52 dBm
Rx invalid nwid:0 Rx invalid crypt:0 Rx invalid frag:0
Tx excessive retries:0 Invalid misc:16 Missed beacon:0

lo no wireless extensions.

eth0 no wireless extensions.

-------------------------
* IV. querying ifconfig...
eth0 Link encap:Ethernet HWaddr f0f1:95:f3:37
UP BROADCAST MULTICAST MTU:1500 Metric:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:0 (0.0 B) TX bytes:0 (0.0 B)
Interrupt:20 Memory:f2600000-f2620000

lo Link encap:Local Loopback
inet addr:127.0.0.1 Mask:255.0.0.0
inet6 addr: ::1/128 Scope:Host
UP LOOPBACK RUNNING MTU:65536 Metric:1
RX packets:10305 errors:0 dropped:0 overruns:0 frame:0
TX packets:10305 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:1129504 (1.1 MB) TX bytes:1129504 (1.1 MB)

wlan0 Link encap:Ethernet HWaddr 38:59:f9:e2:03:ca
inet addr:192.168.1.109 Bcast:192.168.1.255 Mask:255.255.255.0
inet6 addr: fe80::3a59:f9ff:fee2:3ca/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:415120 errors:0 dropped:0 overruns:0 frame:0
TX packets:343714 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:430155795 (430.1 MB) TX bytes:56706416 (56.7 MB)

-------------------------
* V. querying DHCP...
-------------------------
* VI. querying nslookup google.com...
Server: 64.59.160.13
Address: 64.59.160.13#53

Non-authoritative answer:
Name: google.com
Address: 173.194.33.135
Name: google.com
Address: 173.194.33.134
Name: google.com
Address: 173.194.33.131
Name: google.com
Address: 173.194.33.132
Name: google.com
Address: 173.194.33.142
Name: google.com
Address: 173.194.33.128
Name: google.com
Address: 173.194.33.133
Name: google.com
Address: 173.194.33.130
Name: google.com
Address: 173.194.33.137
Name: google.com
Address: 173.194.33.129
Name: google.com
Address: 173.194.33.136

[JeremyB]

I would try a google search for rtl8188ce site:ubuntuforums.org
And see what can be found, look for posts from July of this year and newer. I know there are some power management options that can be used

[TihSon]

Thank you. I will check that out.

[TihSon]

No good. Still looking for the answer.

[TihSon]

I've just upgraded my kernel from 2.13.0-24 to 3.13.0-27. The information I found on the -27 kernel seems to be telling me it resolves the issue with my network card. Here's hoping. I will report back in a few days to report on findings.

[Roland]

Does it help you to set your Wifi router to a fixed channel (1-13) instead of a automatically choosen channel? I am trying this solution for me now.

[JeremyB]

Post the results from this command

Code: Select all

 for p in /sys/module/rtl8188ce/parameters/*; do echo $p; cat $p; done

[TihSon]

The kernel upgrade seemed to have helped, but not permanently. It was odd. Initially it was great, but after a short while it seemed to forget how to wake up correctly sometimes, and then it began to lose connections again as it did before. Overall it seems better, but not much. As for the channels, I set that to a single channel based on the best readings in the area. I usually check about once every six months, and I changed it just the other day. Nice strong signal, and I'm all alone.

Also, the result of that command was ...

/sys/module/rtl8188ce/parameters/*
cat: /sys/module/rtl8188ce/parameters/*: No such file or directory

I will keep digging. Thanks everyone.

[JeremyB]

The kernel upgrade seemed to have helped, but not permanently. It was odd. Initially it was great, but after a short while it seemed to forget how to wake up correctly sometimes, and then it began to lose connections again as it did before. Overall it seems better, but not much. As for the channels, I set that to a single channel based on the best readings in the area. I usually check about once every six months, and I changed it just the other day. Nice strong signal, and I'm all alone.

Also, the result of that command was ...

/sys/module/rtl8188ce/parameters/*
cat: /sys/module/rtl8188ce/parameters/*: No such file or directory

I will keep digging. Thanks everyone.

Kernel version -40 is out, try the other command with a change

Code: Select all

 for p in /sys/module/rtl8192ce/parameters/*; do echo $p; cat $p; done

[TihSon]

... and that gave me this.

/sys/module/rtl8192ce/parameters/debug
0
/sys/module/rtl8192ce/parameters/fwlps
Y
/sys/module/rtl8192ce/parameters/ips
Y
/sys/module/rtl8192ce/parameters/swenc
N
/sys/module/rtl8192ce/parameters/swlps
N

I must admit, this is over my head. What am I looking at?

[JeremyB]

... and that gave me this.

/sys/module/rtl8192ce/parameters/debug
0
/sys/module/rtl8192ce/parameters/fwlps
Y
/sys/module/rtl8192ce/parameters/ips
Y
/sys/module/rtl8192ce/parameters/swenc
N
/sys/module/rtl8192ce/parameters/swlps
N

I must admit, this is over my head. What am I looking at?

If you look at

Code: Select all

modinfo -p rtl8192ce

It will show some definitions, debug is debug level, fwlps, ips, and swlps are all power save options and might be the issue, so to change ips to N we can

Code: Select all

sudo modprobe -r rtl8192ce

to temporarily remove the module and then we

Code: Select all

sudo modprobe rtl8192ce ips=N

If the change makes an improvement it can be made somewhat permanent by

Code: Select all

echo "options rtl8192ce ips=N" | sudo tee /etc/modprobe.d/rtl8192ce.conf

It might take more than one parameter change to see a difference

Code: Select all

sudo modprobe -r rtl8192ce

Code: Select all

sudo modprobe rtl8192ce ips=N fwlps=N

Changing swenc to Y might even help, swenc= software encryption

[TihSon]

No love. It seems to be worse now.

[JeremyB]

It might be a strange one

Code: Select all

sudo iwconfig wlan0 power on

[TihSon]

Sorry, it's been a while. Major system upgrades ...

The prior command gave me the following;

Code: Select all

Error for wireless request "Set Power Management" (8B2C) :
    SET failed on device wlan0 ; Operation not supported.

I am moving to Mint 64bit on a new SSD, and I will be installing a second Linux OS as well. I will compare the two systems to see if the problem is the same on the two systems. Also, this issue began when I upgraded to 17. I understand this probably has an answer on another part of this forum, but I am curious to know ... is it possible to revert to an earlier kernel when I upgrade the system to M17 64bit? Nothing I do is so bleeding edge I need the latest of anything.

[JeremyB]

Sorry, it's been a while. Major system upgrades ...

The prior command gave me the following;

Code: Select all

Error for wireless request "Set Power Management" (8B2C) :
    SET failed on device wlan0 ; Operation not supported.

I am moving to Mint 64bit on a new SSD, and I will be installing a second Linux OS as well. I will compare the two systems to see if the problem is the same on the two systems. Also, this issue began when I upgraded to 17. I understand this probably has an answer on another part of this forum, but I am curious to know ... is it possible to revert to an earlier kernel when I upgrade the system to M17 64bit? Nothing I do is so bleeding edge I need the latest of anything.

Try this and reboot

Code: Select all

echo "options rtl8192ce swenc=Y ips=N" | sudo tee /etc/modprobe.d/rtl8192ce.conf

[TihSon]

This thing is tricky. That did nothing ...

FYI, I've installed 17 64bit on my wife's nearly identical Thinkpad, and she's having the same issues. I am thinking I am going to learn about kernel regression and use the same kernel as 16 ... we'll see ...

[JeremyB]

This thing is tricky. That did nothing ...

FYI, I've installed 17 64bit on my wife's nearly identical Thinkpad, and she's having the same issues. I am thinking I am going to learn about kernel regression and use the same kernel as 16 ... we'll see ...

Found a new trick

Code: Select all

sudo apt-get install linux-headers-generic build-essential

Code: Select all

wget https://www.kernel.org/pub/linux/kernel/projects/backports/stable/v3.19-rc1/backports-3.19-rc1-1.tar.gz

Code: Select all

tar -zxvf backports-3.19-rc1-1.tar.gz

Code: Select all

cd backports-3.19-rc1-1

Code: Select all

make defconfig-rtlwifi

Code: Select all

make

Code: Select all

sudo make install

Then reboot

[TihSon]

I've just installed the backported module, and ... so far ... it works. I recently changed routers, and the system was dropping the connection every thirty seconds at times, and asking repeatedly for passwords ... which it would then reject. I will use the system for a day or two to verify this fix does what it should, and if it continues to function well I will mark this issue as SOLVED.

Thank you very much for your assistance with this nagging issue!

[JeremyB]

I would check the new router settings to make sure the encryption is WPA2-AES or WPA2 only

[TihSon]

Well this sucks.

I thought we'd found the answer, but the system still cannot hold a connection with even a slight amount of reliability. I have to admit, I am impressed that this has been evaded a solution for so long. I can't be the only person using this hardware, and considering this apparently affects Ubuntu systems as well ... clearly I am resigned to this. I haven't got the time to become a professional network analyst, and this is clearly something that a PhD is required to solve.

Thanks everyone for all of your help with this. I really do appreciate your work.