Debian Bug report logs - #776816
firmware-realtek: fails to connect after a few suspends (or some uptime?)

Display info messages

Message #5 received at submit@bugs.debian.org (full text, mbox, reply):

From: Antoine Beaupré <anarcat@koumbit.org>

To: Debian Bug Tracking System <submit@bugs.debian.org>

Subject: firmware-realtek: fails to connect after a few suspends (or some uptime?)

Date: Sun, 01 Feb 2015 23:06:41 -0500

Package: firmware-realtek
Version: 0.43
Severity: normal

I started seeing this behavior after the upgrade from wheezy to jessie.
I am not sure it's directly related to the firmware, because I upgraded
it shortly before the upgrade. This is the history of upgrades, in
reverse order:

/var/log/dpkg.log.1:2014-12-30 17:35:43 upgrade firmware-realtek:all 0.43~bpo70+1 0.43
/var/log/dpkg.log.1:2014-12-05 15:46:29 upgrade firmware-realtek:all 0.41~bpo70+1 0.43~bpo70+1
/var/log/dpkg.log.10.gz:2014-03-23 20:14:57 upgrade firmware-realtek:all 0.40~bpo70+1 0.41~bpo70+1
/var/log/dpkg.log.12.gz:2014-01-19 14:10:55 upgrade firmware-realtek:all 0.39~bpo70+1 0.40~bpo70+1

It could also be the kernel's fault:

root@angela:/etc/ssh# grep linux-image /var/log/dpkg.log* | grep -v status
/var/log/dpkg.log:2015-01-23 15:59:56 remove linux-image-3.2.0-4-amd64:amd64 3.2.63-2+deb7u2 <aucune>
/var/log/dpkg.log:2015-01-23 16:00:05 purge linux-image-3.2.0-4-amd64:amd64 3.2.63-2+deb7u2 <aucune>
/var/log/dpkg.log.1:2014-12-09 15:35:48 upgrade linux-image-3.2.0-4-amd64:amd64 3.2.63-2+deb7u1 3.2.63-2+deb7u2
/var/log/dpkg.log.1:2014-12-09 15:36:14 configure linux-image-3.2.0-4-amd64:amd64 3.2.63-2+deb7u2 <none>
/var/log/dpkg.log.1:2014-12-30 18:33:13 install linux-image-3.16.0-4-amd64:amd64 <aucune> 3.16.7-ckt2-1
/var/log/dpkg.log.1:2014-12-30 18:42:23 upgrade linux-image-amd64:amd64 3.2+46 3.16+63
/var/log/dpkg.log.1:2014-12-30 18:53:07 configure linux-image-3.16.0-4-amd64:amd64 3.16.7-ckt2-1 <aucune>
/var/log/dpkg.log.1:2014-12-30 19:50:42 configure linux-image-amd64:amd64 3.16+63 <aucune>

notice how that clever boy of yours uninstalled the previous kernel, making it
difficult to test the regression. i'll try to find one of those somewhere...

I believe the problem may have started in december. I recall having
similar issues in the past, but reloading the driver would always fix
it:

modprobe -r rtl8192ce
modprobe rtl8192ce

but now this doesn't work anymore. nothing short of a reboot can restore
proper wifi. this may be related to secure hotspots but since they are
so frequent nowadays it's hard to tell.

here's a typical failing NM chitchat:

Feb  1 22:44:24 angela NetworkManager[682]: <info> Activation (wlan0) starting connection 'CrapN6'
Feb  1 22:44:24 angela NetworkManager[682]: <info> Activation (wlan0) Stage 1 of 5 (Device Prepare) scheduled...
Feb  1 22:44:24 angela NetworkManager[682]: <info> Activation (wlan0) Stage 1 of 5 (Device Prepare) started...
Feb  1 22:44:24 angela NetworkManager[682]: <info> (wlan0): device state change: disconnected -> prepare (reason 'none') [30 40 0]
Feb  1 22:44:24 angela NetworkManager[682]: <info> NetworkManager state is now CONNECTING
Feb  1 22:44:24 angela NetworkManager[682]: <info> Activation (wlan0) Stage 2 of 5 (Device Configure) scheduled...
Feb  1 22:44:24 angela NetworkManager[682]: <info> Activation (wlan0) Stage 1 of 5 (Device Prepare) complete.
Feb  1 22:44:24 angela NetworkManager[682]: <info> Activation (wlan0) Stage 2 of 5 (Device Configure) starting...
Feb  1 22:44:24 angela NetworkManager[682]: <info> (wlan0): device state change: prepare -> config (reason 'none') [40 50 0]
Feb  1 22:44:24 angela NetworkManager[682]: <info> Activation (wlan0/wireless): access point 'CrapN6' has security, but secrets are required.
Feb  1 22:44:24 angela NetworkManager[682]: <info> (wlan0): device state change: config -> need-auth (reason 'none') [50 60 0]
Feb  1 22:44:24 angela NetworkManager[682]: <info> Activation (wlan0) Stage 2 of 5 (Device Configure) complete.
Feb  1 22:44:24 angela NetworkManager[682]: <info> Activation (wlan0) Stage 1 of 5 (Device Prepare) scheduled...
Feb  1 22:44:24 angela NetworkManager[682]: <info> Activation (wlan0) Stage 1 of 5 (Device Prepare) started...
Feb  1 22:44:24 angela NetworkManager[682]: <info> (wlan0): device state change: need-auth -> prepare (reason 'none') [60 40 0]
Feb  1 22:44:24 angela NetworkManager[682]: <info> Activation (wlan0) Stage 2 of 5 (Device Configure) scheduled...
Feb  1 22:44:24 angela NetworkManager[682]: <info> Activation (wlan0) Stage 1 of 5 (Device Prepare) complete.
Feb  1 22:44:24 angela NetworkManager[682]: <info> Activation (wlan0) Stage 2 of 5 (Device Configure) starting...
Feb  1 22:44:24 angela NetworkManager[682]: <info> (wlan0): device state change: prepare -> config (reason 'none') [40 50 0]
Feb  1 22:44:24 angela NetworkManager[682]: <info> Activation (wlan0/wireless): connection 'CrapN6' has security, and secrets exist.  No new secrets needed.
Feb  1 22:44:24 angela NetworkManager[682]: <info> Config: added 'ssid' value 'CrapN6'
Feb  1 22:44:24 angela NetworkManager[682]: <info> Config: added 'scan_ssid' value '1'
Feb  1 22:44:24 angela NetworkManager[682]: <info> Config: added 'key_mgmt' value 'WPA-PSK'
Feb  1 22:44:24 angela NetworkManager[682]: <info> Config: added 'auth_alg' value 'OPEN'
Feb  1 22:44:24 angela NetworkManager[682]: <info> Config: added 'psk' value '<omitted>'
Feb  1 22:44:24 angela NetworkManager[682]: <info> Activation (wlan0) Stage 2 of 5 (Device Configure) complete.
Feb  1 22:44:25 angela NetworkManager[682]: <info> Config: set interface ap_scan to 1
Feb  1 22:44:25 angela NetworkManager[682]: <info> (wlan0): supplicant interface state: disconnected -> scanning
Feb  1 22:44:35 angela wpa_supplicant[2160]: wlan0: SME: Trying to authenticate with f4:ec:38:e2:f9:68 (SSID='CrapN6' freq=2412 MHz)
Feb  1 22:44:35 angela NetworkManager[682]: <info> (wlan0): supplicant interface state: scanning -> authenticating
Feb  1 22:44:40 angela NetworkManager[682]: <info> (wlan0): supplicant interface state: authenticating -> disconnected
Feb  1 22:44:41 angela NetworkManager[682]: <info> (wlan0): supplicant interface state: disconnected -> scanning
Feb  1 22:44:50 angela NetworkManager[682]: <warn> Activation (wlan0/wireless): association took too long, failing activation.
Feb  1 22:44:50 angela NetworkManager[682]: <info> (wlan0): device state change: config -> failed (reason 'ssid-not-found') [50 120 53]
Feb  1 22:44:50 angela NetworkManager[682]: <info> NetworkManager state is now DISCONNECTED
Feb  1 22:44:50 angela NetworkManager[682]: <info> Disabling autoconnect for connection 'CrapN6'.
Feb  1 22:44:50 angela NetworkManager[682]: <warn> Activation (wlan0) failed for connection 'CrapN6'
Feb  1 22:44:50 angela NetworkManager[682]: <info> (wlan0): device state change: failed -> disconnected (reason 'none') [120 30 0]
Feb  1 22:44:50 angela NetworkManager[682]: <info> (wlan0): deactivating device (reason 'none') [0]
Feb  1 22:44:50 angela wpa_supplicant[2160]: wlan0: Reject scan trigger since one is already pending
Feb  1 22:44:50 angela NetworkManager[682]: <info> (wlan0): supplicant interface state: scanning -> disconnected
Feb  1 22:44:50 angela NetworkManager[682]: <warn> Couldn't disconnect supplicant interface: This interface is not connected.
Feb  1 22:44:50 angela NetworkManager[682]: <warn> Could not get scan request result: Scan request rejected

so the above is a timeout. it would often be followed by another similar
error, but notice the CONN_FAILED:


Feb  1 22:45:03 angela wpa_supplicant[2160]: wlan0: SME: Trying to authenticate with f4:ec:38:e2:f9:68 (SSID='CrapN6' freq=2412 MHz)
Feb  1 22:45:03 angela NetworkManager[682]: <info> (wlan0): supplicant interface state: disconnected -> authenticating
Feb  1 22:45:08 angela wpa_supplicant[2160]: wlan0: CTRL-EVENT-SSID-TEMP-DISABLED id=0 ssid="CrapN6" auth_failures=1 duration=10 reason=CONN_FAILED
Feb  1 22:45:08 angela NetworkManager[682]: <info> (wlan0): supplicant interface state: authenticating -> disconnected

wpa_supplicant would also warn me about:

Feb  1 22:45:51 angela wpa_supplicant[2160]: wlan0: Reject scan trigger since one is already pending
Feb  1 22:45:51 angela wpa_supplicant[2160]: wlan0: Failed to initiate AP scan

and here's the kind of things the kernel had to say for its sorry self:

Feb  1 22:45:03 angela kernel: [ 7509.781379] wlan0: authenticate with f4:ec:38:e2:f9:68
Feb  1 22:45:03 angela kernel: [ 7509.796904] wlan0: send auth to f4:ec:38:e2:f9:68 (try 1/3)
Feb  1 22:45:03 angela kernel: [ 7509.803235] wlan0: authenticated
Feb  1 22:45:08 angela kernel: [ 7514.799136] wlan0: aborting authentication with f4:ec:38:e2:f9:68 by local choice (Reason: 3=DEAUTH_LEAVING)
Feb  1 22:45:23 angela kernel: [ 7529.805590] wlan0: authenticate with f4:ec:38:e2:f9:68

i did try to swap out a new network card in this stupid machine, but the
equally stupid BIOS wouldn't let me.

yay proprietary hardware... :/

-- System Information:
Debian Release: 8.0
  APT prefers testing
  APT policy: (500, 'testing')
Architecture: amd64 (x86_64)

Kernel: Linux 3.16.0-4-amd64 (SMP w/2 CPU cores)
Locale: LANG=fr_CA.UTF-8, LC_CTYPE=fr_CA.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

firmware-realtek depends on no packages.

firmware-realtek recommends no packages.

Versions of packages firmware-realtek suggests:
ii  initramfs-tools  0.116

-- no debconf information

Message #10 received at 776816@bugs.debian.org (full text, mbox, reply):

From: Antoine Beaupré <anarcat@koumbit.org>

To: 776816@bugs.debian.org

Subject: Re: Bug#776816: Acknowledgement (firmware-realtek: fails to connect after a few suspends (or some uptime?))

Date: Wed, 18 Feb 2015 23:25:54 -0500

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.

Since this is a fairly serious regression, I think it's fair to mark
this as release-critical (hence the severity change).

More details on the wifi adapter:

04:00.0 Network controller [0280]: Realtek Semiconductor Co., Ltd. RTL8188CE 802.11b/g/n WiFi Adapter [10ec:8176] (rev 01)
Subsystem: Realtek Semiconductor Co., Ltd. Device [10ec:8195]
Physical Slot: 0
Flags: bus master, fast devsel, latency 0, IRQ 17
I/O ports at 2000 [size=256]
Memory at f0100000 (64-bit, non-prefetchable) [size=16K]
Capabilities: [40] Power Management version 3
Capabilities: [50] MSI: Enable- Count=1/1 Maskable- 64bit+
Capabilities: [70] Express Endpoint, MSI 00
Capabilities: [100] Advanced Error Reporting
Capabilities: [140] Virtual Channel
Capabilities: [160] Device Serial Number 01-91-81-fe-ff-4c-e0-00
Kernel driver in use: rtl8192ce

I'm of course available to debug any problems with this.

A.

Message #19 received at 776816@bugs.debian.org (full text, mbox, reply):

From: Ben Hutchings <ben@decadent.org.uk>

To: Antoine Beaupré <anarcat@koumbit.org>, 776816@bugs.debian.org

Subject: Re: Bug#776816: Acknowledgement (firmware-realtek: fails to connect after a few suspends (or some uptime?))

Date: Sat, 28 Feb 2015 23:08:50 +0000

[Message part 1 (text/plain, inline)]

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.

Ben.

-- 
Ben Hutchings
friends: People who know you well, but like you anyway.

[signature.asc (application/pgp-signature, inline)]

Message #28 received at 776816@bugs.debian.org (full text, mbox, reply):

From: Antoine Beaupré <anarcat@debian.org>

To: Ben Hutchings <ben@decadent.org.uk>, 776816@bugs.debian.org

Subject: Re: Bug#776816: firmware-realtek: fails to connect after a few suspends (or some uptime?)

Date: Sun, 22 Nov 2015 22:27:04 -0500

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"

Message #43 received at 776816-done@bugs.debian.org (full text, mbox, reply):

From: carnil@debian.org

To: 776816-done@bugs.debian.org

Cc: 776816-submitter@bugs.debian.org

Subject: Closing this bug (BTS maintenance for src:linux bugs)

Date: Sat, 08 May 2021 08:34:37 -0700 (PDT)

Hi

This bug was filed for a very old kernel or the bug is old itself
without resolution.

If you can reproduce it with

- the current version in unstable/testing
- the latest kernel from backports

please reopen the bug, see https://www.debian.org/Bugs/server-control
for details.

Regards,
Salvatore

Message #51 received at 776816-quiet@bugs.debian.org (full text, mbox, reply):

From: Antoine Beaupré <anarcat@debian.org>

To: carnil@debian.org

Cc: 776816-quiet@bugs.debian.org

Subject: Re: Bug#776816: Closing this bug (BTS maintenance for src:linux bugs)

Date: Sat, 08 May 2021 20:12:42 -0400

On 2021-05-08 08:34:37, carnil wrote:
> Hi
>
> This bug was filed for a very old kernel or the bug is old itself
> without resolution.
>
> If you can reproduce it with
>
> - the current version in unstable/testing
> - the latest kernel from backports
>
> please reopen the bug, see https://www.debian.org/Bugs/server-control
> for details.

makes sense, of course... i'm not even sure that machine still works, i
believe it died when it fell face first on the floor:

https://anarc.at/hardware/laptop/thinkpad-x120e/

Thanks for the tidying up, sorry I didn't do it myself!

a.

PS: I should probably go through the bugs I filed myself, by
chronological order, and close the oldest ones. ;)

-- 
Non qui parum habet, sed qui plus cupit, pauper est.
It is not the man who has too little, but the man who craves more,
that is poor.            - Lucius Annaeus Seneca (65 AD)

Message #56 received at 776816-quiet@bugs.debian.org (full text, mbox, reply):

From: Salvatore Bonaccorso <carnil@debian.org>

To: Antoine Beaupré <anarcat@debian.org>

Cc: 776816-quiet@bugs.debian.org

Subject: Re: Bug#776816: Closing this bug (BTS maintenance for src:linux bugs)

Date: Sun, 9 May 2021 08:33:32 +0200

Hi Antoine,

On Sat, May 08, 2021 at 08:12:42PM -0400, Antoine Beaupré wrote:
> On 2021-05-08 08:34:37, carnil wrote:
> > Hi
> >
> > This bug was filed for a very old kernel or the bug is old itself
> > without resolution.
> >
> > If you can reproduce it with
> >
> > - the current version in unstable/testing
> > - the latest kernel from backports
> >
> > please reopen the bug, see https://www.debian.org/Bugs/server-control
> > for details.
> 
> makes sense, of course... i'm not even sure that machine still works, i
> believe it died when it fell face first on the floor:
> 
> https://anarc.at/hardware/laptop/thinkpad-x120e/
> 
> Thanks for the tidying up, sorry I didn't do it myself!

Thanks for confirming in any case, additional reason to close the bug
if the hardware is not really anymore "available". 

> a.
> 
> PS: I should probably go through the bugs I filed myself, by
> chronological order, and close the oldest ones. ;)

If you have spare cycles to review those, this surely would be much
appreciated :)

Regards,
Salvatore

Send a report that this bug log contains spam.