Bug#776816: firmware-realtek: fails to connect after a few suspends (or some uptime?)
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"
Reply to: