10ec:8176 [Lenovo ThinkPad X120e] Wireless not working in 12.04 for rtl8192ce (RTL8188CE)

Thank you for taking the time to file a bug report on this issue.

However, given the number of bugs that the Kernel Team receives during any development cycle it is impossible for us to review them all. Therefore, we occasionally resort to using automated bots to request further testing. This is such a request.

We have noted that there is a newer version of the development kernel than the one you last tested when this issue was found. Please test again with the newer kernel and indicate in the bug if this issue still exists or not.

If the bug still exists, change the bug status from Incomplete to Confirmed. If the bug no longer exists, change the bug status from Incomplete to Fix Released.

If you want this bot to quit automatically requesting kernel tests, add a tag named: bot-stop-nagging.

 Thank you for your help, we really do appreciate it.

Still happens with the lastest kernel.

apport information

apport information

apport information

apport information

apport information

apport information

apport information

apport information

apport information

apport information

apport information

apport information

apport information

apport information

apport information

apport information

apport information

apport information

apport information

apport information

apport information

apport information

Would it be possible for you to test the latest upstream kernel? It will allow additional upstream developers to examine the issue. Refer to https://wiki.ubuntu.com/KernelMainlineBuilds . If possible, please test the latest v3.2-rcN kernel (Not a kernel in the daily directory). Once you've tested the upstream kernel, please remove the 'needs-upstream-testing' tag(Only that one tag, please leave the other tags). This can be done by clicking on the yellow pencil icon next to the tag located at the bottom of the bug description and deleting the 'needs-upstream-testing' text.

If this bug is fixed by the mainline kernel, please add the following tag 'kernel-fixed-upstream-KERNEL-VERSION'. For example, if kernel version 3.2-rc1 fixed and issue, the tag would be: 'kernel-fixed-upstream-v3.2-rc1'.

If the mainline kernel does not fix this bug, please add the tag: 'kernel-bug-exists-upstream'.

If you are unable to test the mainline kernel, for example it will not boot, please add the tag: 'kernel-unable-to-test-upstream'. If you believe this bug does not require upstream testing, please add the tag: 'kernel-upstream-testing-not-needed'.

Once testing of the upstream kernel is complete, please mark this bug as "Confirmed".

Thanks in advance.

Bug is still present after installing linux-image-3.2.0-030200rc5-generic-pae_3.2.0-030200rc5.201112091935_i386.deb

Will re-attach logs.

Bug is still present after installing linux-image-3.2.0-030200rc5-generic-pae_3.2.0-030200rc5.201112091935_i386.deb

Also, after installing that kernel, I could no longer access any terminals (either gnome-terminal or any TTY with control+alt+f1-6).
Everything else worked, but no terminal, so I couldn't collect logs with the latest kernel.
Same symptoms, though.

apport information

apport information

apport information

apport information

apport information

apport information

apport information

apport information

apport information

apport information

apport information

apport information

And finally with mainline kernel 3.11 (before i used 3.2-52) still a bunch of messages (which are not there if connected in Windows) but not so relating to missing ACK. Looks stable at the moment with mode N:

Sep 5 16:55:50 OpenWrt daemon.info hostapd: wlan0: STA d0:df:9a:46:3b:c9 WPA: pairwise key handshake completed (RSN)
Sep 5 16:56:01 OpenWrt daemon.info hostapd: wlan0: STA d0:df:9a:46:3b:c9 IEEE 802.11: disconnected due to excessive missing ACKs
Sep 5 16:56:05 OpenWrt daemon.info hostapd: wlan0: STA d0:df:9a:46:3b:c9 IEEE 802.11: authenticated
Sep 5 16:56:05 OpenWrt daemon.info hostapd: wlan0: STA d0:df:9a:46:3b:c9 IEEE 802.11: associated (aid 1)
Sep 5 16:56:05 OpenWrt daemon.info hostapd: wlan0: STA d0:df:9a:46:3b:c9 WPA: pairwise key handshake completed (RSN)
Sep 5 16:56:27 OpenWrt daemon.info hostapd: wlan0: STA d0:df:9a:46:3b:c9 IEEE 802.11: authenticated
Sep 5 16:56:27 OpenWrt daemon.info hostapd: wlan0: STA d0:df:9a:46:3b:c9 IEEE 802.11: associated (aid 1)
Sep 5 16:56:27 OpenWrt daemon.info hostapd: wlan0: STA d0:df:9a:46:3b:c9 WPA: pairwise key handshake completed (RSN)
Sep 5 16:56:56 OpenWrt daemon.info hostapd: wlan0: STA d0:df:9a:46:3b:c9 IEEE 802.11: authenticated
Sep 5 16:56:56 OpenWrt daemon.info hostapd: wlan0: STA d0:df:9a:46:3b:c9 IEEE 802.11: associated (aid 1)
Sep 5 16:56:56 OpenWrt daemon.info hostapd: wlan0: STA d0:df:9a:46:3b:c9 WPA: pairwise key handshake completed (RSN)
Sep 5 16:57:04 OpenWrt daemon.info hostapd: wlan0: STA d0:df:9a:46:3b:c9 IEEE 802.11: authenticated
Sep 5 16:57:04 OpenWrt daemon.info hostapd: wlan0: STA d0:df:9a:46:3b:c9 IEEE 802.11: associated (aid 1)
Sep 5 16:57:04 OpenWrt daemon.info hostapd: wlan0: STA d0:df:9a:46:3b:c9 WPA: pairwise key handshake completed (RSN)
Sep 5 16:57:21 OpenWrt daemon.info hostapd: wlan0: STA d0:df:9a:46:3b:c9 IEEE 802.11: authenticated
Sep 5 16:57:21 OpenWrt daemon.info hostapd: wlan0: STA d0:df:9a:46:3b:c9 IEEE 802.11: associated (aid 1)
Sep 5 16:57:21 OpenWrt daemon.info hostapd: wlan0: STA d0:df:9a:46:3b:c9 WPA: pairwise key handshake completed (RSN)

Interesting, yesterday i run into the same full connection and no data trouble with the 3.11 mainline kernel.

I played arround a bit with some settings in the openwrt firmware. I forced ht-mode to 40Mhz even if the second channel was used by another AP. And all the above messages where gone. Only these sometimes which should be normal where there:

 STA 4c:0b:3a:85:55:3a WPA: pairwise key handshake completed (RSN)
 STA d0:df:9a:46:3b:c9 WPA: pairwise key handshake completed (RSN)

However, today i can't reproduce it, the settings in openwrt didn't change and there are tons of messages like above again.

But eventually it points to a direction whats going wrong. Maybe it has something todo with the channel handling or with which 802.11 standard the Realtek card sends ACK messages and where the AP is hearing for them.

Interesting Sirius.

My DSL problems continue with this crappy new DSL2 service(at&t u-verse), it came back up today, for who knows how long. The old service worked great, never had a single problem.

Anyway, after testing multiple kernels and the new ones from before when I had regular DSL and a netgear modem I had nothing but troubles. Since having this different router and testing all those kernels all over again without any disconnects, plus the fact that I tried my laptop on another similar router and had the same results, I tend to think the realtek drivers are not fully compatible with something in certain routers. ? . ?

Who knows but I do know that the problem for me has, for now anyway, gone away and the only thing that changed was my router. Meanwhile if I hook up my old router which no longer has a DSL connection and I leave my laptop on it does have issues with the connection.

My current kernel is just the standard one from the repos.
3.8.0-29-generic 32bit

Good Luck Sirius

Hi all,

i bought a new Wifi card, so i am no longer affected.

But i really want to see this fixed and i came to the conclusion that i am willing to send my Realtek card to Larry if it helps. I made a picture of it. Don't know if there are much different versions.

@Larry: What do you think? Is it worth a try?

On 09/19/2013 10:08 AM, Sirius1977 wrote:
> Hi all,
>
> i bought a new Wifi card, so i am no longer affected.
>
> But i really want to see this fixed and i came to the conclusion that i
> am willing to send my Realtek card to Larry if it helps. I made a
> picture of it. Don't know if there are much different versions.
>
> @Larry: What do you think? Is it worth a try?
>
>
> ** Attachment added: "RT8188ce"
> https://bugs.launchpad.net/ubuntu/+source/linux/+bug/902557/+attachment/3829368/+files/IMG_20130919_165505.jpg
>

I already have one of those that works for me.

Larry

Ok...

Anyway, have you seen my kismet dumps and openWRT Logs? Do they help in any way to find out what the problem is?

Yesterday i found out that 11b didn't work with 3.11, no chance to connect to the AP.

I have been working on the gain control code in rtl8192ce and rtl8192cu. Both had a tendency to wander to the point that the RX gain was too small for the chip to receive anything. The attached patch is a lot better.

It applies to the current mainline 3.12-rc2 kernel, but it is likely appropriate for olger kernels.

Sounds interesting. I test it as soon as i can.

Is there a way to only compile the affected module and not the entire kernel? The last time i had compiled a kernel was around Debian 3.0 "woody" so my knowlege about this has gone away ;-)

Unless the code is designed for building an out-of-kernel module, you really do need to build the entire kernel.

On a Mint system that I run on a PPC computer, I have to use "fakeroot" to build a .deb file. I assume you would need to do the same, but I don't use Ubuntu, and I'm not a reliable source on that distro.

 Hi Larry,

Thanks a lot for your work on this. Is there any chance for these improvements to end up in older kernels?
I'm stuck on 3.2 because of the cedartrail and gva500 drivers that don't exist for newer kernels :-(

These changes depend on a lot of other work that cannot be backported to 3.2. You will, however, be able to use the code base of the backports project to get the latest drivers. I assume that Ubuntu builds a backports package for each of their kernels. Most distros do.

Thanks for the hint -I'll have a look when I can spend more time on this and report back here.

At the moment the situation for this wifi driver in Ubuntu 12.04 is as follows:
Install Ubuntu 12.04 without updates to end up on kernel 3.2 (for the Atom N2600 screen driver) gets you to kernel 3.2.0.29 with working wifi.
Upgrading the installation gets you to 3.2.0.54 where wifi is still broken - not so good for an LTS version.

I found a non official DKMS package for the Realtek 0007.0809.2012 driver, which performs really bad (slow and grinding to a hold after a few minutes). When that happens, all wifi on the same access point nearly stops working (tested with 2 different makes access point and with 2 different wifi cards)
Installing the Realtek 0012.0207.2013 driver is better, but still shows that slowing down to hold after a while syndrome. The impact on the other devices seems to be a lot less, but up to now I didn't manage to compile a DKMS-version from it.

I've been trying to create a DKMS package for 0012.207.2013 on kernel 3.2.0, but I got stuk. Since that is not really a sollution for this bug (it should just work without compiling and installing drivers from Realtek, just like it did before 3.2.0.40), I posted my problems doing that on http://askubuntu.com/questions/357047/how-to-create-realtek-9182ce-driver-dkms-module, leaving a reference here for who ever stubles on the same problem.

I found the problem with the 3.2.0 kernel: the linux-firmware package distributes the old realtek firmware that doesn't work with the new drivers that went in the kernel on 1/4/2013.
I filed a bug for it: https://bugs.launchpad.net/ubuntu/+source/linux-firmware/+bug/1239414

That is a Ubuntu packaging problem. The linux-firmware git repo has the correct firmware.

Ah, good to know. Thanks for looking into this Larry.

I hope I'm looking in the right place (http://git.kernel.org/cgit/linux/kernel/git/firmware/linux-firmware.git/tree/rtlwifi).
In kernel git I notice that the size of rtl8192cfw.bin is 13540 bytes, while the one downloaded from the Realtek website is 16192 bytes. It's a bit hard with those binary blobs and versions :-(, but as far as I can see, the 16192 bytes version works, while the 13540 bytes version doesn't, unless something else is obfuscating my test results. My card is a rtl8188ee, which seems to use this binary.

Your comment is confusing. You write about firmware rtl8192cfw.bin, and then say your hardware is RTL8188EE. If that is really your hardware, then your firmware file is rtl8188efe.bin, not rtl8192cfw.bin. Which is correct?

The firmware files that work for me have the following md5sums and sizes:

finger@larrylap:~/linux-firmware> md5sum rtlwifi/*
3aed09e6385aff0f3809a3949f6c3b64 rtlwifi/rtl8188efw.bin
aaef52a47852e599cbff63a3e7f96a94 rtlwifi/rtl8188eufw.bin
748944fbffd3b08b5b1929bb6c7fc537 rtlwifi/rtl8192cfw.bin
dd371739aa401ea1d615436b24598bc4 rtlwifi/rtl8192cfwU_B.bin
660d5d7e1e1fd985261fb20b2ac283f6 rtlwifi/rtl8192cfwU.bin
7e15572f80406839896ff4a1042b2b2f rtlwifi/rtl8192cufw_A.bin
d0cdaf2531dcf416058ebb00f3f527bb rtlwifi/rtl8192cufw_B.bin
943e9b714a926e630b8152d7aad91d2e rtlwifi/rtl8192cufw.bin
b64bd0e053c8b9e45efeae7ffaafde9f rtlwifi/rtl8192cufw_TMSC.bin
de0e4180e87cf18a8a4b62d145bde829 rtlwifi/rtl8192defw.bin
2faf6915a0bbb5d15d3bd43618f5347c rtlwifi/rtl8192sefw.bin
200fd952db3cc9259b1fd05e3e51966f rtlwifi/rtl8712u.bin
ce50dfe07dbb1bfe9e14bdb315a4b28a rtlwifi/rtl8723fw_B.bin
69ccaffbe94cc0ef1b89c25290e19b2e rtlwifi/rtl8723fw.bin
finger@larrylap:~/linux-firmware> ls -l rtlwifi/
total 400
-rw-r--r-- 1 finger users 11216 Feb 20 2013 rtl8188efw.bin
-rw-r--r-- 1 finger users 13904 Sep 27 22:17 rtl8188eufw.bin
-rw-r--r-- 1 finger users 13540 Feb 14 2013 rtl8192cfw.bin
-rw-r--r-- 1 finger users 14800 Feb 14 2013 rtl8192cfwU_B.bin
-rw-r--r-- 1 finger users 14818 Feb 14 2013 rtl8192cfwU.bin
-rw-r--r-- 1 finger users 16116 Sep 26 17:14 rtl8192cufw_A.bin
-rw-r--r-- 1 finger users 16096 Sep 26 17:14 rtl8192cufw_B.bin
-rw-r--r-- 1 finger users 16014 Feb 14 2013 rtl8192cufw.bin
-rw-r--r-- 1 finger users 16116 Sep 26 17:14 rtl8192cufw_TMSC.bin
-rw-r--r-- 1 finger users 22978 Feb 14 2013 rtl8192defw.bin
-rw-r--r-- 1 finger users 80208 Feb 14 2013 rtl8192sefw.bin
-rw-r--r-- 1 finger users 122328 Feb 14 2013 rtl8712u.bin
-rwxr-xr-x 1 finger users 22996 Feb 14 2013 rtl8723fw_B.bin
-rwxr-xr-x 1 finger users 11662 Feb 14 2013 rtl8723fw.bin
finger@larrylap:~/linux-firmware>

Very confusing :-(
I see in modinfo, what makes me think it uses rtl8192cfw:
firmware: rtlwifi/rtl8192cfwU_B.bin
firmware: rtlwifi/rtl8192cfwU.bin
firmware: rtlwifi/rtl8192cfw.bin

but: description: Realtek 8192C/8188C 802.11n PCI wireless

With a clean install of Ubuntu 12.04, upgraded to kernel 3.2.0-54, wireless does not work: error in dmesg "Failed to request firmware!"

There are a quite a lot of differences with your output, you are right that the problem lies at ubuntu packaging. While testing this, I noticed that rtl8192cfwU_B.bin and rtl8192cfwU.bin where missing and requested by the driver. Copying those in from the Realtek website makes the wifi work again :-).

missing in the Ubuntu installation:
rtl8188efw
rtl8188eufw
rtl8192cfwU_B
rtl8192cfwU
rtl8192cufw_A
rtl8192cufw_B
rtl8192cufw_TMSC

different:
rtl8192defw
rtl8192sefw
rtl8712u

the same:
rtl8192cfw
rtl8192cufw
rtl8723fw_B
rtl8723fw

Details of test machine:
test@test-Intel-powered-classmate-PC:/lib/firmware$ md5sum rtlwifi/*
748944fbffd3b08b5b1929bb6c7fc537 rtlwifi/rtl8192cfw.bin
943e9b714a926e630b8152d7aad91d2e rtlwifi/rtl8192cufw.bin
7a3b61dbd72e0efb22f892ece8020994 rtlwifi/rtl8192defw.bin
bccf9bf2276621770f101a60736b4004 rtlwifi/rtl8192sefw.bin
8e6396b5844a3e279ae8679555dec3f0 rtlwifi/rtl8712u.bin
ce50dfe07dbb1bfe9e14bdb315a4b28a rtlwifi/rtl8723fw_B.bin
69ccaffbe94cc0ef1b89c25290e19b2e rtlwifi/rtl8723fw.bin
test@test-Intel-powered-classmate-PC:/lib/firmware$ ls -l rtlwifi/
totaal 308
-rw-r--r-- 1 root root 13540 dec 11 2012 rtl8192cfw.bin
-rw-r--r-- 1 root root 16014 dec 11 2012 rtl8192cufw.bin
-rw-r--r-- 1 root root 20526 dec 11 2012 rtl8192defw.bin
-rw-r--r-- 1 root root 88856 dec 11 2012 rtl8192sefw.bin
-rw-r--r-- 1 root root 129304 dec 11 2012 rtl8712u.bin
-rwxr-xr-x 1 root root 22996 jul 11 14:43 rtl8723fw_B.bin
-rwxr-xr-x 1 root root 11662 jul 11 14:43 rtl8723fw.bin

test@test-Intel-powered-classmate-PC:/lib/firmware$ modinfo rtl8192ce
filename: /lib/modules/3.2.0-54-generic-pae/kernel/drivers/net/wireless/rtlwifi/rtl8192ce/rtl8192ce.ko
firmware: rtlwifi/rtl8192cfwU_B.bin
firmware: rtlwifi/rtl8192cfwU.bin
firmware: rtlwifi/rtl8192cfw.bin
description: Realtek 8192C/8188C 802.11n PCI wireless
license: GPL
author: Larry Finger <email address hidden>
author: Realtek WlanFAE <email address hidden>
author: lizhaoming <email address hidden>
srcversion: DA52BF758B7683607AFCB85
alias: pci:v000010ECd00008176sv*sd*bc*sc*i*
alias: pci:v000010ECd00008177sv*sd*bc*sc*i*
alias: pci:v000010ECd00008178sv*sd*bc*sc*i*
alias: pci:v000010ECd00008191sv*sd*bc*sc*i*
depends: rtlwifi,rtl8192c-common,mac80211
intree: Y
vermagic: 3.2.0-54-generic-pae SMP mod_unload modversions 686
parm: swenc:Set to 1 for software crypto (default 0)
 (bool)
parm: ips:Set to 0 to not use link power save (default 1)
 (bool)
parm: swlps:Set to 1 to use SW control power save (default 0)
 (bool)
parm: fwlps:Set to 1 to use FW control power save (default 1)
 (bool)
parm: debug:Set debug level (0-5) (default 0) (int)

*-network UNCLAIMED
                description: Network controller
                product: RTL8188CE 802.11b/g/n WiFi Adapter
                vendor: Realtek Semiconductor Co., Ltd.
   ...

I expected that your hardware was an RTL8188CE, but when you wrote EE, I had to ask.

The updated firmware for rtl8192ce in the linux-firmware repo has the following commit:

commit e0836e6ec3568f54b7fac24b9e17bbe8c46eb508
Author: Larry Finger <email address hidden>
Date: Sun Jul 8 15:16:17 2012 -0500

Why has this update been available for 16 months and *still* not picked up and packaged by Ubuntu????

My distro of choice has had it for a long time.

Ah, sorry for the typo.
It's sad. I don't dare to guess how much time I've spend on this while it shouldn't have been a bug at all and the time and energy you have spend, answering my questions that never should have been asked :-(

I really appreciate your help. I hope everyone learned a little bit.

Koen: I'm glad that resolved things for you.

However, simply copying in the RealTek-supplied firmware has never made any difference for me. It's not just a simple matter of what is/isn't packaged with Ubuntu, as far as all my efforts to date go.

At least, I begin to understand why duplicating the problems found by Ubuntu users is so difficult for me.

You should not have to deal with anything from the vendor-supplied code. That is my job. It takes a lot of testing before I change the firmware, and I need a very good reason.

@Ryan: it doesn't resolve everything: it just makes the wireless show up again, rather then not work at all.
The performance is still very poor :-(.
I don't know if Ubuntu ships the latest drivers. The Realtek drivers are not good either, but seem to last a little bit longer before the connection drops. It's very hard to get objective data. I contacted Realtek for a comment, but they don't reply. They probably had enough complainers about this card...

Did anyone test the patch that Larry has posted? I don't have the time at the moment.

Hi Sirius,
I read through the thread again and for what I found, there is a patch that went 1/04/2013 in kernel git for kernel 3.2 and then patches that apply to kernel 3.11 that are too difficult to backport to earlier kernels.
At the moment I'm testing the ones that went in on 1/04/2013 with linux-firmware that finally made it in proposed.

Very subjective observation: it works better then whit the manufacturers driver (0007 and 0012). I find it hard to come up with a testsetup and a way to collect reproducable results. I only had one moment when the speed dropped badly and that could have been due to my desk standing full of working laptops.

I tested it up to now with 3 AP's: linksys wrt54gs, linksys wap200 and unifi pro. It works fine on all 3, except with the unifi I get a weird message in dmesg of the client: No basic rates in AssocResp. Using min supported rate instead. The speed seems ok though. Going to ask the unifi guys why that message shows up on their equipment.

Upgraded to 13.10 yesterday with hope that new kernel will save the situation - no luck, if not became worse...

What kernel does 13.10 run? If you want the latest, you will need to build your own.

You also need to look very carefully at the firmware version as Ubuntu has not been distributing the latest. On my system, the md5sum for the correct fw is

748944fbffd3b08b5b1929bb6c7fc537 /lib/firmware/rtlwifi/rtl8192cfw.bin

The device works for me. I use openSUSE with a 3.12-rc4 kernel and I control it with NetworkManager. I have already wasted a lot of time trying to find what is causing problems for Ubuntu users, only to find that the distro's firmware is out of date. I have decided to quit doing that.

just checked my pangolin install

/media/pangolin# uname -a
Linux peter-GA-MA78GM-S2HP 3.8.0-31-generic #46-Ubuntu SMP Tue Sep 10 20:03:44 UTC 2013 x86_64 x86_64 x86_64 GNU/Linux

/media/pangolin/lib/firmware/rtlwifi# md5sum rtl8192cfw.bin
748944fbffd3b08b5b1929bb6c7fc537 rtl8192cfw.bin

it is the same as posted under #343 and it works on devices/pc's that have this chipset.

hi Larry. sorry for late reply. 13.10 runs "Linux sergio-pc 3.11.0-13-generic #20-Ubuntu SMP Wed Oct 23 17:26:33 UTC 2013 i686 i686 i686 GNU/Linux"

hi again @Larry, just checked current system firmware for the kernel i mentioned above, and you know what?

sergio@sergio-pc:~$ md5sum /lib/firmware/rtlwifi/rtl8192cfw.bin
748944fbffd3b08b5b1929bb6c7fc537 /lib/firmware/rtlwifi/rtl8192cfw.bin

…which is the same as you posted, but the device still constantly drops connection! what else should i try to do?

I've you tried to add this in /etc/modprobe.d/rtl8192ce.conf :

options rtl8192ce ips=0 fwlps=0

I have recently done a complete rewrite on the gain control code in rtl8192c. The primary reason for this was to implove the connectivity in rtl8192cu, but the new code also impacts rtl8192ce. At the moment, I am testing a 10ec:8178 RTL8192CE device with good results (RX throughput up to 65 Mbps). The next card to test will be an RTL8188CE.

These patches will be submitted with a notation that they be backported to stable kernels; however, I have no idea how long it will take for them to hit the stable kernel versions, and then to get into the Ubuntu kernels.

@Patrick, thank for your advice, tried it yesterday and thank goodness it worked for me! i'd recommend others to try it out.
quick googling shows that this solution has been around for several months (!), it's a pity that nobody else found/mentioned that earlier here, but now it seems like a real work-around.

@Larry, should your patches simply improve signal quality or directly address this issue? i mean should i keep these settings "ips=0" and "fwlps=0" forever or your changes would directly affect them?

ps: btw @Larry, i don't know is this related or not, buy as my wifi adapter is 802.11n 300Mbps, i expect high connection speed. i got 70Mbps tariff from ISP, 802.11n 300Mbps router Zyxel Keenetic which promises up to 70Mbps over L2TP and gives 60+ Mbps over ethernet, but only 40+ Mbps max over wifi even if from 1 meter in-sight distance. is this expected behavior or not? could your patches help with it?

Did you read my previous comment about speed? YMMV.

Any promise of wifi speed depends on so many factors that it is meaningless without a measurement.

I am running without any special module loading parameters. I am still getting Reason 7 deauthentications, but the connection recovers within a few tenths of a second.

I'm trying to install the posted patch, but don't really know what i'm doing as I've never patched anything before. I've seen references to diff files when searching for how to apply a patch, but there just seems to be this one .txt file which I've downloaded.

Can anybody elaborate more on this or point me to a good forum post that explains what to do?

If it matters, I'm using 3.11.7.

$ md5sum /lib/firmware/rtlwifi/rtl8192cfw.bin
fd118c183ad9e11060a6e575b472280e /lib/firmware/rtlwifi/rtl8192cfw.bin

Saw this and also noticed that I had another file (same name, but with .bin.bak extension) that matched the md5sum @Larry posted, so I swapped them around and ran

$ sudo rmmod rtl8192ce
$ sudo modprobe rtl8192ce

No noticeable difference, however. Here's the output from syslog, filtered on the Reason 6 deassociations:

Nov 20 09:49:35 <redacted> wpa_supplicant[1165]: wlan0: CTRL-EVENT-DISCONNECTED bssid=00:46:9a:02:17:01 reason=6
Nov 20 09:49:45 <redacted> kernel: [ 1072.963826] wlan0: deauthenticated from 00:46:9a:02:17:01 (Reason: 6)
Nov 20 09:49:45 <redacted> wpa_supplicant[1165]: wlan0: CTRL-EVENT-DISCONNECTED bssid=00:46:9a:02:17:01 reason=6
Nov 20 09:49:54 <redacted> kernel: [ 1081.877888] wlan0: deauthenticated from 00:46:9a:02:17:01 (Reason: 6)
Nov 20 09:49:54 <redacted> wpa_supplicant[1165]: wlan0: CTRL-EVENT-DISCONNECTED bssid=00:46:9a:02:17:01 reason=6
Nov 20 09:50:17 <redacted> kernel: [ 1105.164543] wlan0: deauthenticated from 00:46:9a:02:17:01 (Reason: 6)
Nov 20 09:50:17 <redacted> wpa_supplicant[1165]: wlan0: CTRL-EVENT-DISCONNECTED bssid=00:46:9a:02:17:01 reason=6
Nov 20 09:50:26 <redacted> kernel: [ 1114.050513] wlan0: deauthenticated from 00:46:9a:02:17:01 (Reason: 6)
Nov 20 09:50:26 <redacted> wpa_supplicant[1165]: wlan0: CTRL-EVENT-DISCONNECTED bssid=00:46:9a:02:17:01 reason=6
Nov 20 09:50:35 <redacted> kernel: [ 1122.749766] wlan0: deauthenticated from 00:46:9a:02:17:01 (Reason: 6)
Nov 20 09:50:35 <redacted> wpa_supplicant[1165]: wlan0: CTRL-EVENT-DISCONNECTED bssid=00:46:9a:02:17:01 reason=6
Nov 20 09:50:53 <redacted> kernel: [ 1140.669823] wlan0: deauthenticated from 00:46:9a:02:17:01 (Reason: 6)
Nov 20 09:50:53 <redacted> wpa_supplicant[1165]: wlan0: CTRL-EVENT-DISCONNECTED bssid=00:46:9a:02:17:01 reason=6
Nov 20 09:51:12 <redacted> kernel: [ 1159.897681] wlan0: deauthenticated from 00:46:9a:02:17:01 (Reason: 6)
Nov 20 09:51:12 <redacted> wpa_supplicant[1165]: wlan0: CTRL-EVENT-DISCONNECTED bssid=00:46:9a:02:17:01 reason=6
Nov 20 09:52:12 <redacted> kernel: [ 1219.900061] wlan0: deauthenticated from 00:46:9a:02:17:01 (Reason: 6)
Nov 20 09:52:12 <redacted> wpa_supplicant[1165]: wlan0: CTRL-EVENT-DISCONNECTED bssid=00:46:9a:02:17:01 reason=6
Nov 20 09:52:46 <redacted> kernel: [ 1254.185542] wlan0: deauthenticated from 00:46:9a:02:17:01 (Reason: 6)
Nov 20 09:52:46 <redacted> wpa_supplicant[1165]: wlan0: CTRL-EVENT-DISCONNECTED bssid=00:46:9a:02:17:01 reason=6
Nov 20 09:53:24 <redacted> kernel: [ 1292.437548] wlan0: deauthenticated from 00:46:9a:02:17:01 (Reason: 6)
Nov 20 09:53:24 <redacted> wpa_supplicant[1165]: wlan0: CTRL-EVENT-DISCONNECTED bssid=00:46:9a:02:17:01 reason=6
Nov 20 09:53:41 <redacted> kernel: [ 1309.370754] wlan0: deauthenticated from 00:46:9a:02:17:01 (Reason: 6)
Nov 20 09:53:41 <redacted> wpa_supplicant[1165]: wlan0: CTRL-EVENT-DISCONNECTED bssid=00:46:9a:02:17:01 reason=6
Nov 20 09:53:48 <redacted> kernel: [ 1316.014818] wlan0: deauthenticated from 00:46:9a:02:17:01 (Reason: 6)
Nov 20 09:53:48 <redacted> wpa_supplicant[1165]: wlan0: CTRL-EVENT-DISCONNECTED bssid=00:46:9a:02:17:01 rea...

The newer bug report is a duplicate of this one, not the other way round.

Neither bug is a duplicate of the other as they deal with two different chipsets.

The Precise Pangolin has reached end of life, so this bug will not be fixed for that release