On 2015-02-28 18:08:50, Ben Hutchings wrote: > Control: severity -1 normal > Control: notfixed -1 0.36+wheezy.1 > > On Wed, 2015-02-18 at 23:25 -0500, Antoine Beaupré wrote: >> Control: severity -1 grave >> Control: fixed -1 0.36+wheezy.1 >> >> I am now pretty sure this is a bug, a regression, even, in the realtek >> firmware. I downgraded to the wheezy version 4 days ago, and problems >> went away (hence the "fixed" above). Now that I upgraded again, problems >> are back. > [...] > > The rtl8192ce firmware (rtl8192cfw.bin, rtl8192cfwU.bin and > rtl8192cfwU_B.bin for various versions of the chip) has not been changed > since version 0.36+wheezy.1 of the package. So this problem is not a > regression.
So I know this is pretty old now, but i'm still stuck with this wifi card that basically doesn't work at all as soon as encryption is used over the airwaves. I get a minute or two of traffic then boom, it goes down and i need to turn the wifi off and on again to fix it. That is, to say the least, disruptive to things like TCP. In february I documented that downgrading to the wheezy version fixed it. I double-checked my dpkg logs (while they're stil around!) and figured it could be useful to paste those to confirm that: 2015-02-14 23:20:17 startup archives unpack 2015-02-14 23:20:21 upgrade firmware-realtek:all 0.43 0.36+wheezy.1 2015-02-14 23:20:21 status half-configured firmware-realtek:all 0.43 2015-02-14 23:20:21 status unpacked firmware-realtek:all 0.43 2015-02-14 23:20:21 status half-installed firmware-realtek:all 0.43 2015-02-14 23:20:21 status half-installed firmware-realtek:all 0.43 2015-02-14 23:20:22 status unpacked firmware-realtek:all 0.36+wheezy.1 2015-02-14 23:20:22 status unpacked firmware-realtek:all 0.36+wheezy.1 2015-02-14 23:20:22 startup packages configure 2015-02-14 23:20:22 configure firmware-realtek:all 0.36+wheezy.1 <aucune> 2015-02-14 23:20:22 status unpacked firmware-realtek:all 0.36+wheezy.1 2015-02-14 23:20:22 status half-configured firmware-realtek:all 0.36+wheezy.1 2015-02-14 23:20:22 status installed firmware-realtek:all 0.36+wheezy.1 2015-02-14 23:20:22 status triggers-pending initramfs-tools:all 0.116 2015-02-14 23:20:22 trigproc initramfs-tools:all 0.116 <aucune> 2015-02-14 23:20:22 status half-configured initramfs-tools:all 0.116 2015-02-14 23:20:46 status installed initramfs-tools:all 0.116 2015-02-14 23:20:47 startup packages configure I am currently running into the same issues with the firmware from 0.44, which *has* changed from 0.43 and previous. Yet the problem is still there. I have found similar threads here and there... Here's one in Ubuntu that is similar: https://askubuntu.com/questions/504777/unstable-wireless-connection-in-ubuntu-14-04 the suggested workaround ("swenc=1 ips=0") doesn't work. I do not control the wireless routers in a lot of cases, so the other suggestions do not apply. (Although i did try to disable IPv6, which doesn't work either.) this thread is also somewhat similar and explains a lot of options in diagnostics of the realtek firmware: http://ubuntuforums.org/showthread.php?t=2180178 Somehow, if the wifi connection is continuously active, the delay until which i need to restart it is longer. Ping doesn't suffice, it needs to be a bunch of tabs in a browser or something. I feel there's a correlation between me switching from my web browser to a mosh session, but that could just be an impression. In fact, it seems that if the connection is *idle* too long, something times out and the wifi crumbles. this kernel bug also seems related: https://bugzilla.kernel.org/show_bug.cgi?id=60713 It could explain the regression i saw from wheezy (linux 3.2) to jesssie (linux 3.16). But downgrading to Linux 3.2 doesn't completely solve the problem. The connexion is slightly more reliable, but not in a definitive way. I still saw it crash two times since the reboot, but it feels way more reliable. Whereas 3.16 crashes very frequently (every one or two minutes), i have just now spent 10 minutes without a crash on 3.2, which almost never happens on 3.16. The 4.2 kernel also looks a little more reliable. I need to test it a little more, but so far there has been no crashes in about 10 minutes of uptime. This is exceptional: i couldn't get anything that reliable in jessie so far with or without the wheezy kernel. (One new problem, however, is that the network-manager applet doesn't notice the network going up anymore, which looks really weird because the animation is stuck at "the first ball is green, the other gray" and stays there, even though the UI is still responsive. Restarting nm-applet fixes that specific problem.) It certainly feels that something is wrong with the gain control, as described in the kernel bug report above; another symptom i just noticed is that, through mosh i can see my irssi clock being update on a shell, even when i can't ping the gateway. My guess is that something is wrong with the way the wifi card sends wifi packets, but it can still *receive* them, and mosh is able to parse those UDP packets fine and update its display. It also doesn't need to ACK them so the connexion looks like it's still on, at least from one side of it. I am not sure where to go from here to fix that. There seems to be definitely something wrong with the driver, and it certainly looks more and more the be the fault of the kernel - should the bug be reassigned to the linux source package? Maybe the fixes (if any) performed on the 4.x branch of that driver could be backported in a stable-update? This wifi card is fairly common, from what i could find online. It was shipped with this Lenovo Thinkpad x120e... Thanks for the feedback, and sorry for the delays. A. -- Un éducateur dans l'âme ne prend rien au sérieux que par rapport à ses disciples -- soi-même non excepté. - Nietzsche, "Par delà le bien et le mal"
