WiFI disabled on resume from sleep - Bionic64

[courtage]

This is very very annoying.

Without having changed any of the configuration so far as I am aware, my Dell 1545 running Puppy Bionic64 with @rockedge 's realtime kernel has suddenly started refusing to reconnect the wifi on resume from sleep.

This has worked fine for years: Close lid, ACPI puts machine to sleep; open lid, system resumes, wifi comes up & reconnects.

Now, it's stopped: The wifi is dead on resume about 60% of the time (Ah the joys of the intermittent fault.)

If I immediately run the network wizard, and click "test interface", it reports "Puppy was able to find a live network".

If I then select Wireless & select & load the correct profile for my network, it fails to connect, and the details box gives

Code: Select all

wpa_state=INTERFACE_DISABLED
address=00:08:ca:cb:30:f5
uuid=917838bf-4202-59a5-81cc-b7b52046951e

if we look at the output from rfkill we see:

Code: Select all

root# rfkill list
0: phy0: wlan
    Soft blocked: no
    Hard blocked: no

Output from ifconfig shown in screenshot:

screenshotbrokennetwl.png (298.75 KiB) Viewed 369 times

Note that

Code: Select all

ifconfig wlan0 up 

doesn't fix it either.

The acpi stuff in /etc/acpi is stock - I haven't *ever* touched that.

lspci:

Code: Select all

root# lspci
[stuff snipped]
09:00.0 Ethernet controller: Marvell Technology Group Ltd. 88E8040 PCI-E Fast Ethernet Controller (rev 13)
0c:00.0 Network controller: Qualcomm Atheros AR9285 Wireless Network Adapter (PCI-Express) (rev 01)

Here's /var/log/messages from the time of the last suspend through the resume.

Code: Select all

Nov 28 15:58:13 puppypc1545 kern.info kernel: PM: suspend entry (deep)
Nov 28 15:58:13 localhost vmunix: PM: Syncing filesystems ... done.
Nov 28 18:57:06 localhost vmunix: usb usb4: root hub lost power or was reset
Nov 28 18:57:06 localhost vmunix: atkbd serio0: Unknown key pressed (translated set 2, code 0x8d on isa0060/serio0).
Nov 28 18:57:06 localhost vmunix: atkbd serio0: Use 'setkeycodes e00d <keycode>' to make it known.
Nov 28 18:57:06 localhost vmunix: usb usb6: root hub lost power or was reset
Nov 28 18:57:06 localhost vmunix: usb usb7: root hub lost power or was reset
Nov 28 18:57:06 localhost vmunix: atkbd serio0: Unknown key pressed (translated set 2, code 0x8d on isa0060/serio0).
Nov 28 18:57:06 localhost vmunix: atkbd serio0: Use 'setkeycodes e00d <keycode>' to make it known.
Nov 28 18:57:06 localhost vmunix: usb usb8: root hub lost power or was reset
Nov 28 18:57:06 localhost vmunix: ata5: SATA link down (SStatus 0 SControl 300)
Nov 28 18:57:06 localhost vmunix: ata2: SATA link up 1.5 Gbps (SStatus 113 SControl 300)
Nov 28 18:57:06 localhost vmunix: ata6: SATA link down (SStatus 0 SControl 300)
Nov 28 18:57:06 localhost vmunix: usb 1-5: reset high-speed USB device number 2 using ehci-pci
Nov 28 18:57:06 localhost vmunix: ata2.00: configured for UDMA/100
Nov 28 18:57:06 localhost vmunix: ata1: SATA link up 3.0 Gbps (SStatus 123 SControl 300)
Nov 28 18:57:06 localhost vmunix: ata1.00: configured for UDMA/133
Nov 28 18:57:06 localhost vmunix: OOM killer enabled.
Nov 28 18:57:06 puppypc1545 kern.info kernel: Freezing user space processes ... (elapsed 0.016 seconds) done.
Nov 28 18:57:06 puppypc1545 kern.info kernel: OOM killer disabled.
Nov 28 18:57:06 puppypc1545 kern.info kernel: Freezing remaining freezable tasks ... (elapsed 0.001 seconds) done.
Nov 28 18:57:06 puppypc1545 kern.info kernel: Suspending console(s) (use no_console_suspend to debug)
Nov 28 18:57:06 puppypc1545 kern.info kernel: wlan0: deauthenticating from 34:49:5b:ed:74:2e by local choice (Reason: 3=DEAUTH_LEAVING)
Nov 28 18:57:06 puppypc1545 kern.notice kernel: sd 0:0:0:0: [sda] Synchronizing SCSI cache
Nov 28 18:57:06 puppypc1545 kern.notice kernel: sd 0:0:0:0: [sda] Stopping disk
Nov 28 18:57:06 puppypc1545 kern.info kernel: ACPI: Preparing to enter system sleep state S3
Nov 28 18:57:06 puppypc1545 kern.info kernel: PM: Saving platform NVS memory
Nov 28 18:57:06 puppypc1545 kern.info kernel: Disabling non-boot CPUs ...
Nov 28 18:57:06 puppypc1545 kern.info kernel: smpboot: CPU 1 is now offline
Nov 28 18:57:06 puppypc1545 kern.info kernel: ACPI: Low-level resume complete
Nov 28 18:57:06 puppypc1545 kern.info kernel: PM: Restoring platform NVS memory
Nov 28 18:57:06 puppypc1545 kern.info kernel: Enabling non-boot CPUs ...
Nov 28 18:57:06 puppypc1545 kern.info kernel: x86: Booting SMP configuration:
Nov 28 18:57:06 puppypc1545 kern.info kernel: smpboot: Booting Node 0 Processor 1 APIC 0x1
Nov 28 18:57:06 puppypc1545 kern.warn kernel:  cache: parent cpu1 should not be sleeping
Nov 28 18:57:06 puppypc1545 kern.info kernel: CPU1 is up
Nov 28 18:57:06 puppypc1545 kern.info kernel: ACPI: Waking up from system sleep state S3
Nov 28 18:57:06 puppypc1545 kern.info kernel: ath: phy0: ASPM enabled: 0x43
Nov 28 18:57:06 puppypc1545 kern.notice kernel: usb usb3: root hub lost power or was reset
Nov 28 18:57:06 puppypc1545 kern.notice kernel: usb usb5: root hub lost power or was reset
Nov 28 18:57:06 puppypc1545 kern.notice kernel: sd 0:0:0:0: [sda] Starting disk
Nov 28 18:57:06 localhost vmunix: Restarting tasks ... done.
Nov 28 18:57:07 puppypc1545 kern.info kernel: video LNXVIDEO:01: Restoring backlight state
Nov 28 18:57:07 localhost vmunix: PM: suspend exit
Nov 28 18:57:07 puppypc1545 kern.warn kernel: atkbd serio0: Unknown key pressed (translated set 2, code 0x8d on isa0060/serio0).
Nov 28 18:57:07 puppypc1545 kern.warn kernel: atkbd serio0: Use 'setkeycodes e00d <keycode>' to make it known.
Nov 28 18:57:08 puppypc1545 kern.info kernel: wlan0: authenticate with 34:49:5b:ed:74:2e
Nov 28 18:57:08 puppypc1545 kern.info kernel: wlan0: send auth to 34:49:5b:ed:74:2e (try 1/3)
Nov 28 18:57:08 puppypc1545 kern.info kernel: wlan0: authenticated
Nov 28 18:57:08 puppypc1545 kern.info kernel: wlan0: associate with 34:49:5b:ed:74:2e (try 1/3)
Nov 28 18:57:08 puppypc1545 kern.info kernel: wlan0: RX AssocResp from 34:49:5b:ed:74:2e (capab=0x431 status=0 aid=2)
Nov 28 18:57:08 puppypc1545 kern.info kernel: wlan0: associated
Nov 28 18:57:08 puppypc1545 kern.debug kernel: ath: EEPROM regdomain: 0x833a
Nov 28 18:57:08 puppypc1545 kern.debug kernel: ath: EEPROM indicates we should expect a country code
Nov 28 18:57:08 puppypc1545 kern.debug kernel: ath: doing EEPROM country->regdmn map search
Nov 28 18:57:08 puppypc1545 kern.debug kernel: ath: country maps to regdmn code: 0x37
Nov 28 18:57:08 puppypc1545 kern.debug kernel: ath: Country alpha2 being used: GB
Nov 28 18:57:08 puppypc1545 kern.debug kernel: ath: Regpair used: 0x37
Nov 28 18:57:08 puppypc1545 kern.debug kernel: ath: regdomain 0x833a dynamically updated by country element
Nov 28 18:58:00 localhost vmunix: wlan0: deauthenticating from 34:49:5b:ed:74:2e by local choice (Reason: 3=DEAUTH_LEAVING)
Nov 28 18:58:02 localhost vmunix: wlan0: authenticate with 34:49:5b:ed:74:2e
Nov 28 18:58:02 puppypc1545 kern.info kernel: wlan0: send auth to 34:49:5b:ed:74:2e (try 1/3)
Nov 28 18:58:02 puppypc1545 kern.info kernel: wlan0: authenticated
Nov 28 18:58:02 puppypc1545 kern.info kernel: wlan0: associate with 34:49:5b:ed:74:2e (try 1/3)
Nov 28 18:58:02 localhost vmunix: wlan0: RX AssocResp from 34:49:5b:ed:74:2e (capab=0x431 status=0 aid=2)
Nov 28 18:58:02 localhost vmunix: wlan0: associated
Nov 28 18:58:43 localhost vmunix: wlan0: deauthenticating from 34:49:5b:ed:74:2e by local choice (Reason: 3=DEAUTH_LEAVING)

The only way to reconnect is to reboot.

This is driving me up the f'ing wall.

I wondered if it could be bios-related (maybe the coincell needs replacing & the wifi is getting switched off?) -- but then I'm not seeing any bios errors on a cold or warm boot.

hlep/

[bigpup]

To fully understand.

running Puppy Bionic64 with @rockedge 's realtime kernel

This did not start being a problem, after switching to this kernel?
It has worked OK, for some time, with this kernel?

There is nothing you have installed, just before this problem started?

Have you run Quickpet->Info->Bionicpup updates and rebooted, so changes are saved and are being used?

[bigpup]

Do you have a lot of wifi signals detected in your area?
If yes.

With all those different WIFI signals in your area.

Consider seeing what channels they are using as compared to the channel you are using.

It is best if you set your WIFI transmitter router to use a channel someone else is not using.

Your WIFI router should have settings to change the channel it uses.

Selecting the proper WiFi channel can significantly improve your WiFi coverage and performance. In the 2.4 GHz band, 1, 6, and 11 are the only non-overlapping channels. Selecting one or more of these channels is an important part of setting up your network correctly.

Each channel on the 2.4 GHz spectrum is 20 MHz wide. The channel centers are separated by 5 MHz, and the entire spectrum is only 100 MHz wide. This means the 11 channels have to squeeze into the 100 MHz available, and in the end, overlap.

However, there are three channels that don’t overlap: 1, 6 and 11. Co-channel interference is where devices take turns talking, so the more devices on one channel, the longer it takes for a device to talk since it has to wait for its turn.

Channel 11 seems to be used a lot, as the default channel, set by the manufactures. At least, all the wifi routers I have used, were preset to channel 11.

The 5GHz wifi devices are a big improvement for several reasons.

5 GHz
24 non-overlapping channels.
Little WiFi congestion
Very little non-WiFi interference

Note:
Network Wizard.
When you select scan to see what wifi signals are available.
A list of what is found in area is made.
The list is the names of the wifi routers found and if encryption on/off.
To see info about the channel used.
Hover over the router name and more info will show.

In terminal can use this command to get channel info.

Code: Select all

iwlist wlan0 s

[rerwin]

courtage,

Do either of the other network managers also encounter this problem?

If so, please consider trying the latest versions from viewtopic.php?p=2241#p2241:

• Network_connect_update-20200722

• Simple_network_setup-2.4

• Frisbee-2.0

• Network_wizard-2.1.3 -- needed for NetWiz use with Network_connect_update-20200722

Richard

[rockedge]

Did the WiFi connection work correctly with the RT kernel at some point before this condition occured?

[courtage]

For everybody asking, it has worked fine with the rt kerne for at least a year.

It just started happening out of the blue within the last couple of weeks.

I have installed/uninstalled other packages, I do that all the time like many people.
these are the most recent:

Code: Select all

vivaldi-stable_3.4.2066.106.files
inetutils-syslogd_1.9.4-3.files
inetutils-ftpd_1.9.4-3.files
ftpd-ssl_0.17.36+0.3-2.files
dconf-editor_3.28.0-1.files
dconf-cli_0.26.0.files

[bigpup]

courtage,

Answer rerwin's questions?

He is the Puppy Linux expert on network connection stuff, and the Puppy software for controlling it.
He actively maintains the network connection managers in Puppy and keeps them updated.

I assume Bionicpup64 8.0 is a frugal install using a save file or folder.
Could try and boot not using the save and see what sleep does.
If wifi reconnect now works OK.
That will tell us something in the save is causing the problem.

I do wonder why you installed inetutils stuff from the Puppy Package Manager(PPM)?
You should not need to.

[courtage]

OOps sorry @rockedge @rerwin I forgot to report back.

It all started working perfectly again when I setup networking using Frisbee.

I didn't install any of the updates suggested first, I just tried Frisbee as the first option to see how it went.

Since then I've never had a single similar problem - it always reconnects on resume, and it always connects automatically on reboot.

WHY it stopped working in the first place is going to have to remain a mystery.

[rerwin]

courtage,

Thank you for your report. I am pleased that frisbee works for you.

This gives me something more to try with NetWiz and SNS. I have never used the resume function, so it should be interesting on my netbook.