yeah, canonical, is anyone there?!
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to network-manager in Ubuntu.
https://bugs.launchpad.net/bugs/1585863
Title:
WiFi malfunction after suspend & resume stress - sudo wpa_cli
@auspex: Your script doesn't work here. I just created it and gave it
execution permissions, rebooted and tried a sleep/resume cycle. No dice.
I'm just amazed no one from Canonical is chiming in. This has been
happening from the very moment I installed 16.04 on its release day and
it happens in
> Nobody at Canonical suffers from this problem?
LOL I don't think anybody at Canonical actually uses it, otherwise it
couldn't possibly be as broken as it is.
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to network-manager
Bug# 1455097 "/etc/pm/sleep.d/ is no more processed" confirms that any
solution involving "/etc/pm/sleep.d/" will not work since systemd took
over. auspex solution works (thank you), although in my case, I simply
restart the Network Manager (systemctl restart network-manager) to be
really sure
I can confirm that this also happens when toggling the radio killswitch
on my x230 with Xenial:
Jul 26 09:48:19 Host NetworkManager[2979]: [1469540899.8669] manager:
WiFi now enabled by radio killswitch
Jul 26 09:48:19 Host kernel: [71025.599893] IPv6: ADDRCONF(NETDEV_UP): wlan0:
link is not
I finally worked around my problem by adding a script in /lib/systemd
/system-sleep/:
$ cat /lib/systemd/system-sleep/12_wifi
#!/bin/bash
case $1 in
"post")
# disable/enable wifi
rfkill block wifi; rfkill unblock wifi
logger "reenabled wifi"
;;
Don't know about others but my Dell's notebook is not only loosing the wifi,
after sleep it is not waking up anymore.I need to power off it...
In the log I think I just see these: /lib/systemd/system-sleep/wpasupplicant
failed with error code 255.
--
You received this bug notification because
because restarting network-manager from sleep.d isn't even a workaround,
let alone a fix. With that, my network successfully reconnects just
about as often as if there is nothing in sleep.d.
Which, apparently, would be because /etc/pm/sleep.d is never invoked.
--
You received this bug
101 - 108 of 108 matches
Mail list logo
