Networkmanager does not autoconnect to wireless network

[Søren Holm]

When adding a net wireless network and enable "connect automatically' networkmanager does not automatically connect to the network wenever possible.

I'm running kubuntu 14.10 daily.

ProblemType: Bug
DistroRelease: Ubuntu 14.10
Package: network-manager 0.9.8.8-0ubuntu23
ProcVersionSignature: Ubuntu 3.16.0-6.11-generic 3.16.0-rc7
Uname: Linux 3.16.0-6-generic x86_64
ApportVersion: 2.14.5-0ubuntu4
Architecture: amd64
CurrentDesktop: KDE
Date: Sun Aug 10 21:30:03 2014
IfupdownConfig:
 # interfaces(5) file used by ifup(8) and ifdown(8)
 auto lo
 iface lo inet loopback
InstallationDate: Installed on 2014-07-11 (29 days ago)
InstallationMedia: Kubuntu 14.10 "Utopic Unicorn" - Alpha amd64 (20140710)
IpRoute:
 default via 192.168.0.2 dev wlan0 proto static
 192.168.0.0/24 dev wlan0 proto kernel scope link src 192.168.0.213 metric 9
SourcePackage: network-manager
UpgradeStatus: No upgrade log present (probably fresh install)
nmcli-dev:
 DEVICE TYPE STATE DBUS-PATH
 wlan0 802-11-wireless connected /org/freedesktop/NetworkManager/Devices/1
 eth0 802-3-ethernet unavailable /org/freedesktop/NetworkManager/Devices/0
nmcli-nm:
 RUNNING VERSION STATE NET-ENABLED WIFI-HARDWARE WIFI WWAN-HARDWARE WWAN
 running 0.9.8.8 connected enabled enabled enabled enabled disabled

[Søren Holm (sgh)]

Do you have any good ideas as to what I could try out to figure out what's wrong?

[Søren Holm (sgh)]

After getting KDE 4.14 I tired to remove all the wifi connections and add them again. Now everything seems to be alright.

[Søren Holm (sgh)]

I reopened the bug since it's still present. My comment above is still valid, but auto connecting stops working when suspending to ram or rebooting. So basically the desired behavior can be obtained temporarily by removing and adding the network in question.

[BadBoy (sklep-szybkieczytanie)]

I confirm this annoying bug. I think it does not connect even after a fresh reboot.

[Launchpad Janitor (janitor)]

Status changed to 'Confirmed' because the bug affects multiple users.

[Søren Holm (sgh)]

Do you have a possibility to try kubuntu 14.10 installed from scratch. Maybe some upgrade-path related issue is at stake here.

Also - I think this _must_ be resolved for 14.10

[Søren Holm (sgh)]

I can add that flipping ipv5 setting to "ignore" and then back to "automatic" makes auto connection work again. I do think that it is needed for every reboot though. But it's a workaround.

[Jeremielapuree (jeremielapuree)]

With the stable ubuntu 14.10, this bug occurs for me too :(

[Søren Holm (sgh)]

That makes me happy and sad at the same time. Happy because this bug is really
annoying and maybe it can get some attention, and sad because it's present in
14.10 and potentially a lot of users will now end up fight to get wireless
connecting.

[dyug (dyug)]

this bug include automatic wired connect too

[Magnus (koma-lysator)]

This has started to happen to me as well after upgrading to 14.10.

I have two ethernet NICs in my computer, and I only use eth1.

I have to manually select it in the network manager list in order to get any network connection after logging in.

[Adolph J. Vogel (ajvogel-d)]

I also experienced this annoying bug after upgrading to 14.10. I think I found a work around.

According to SteveRiley, on the Kubuntu Forum, if you enable "All users may connect to this network" in the settings, then the connection does autoconnect. I tried this once or twice with my wifi networks and it seems to work.

https://www.kubuntuforums.net/showthread.php?66702-NetworkManagement-widget-not-connecting-to-wifi-automatically&p=361413

[João Pedro (jpgomes)]

This bug also appeared to me after upgrading to 14.10. Network Manager doesn't connect automatically after boot or after resume from suspend.
I followed the previous suggestion (enable "All users may connect to this network" in the wifi connection setting) and it worked for me.
Curiously, I made a few tests and if after enable that option I disable it again Network Manager still reconnects after resume from suspend (but not after reboot).

[Søren Holm (sgh)]

To sum up.

1. New connections always reconnect.
2. After reboot connections does NOT reconnect.
3. Allowing all users to connect makes auto-connection work even after reboot.

[Scarlett Gately Moore (scarlettmoore)]

I can confirm this on my laptop 14.10 with KDE4 my network does not auto reconnect on reboot or sleep or suspend. My KF5/Plasma 5 desktop does not suffer from this at all.

[Scarlett Gately Moore (scarlettmoore)]

This is an upstream bug:

https://bugs.kde.org/show_bug.cgi?id=339674

[Paul Loughman (snowhog)]

From reply #13:

According to SteveRiley, on the Kubuntu Forum, if you enable "All users may connect to this network" in the settings, then the connection does autoconnect. I tried this once or twice with my wifi networks and it seems to work.

https://www.kubuntuforums.net/showthread.php?66702-NetworkManagement-widget-not-connecting-to-wifi-automatically&p=361413

This does not work for me.

PC: HP Pavilion g7-1070us 64-bit i3
02:00.0 Network controller: Broadcom Corporation BCM4313 802.11bgn Wireless Network Adapter (rev 01)
03:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL8101E/RTL8102E PCI Express Fast Ethernet controller (rev 05)

I was running Kubuntu 14.04.1 w/KDE 4.14.2 perfectly on this laptop. I was fully dist-upgraded and did a release upgrade from the console: sudo do-release-upgrade -d

When it finished and I rebooted, network-manager did not auto-start. Before the KDM login screen, these two messages were presented:

Waiting for network configuration...

then after awhile,

Waiting up to 60 more seconds for network configuration...

At the end of the 60 seconds, KDM login screen presented and I logged in. I had no network connections. Running sudo service network-manager start from the console started both my ethernet and wireless connections.

Editing both connections and marking "All users may connect to this network" in the settings DOES NOT servive a logout/reboot. I really would like to know why, and how to remedy this.

The only thing I can point to is the message that a 'fatal error occured' right at the end of the release-upgrade process:

Total disk space freed by localepurge: 0 KiB

Error in function:

A fatal error occurred

Please report this as a bug and include the files
/var/log/dist-upgrade/main.log and /var/log/dist-upgrade/apt.log in
your report. The upgrade has aborted.
Your original sources.list was saved in
/etc/apt/sources.list.distUpgrade.

SystemError: E:Sub-process /usr/bin/dpkg returned an error code (1)

Error during commit

A problem occurred during the clean-up. Please see the below message
for more information.

installArchives() failed

System upgrade is complete.

Restart required

To finish the upgrade, a restart is required.
If you select 'y' the system will be restarted.
y

Does anyone have information as to what caused this?

[Paul Loughman (snowhog)]

/var/log/dist-upgrade/main.log and /var/log/dist-upgrade/apt.log attached.

[Paul Loughman (snowhog)]

/var/log/upstart/networking.log attached.

[Paul Loughman (snowhog)]

SOLVED!!!

The hint to the solution was the content of networking.log:

run-parts: failed to exec /etc/network/if-up.d/static-routes: Exec format error
run-parts: /etc/network/if-up.d/static-routes exited with return code 1
Failed to bring up lo.
run-parts: failed to exec /etc/network/if-up.d/static-routes: Exec format error
run-parts: /etc/network/if-up.d/static-routes exited with return code 1
ifup: post-up script failed.

So I compared the /etc/network/if-up.d directories on my working 32-bit and 64-bit laptops. The difference was a single executable file on the 64-bit affected laptop but not on the unaffected 32-bit laptop:

-rwxr-xr-x 1 root root 351 Oct 17 16:25 static-routes

Which contains:

ip route add unreachable 10.0.0.0/8 metric 999
ip route add unreachable 172.16.0.0/12 metric 999
ip route add unreachable 192.168.0.0/16 metric 999
ip route add unreachable 169.254.0.0/16 metric 999
ip route add unreachable 192.0.2.0/24 metric 999
ip route add unreachable 198.51.100.0/24 metric 999
ip route add unreachable 203.0.113.0/24 metric 999

I removed the executable bit (sudo chmod -x) and logged out and rebooted. My network was auto-started as it should!! I don't know why the release-upgrade put it there (I assume it did), but it was the culprit in this fiasco.

[Søren Holm (sgh)]

I can not see that file on my system.

I have these files.

-rwxr-xr-x 1 root root 549 Jan 18 2013 000resolvconf
-rwxr-xr-x 1 root root 881 Dec 30 2013 avahi-autoipd
-rwxr-xr-x 1 root root 484 Dec 30 2013 avahi-daemon
-rwxr-xr-x 1 root root 1675 Jan 28 2014 ethtool
-rwxr-xr-x 1 root root 1298 Apr 3 2013 ntpdate
-rwxr-xr-x 1 root root 945 Aug 13 01:59 openssh-server
-rwxr-xr-x 1 root root 374 May 2 2014 openvpn
-rwxr-xr-x 1 root root 1483 Jan 6 2013 upstart
lrwxrwxrwx 1 root root 32 Oct 10 16:53 wpasupplicant ->
../../wpa_supplicant/ifupdown.sh

[Hervé Fache (rvfh)]

ROTFL

So we have a *release* of what is meant to be one of the most important/mainstream distributions where the network management is broken, and this is *Medium*!?!

Are you kidding me? No wonder why my colleagues always have a stock of jokes about Linux for me.

This is not serious. This should be one of the first tests to be run: does the network manager actually manage the network? And from what I see, this was reported 2 months before the release...

[Hervé Fache (rvfh)]

I have rolled back the following packages to their trusty versions, to no avail:
* network-manager
* plasma-widget-networkmanagement
* plasma-nm (needs an extra dependency)
* wpasupplicant

I suppose something is meant to trigger the connection when the user logs in, which I wrongly thought was the startup of the plasma-nm widget. I suppose I need to talk to the KDE guys directly if I want to help more...

[Søren Holm (sgh)]

Hervé - you are right. I works as a software developer and this bug would clearly be a blocker - meaning that we cannot realease until it's resolved. Simple John Joe tpye of things must always work. I know little of any about networkmanager, but given the right instructions I'd be able to debug it.

[Denis Garcia (denis.garci)]

Hi, I have a similar problem on my X230. I was previously using Arch and didn't have that bug. How can I help?

[Hervé Fache (rvfh)]

Søren, Denis,

Apparently, the KDE guys who worked on plasma-nm consider the bug to be somewhere else in the stack, maybe in network manager. Has one of you got a Ubuntu 14.10 to test this? If it works with Unity, then we know it's KDE-related.

Maybe this can be tested using a Live USB key:
* make key for Ubuntu 14.10
* setup WiFi
* put in standby
* resume
- > does it auto-reconnect?

Then do the same for Kubuntu 14.10...

I am sorry I don't have enough time right now to do it myself :-(

BTW, if it works in both cases, then it may be an upgrade issue and we would have to compare the config files between the Live and failing systems around network manager/network.

Thanks!

[Søren Holm (sgh)]

I'll try it out today.

[Søren Holm (sgh)]

Ok - these are the facts while trying out Ubuntu 14.10. I did not try Kubuntu 14.10 from USB because the steps below results in the exact same weirdnesses on the Kubuntu 14.10 install I have,

1. Create boot disk - reserve 1GB for storage.
2. Boot the from USB
3. Setup wifi - it connects.
4. Setup that not all users may connect - yes, "allow all" is the default setting.
5. Suspend
6. Resume
7. Wifi connects.

This all looks good - and the same thing happens on my installed Kubuntu when setting up new network connections. But not it gets weird.

8. Reboot on the USB flash
9. Watch wifi - it does not connect.
10. Connected manually - it connects.
11. suspend
12. resume
13. watch wifi - it does not connect.
14. Change any setting in relation to the connection. I changed IPv4 from DHCP to Link-Local
15. Change the setting back again.
16. Wathc the wifi - it connects.

[Denis Garcia (denis.garci)]

Hey,

So I just tried with an Ubuntu 14.10 live USB key and after resuming the wifi reconnects. With the Kubuntu 14.10 live USB after the resume it asks for the wifi password again...

[Søren Holm (sgh)]

FWIT it works in debian unable

network-manager 0.9.10.0-3
plasma-nm 0.9.3.4-2
plasma-widget-networkmanagement 0.9.3.4-2

[Søren Holm (sgh)]

I take my previous comment back. Debian unstable also does this.

[Søren Holm (sgh)]

Debian actually does not have this problem after all..... does that help anything?

[Mark (mark-wege)]

I have this bug too. I first thought this must be a personal bug, somehow from the upgrade. But then I installed Kubuntu on several other systems. All fresh. All have the bug. How could Kubuntu be release with it? This should have been a release blocker. Now many weeks after the release it is still around and the status is still medium?

[Bandicoot (andrew-beals)]

I am also seeing this after upgrading my main laptop from 14.04 LTE to 14.10. The fix for me is to sudo service start network-manager after I log in. While this is the first release upgrade show-stopper I've seen since the 6.04 -> 8.04 mishegas, this says to me that the testers are not using the same environment those of us who are seeing it use - if I had to guess, they're testing in a server environment (fine for LTE releases) and not Ubuntu-as-desktop. I'm wagering that the ugly hack of adding "service network-manager start" (or /etc/init.d/network-manager start) to /etc/rc.local is a work-around.

[Sergey Skripnick (eyerediskin)]

The same story with fresh ubuntu-14.10 on asus pu301 laptop

[guysoft (guysoft)]

Same problem on Asus Zenbook UX32VD, Kubuntu 14.10. I have to run this each time I open my laptop from suspend:

    sudo /etc/init.d/network-manager stop ; sleep 2 ; sudo /etc/init.d/network-manager start

Otherwise I can't see my wireless adapter in network manager. Note its visible if I run 'ifconfig'.

[tobiasBora (tobias-bora)]

I can confirm I've the same (very annoying) bug. I don't have the file that Paul L. is talking about, but when I do "sudo service network-manager restart" it works (but it's dirty, even in the /etc/rc.local folder).

I don't know if it can be useful but here are some logs (I aslept and awoke my laptop) :
$ cat /var/log/syslog | grep -i network
Dec 23 17:13:36 tblinux NetworkManager[1003]: <info> sleep requested (sleeping: no enabled: yes)
Dec 23 17:13:36 tblinux NetworkManager[1003]: <info> sleeping or disabling...
Dec 23 17:13:36 tblinux NetworkManager[1003]: <info> (eth0): device state change: unavailable -> unmanaged (reason 'sleeping') [20 10 37]
Dec 23 17:13:36 tblinux NetworkManager[1003]: <info> (eth0): cleaning up...
Dec 23 17:13:36 tblinux NetworkManager[1003]: <info> (eth0): taking down device.
Dec 23 17:13:37 tblinux NetworkManager[1003]: <info> NetworkManager state is now ASLEEP
Dec 23 17:13:37 tblinux NetworkManager[1003]: <info> (wlan0): device state change: activated -> unmanaged (reason 'sleeping') [100 10 37]
Dec 23 17:13:37 tblinux NetworkManager[1003]: <info> (wlan0): deactivating device (reason 'sleeping') [37]
Dec 23 17:13:37 tblinux NetworkManager[1003]: <info> (wlan0): canceled DHCP transaction, DHCP client pid 5018
Dec 23 17:13:37 tblinux NetworkManager[1003]: <warn> DNS: plugin dnsmasq update failed
Dec 23 17:13:37 tblinux NetworkManager[1003]: <info> Removing DNS information from /sbin/resolvconf
Dec 23 17:13:38 tblinux NetworkManager[1003]: <info> (wlan0): cleaning up...
Dec 23 17:13:38 tblinux NetworkManager[1003]: <info> (wlan0): taking down device.
Dec 23 17:13:38 tblinux NetworkManager[1003]: <info> (D0:C1:B1:5F:55:D9): device state change: disconnected -> unmanaged (reason 'sleeping') [30 10 37]
Dec 23 17:13:38 tblinux NetworkManager[1003]: <info> (D0:C1:B1:5F:55:D9): cleaning up...
Dec 23 17:13:38 tblinux NetworkManager[1003]: <info> (D0:C1:B1:5F:55:D9): taking down device.
Dec 23 17:13:45 tblinux NetworkManager[1003]: <info> BT device D0:C1:B1:5F:55:D9 removed
Dec 23 17:13:46 tblinux NetworkManager[1003]: <info> wake requested (sleeping: yes enabled: yes)
Dec 23 17:13:46 tblinux NetworkManager[1003]: <info> waking up and re-enabling...
Dec 23 17:13:46 tblinux NetworkManager[1003]: <info> (eth0): device state change: unmanaged -> unavailable (reason 'managed') [10 20 2]
Dec 23 17:13:46 tblinux NetworkManager[1003]: <info> (eth0): bringing up device.
Dec 23 17:13:46 tblinux NetworkManager[1003]: <info> (eth0): preparing device.
Dec 23 17:13:46 tblinux NetworkManager[1003]: <info> (eth0): deactivating device (reason 'managed') [2]
Dec 23 17:13:46 tblinux NetworkManager[1003]: <info> Unmanaged Device found; state CONNECTED forced. (see http://bugs.launchpad.net/bugs/191889)
Dec 23 17:13:46 tblinux NetworkManager[1003]: <info> Unmanaged Device found; state CONNECTED forced. (see http://bugs.launchpad.net/bugs/191889)
Dec 23 17:13:46 tblinux NetworkManager[1003]: <info> NetworkManager state is now CONNECTED_GLOBAL
Dec 23 17:13:46 tblinux NetworkManager[1003]: <info> Unmanaged Device found; state CONNECTED forced. (see http://bugs.launchpad.net/bugs/191889)
Dec 23 17:13:46 tblinux NetworkManager[1003]: <info> (wla...

[tobiasBora (tobias-bora)]

Is it possible that the wifi is loaded after network-manager, so that network-manager cannot reconnect ?

[Nick B. (futurepilot)]

I've got this same problem too. After doing a fresh boot and logging in, the wireless will not connect but it is listed in the plasma-nm connection list. I've found that if I delete it and re-add the connection it will automatically reconnect after suspend/hibernate until the next reboot or login. Then it breaks again.

Is anyone else using a hidden network? I'm wondering if that's related.

[Péter Horváth (tentacle)]

I have the same problem in Kubuntu 14.10 after upgrading from 14.04, auto connect never happens (not after reboot and neither after suspend or router reboot). It's quite annoying and I also think this bug should have a higher priority, this is a very basic feature. I have the user restriction enabled, I'll see what happens if I allow automatic connection for all users as suggested above.

[chris.rapson (chris-rapson-9)]

I agree with Hervé, Søren & Mark. How do we get a higher priority for this?

Also, Søren, I don't fully understand you comments #32,34,35,36. I think you're saying it's not a debian problem? It originates in the ubuntu packages, and therefore also affects kubuntu users?

[Søren Holm (sgh)]

The spelling is bad in #32 but the essence is that the problem persists on Unity, so it is not a desktop related problem (KDE, Unity, etc)

The later comments just state that Debian Unstable works, and since Ubuntu is based on Debian Unstable that might help people tracking down what's wrong.

[Pavel Sokolov (hacker-cb)]

I have same problem on on my Lenovo X240 laptop.
WiFi never reconnect after sleep or reboot.

[metRo_ (josescxavier)]

I'm getting the same bug too. I'm on a macbook retina mid-2014. Any log or info that I should share just ask for it.

[tobiasBora (tobias-bora)]

I don't know if it's linked but I'm playing with a Wifi rooteur and I often change the name/encryption of the device, and to refresh the list of the devices the refresh button isn't enough : sometimes it detect a wrong encryption (none instead of psk), sometimes it doesn't detect the Wifi network (while "sudo iwlist wlan0 scan" does). I'm not sure it's linked to this problem but if it is I hope it can help.

[Yves Dorfsman (dorfsmay)]

Something to test...

I had this exact issue on 14.04, when setting up a new wifi network, it would not re-connect automatically after rebooting or suspend. I disabled, saved, then re-enabled the automatic connect setting, and it solved the issue. It's like this setting is disabled by default, but shows as enabled by default, until you force it to be disable to re-sync the actual value and what is shown in the setup tool:

1. go to network setting, select the network and go to "Settings..."
2. in the "General" tab, deselect (uncheck) "Automatically connect to this network"
3. "Save"
4. go back to "Settings..." for this network
5. enable (check) "Automatically connect to this network"
6. save

[Søren Holm (sgh)]

As state in a previous post: You can change whatever setting you'd like. It does not have to be the "auto-connection" setting. You can even change the IP-allocation policy from DHCP to Manual.

[Nick B. (futurepilot)]

I tried that and it didn't work. This machine was upgraded and it only started
after upgrading to 14.10 with no changes made to the network settings. Prior
it was working as expected.

On Wednesday, January 14, 2015 06:24:34 PM Søren Holm wrote:
> As state in a previous post: You can change whatever setting you'd like.
> It does not have to be the "auto-connection" setting. You can even
> change the IP-allocation policy from DHCP to Manual.

[Nico R. (nr-w4k)]

Same problem here on Kubuntu 14.10 on a Dell Latitude E6410 (Intel 5 Series Chipset). Everything worked flawlessly before the upgrade from 14.04 to 14.10.
I also tried the supposed fix from #51, but that didn't help.

[Karmo Rosental (karmux)]

Same bug on Kubuntu 14.10 on HP ProBook 6470b with Broadcom BCM43228 wireless card.

[tobiasBora (tobias-bora)]

@Søren Holm (sgh) : I tried your solution but it work's only for the current session. If you reboot your computer the bug comes back...

[tobiasBora (tobias-bora)]

Could anyone put the priority of this bug to more than medium ? Because it has implication on everyday life... And if you have a bad wifi connection that often disconnect is just horrible to click every ten seconds to reconnect.

[Søren Holm (sgh)]

@tobiasBora: YEs only for the current session. But that something every fix has in common - except for the "Allow all users to access this network"-option.

[Ricardo Fabbri (rfabbri)]

@tobiasBora: +1

[Nathaniel Eliot (temujin9)]

http://ubuntuforums.org/showthread.php?t=2004690 describes what appears to have been the solution to this problem for me: add `SUSPEND_MODULES="iwlwifi"` to `/etc/pm/config.d/config` and reboot.

[RadiantFlux (patrickw)]

@temujin9: this solution worked for me, but I had to input the a different driver other than "iwlwifi".

Using 'sudo lshw -C network' to find driver first.

[Denis Garcia (denis.garci)]

Didn't work for me. My WLAN driver is iwlwifi. I'm still having the bug! I would really like to see it fix before Kubuntu 15.04 is release.

[Bruce Braley (ciclista41)]

#50 worked for me. Thanks, Yves Dorfsman!

[Søren Holm (sgh)]

Please try #51 also

[Richard Henry Lee (rhlee)]

For me, I had to check the "All users may connect to this network box".

[Denis Garcia (denis.garci)]

The "All users may connect to this network box" as explained is #13 worked for me too! Thank you!

[Søren Holm (sgh)]

But #13 is not a solution - it's a workaround.

I changed to Debian becasue of this bug. I've never looked back. The bug has been present for 5 months now.

Btw. is this still occurring in the current 15.04? If it is and it's not fixed for the release this bug has potential to be present until 15.10 which would be really disappointing for most users.

[Denis Garcia (denis.garci)]

I agree I hope that it gets fixed soon. I tried a 15.04 beta and it was not
happening I think. It's really Ubuntu (maybe Debian) specific. It was not
happening in Archlinux for example.

On 12 March 2015 at 22:42, Søren Holm <email address hidden> wrote:

> But #13 is not a solution - it's a workaround.
>
> I changed to Debian becasue of this bug. I've never looked back. The bug
> has been present for 5 months now.
>
> Btw. is this still occurring in the current 15.04? If it is and it's not
> fixed for the release this bug has potential to be present until 15.10
> which would be really disappointing for most users.
>
> --
> You received this bug notification because you are subscribed to the bug
> report.
> https://bugs.launchpad.net/bugs/1354924
>
> Title:
> Networkmanager does not autoconnect to wireless network
>
> To manage notifications about this bug go to:
>
> https://bugs.launchpad.net/ubuntu/+source/network-manager/+bug/1354924/+subscriptions
>

[Nick B. (futurepilot)]

I'm starting to think this is related to hidden SSIDs. I can't seem to reproduce this problem on non-hidden networks.

[michael (r-mail-8)]

Last time I have tested (one week ago), I was able to reproduce with with a non-hidden network as well. I will give it another try and post my feedback here.

[Marco Antonio Macareno Gomez (macareno-marco)]

Same here, using i3 window manager (so it's not KDE for me) and wicd. The disable auto-connect workaround seems to alliviate the problem. Hope this helps to narrow this bug down.

[Tim Plimpton (plimptm)]

I'm also experiencing this issue
14.04 with lightdm, unity-greeter and MATE desktop, ssid broadcast is also disabled
Really hope it gets fixed soon as well.

[Torbjörn Moa (moa-physto)]

The problem seems to have gone away in vivid. I just installed Kubuntu 15.04, and the issue is not there anymore. The WIFI reconnects nicely after sleep/resume without any tricks. I haven't tested very many networks yet, though.

[Nick B. (futurepilot)]

Yep, seems to be working with 15.04

On Monday, April 27, 2015 06:59:35 PM Torbjörn Moa wrote:
> The problem seems to have gone away in vivid. I just installed Kubuntu
> 15.04, and the issue is not there anymore. The WIFI reconnects nicely
> after sleep/resume without any tricks. I haven't tested very many
> networks yet, though.

[Nick B. (futurepilot)]

I take that back. Woke my laptop up today and it didn't automatically connect.

On Monday, April 27, 2015 04:13:13 PM Nick Bryda wrote:
> Yep, seems to be working with 15.04
>
> On Monday, April 27, 2015 06:59:35 PM Torbjörn Moa wrote:
> > The problem seems to have gone away in vivid. I just installed Kubuntu
> > 15.04, and the issue is not there anymore. The WIFI reconnects nicely
> > after sleep/resume without any tricks. I haven't tested very many
> > networks yet, though.

[gonetil (gonetil-gmail)]

Til last week I was using 14.04.2 with KDE, Unity and Gnome 3, I that problem didn't exist.

Not, after installed Kubuntu 15.04 (fresh install) I am having the same problem.
Plasma 5.2.2, Qt 5.4.1, Kernel 3.19.0-16, 64 bits. Broadcom BCM43228 card.

It kinda works restarting networking service, but it's not a solution,
It also works just disabling and enabling the wifi interface from the network applet. Anoying but easier than restarting the service.
Solution #59 didn't work for me .

[Nick B. (futurepilot)]

Nevermind. It does work. That was a problem with kwallet.

On Friday, May 01, 2015 06:07:27 AM Nick B. wrote:
> I take that back. Woke my laptop up today and it didn't automatically
> connect.
>
> On Monday, April 27, 2015 04:13:13 PM Nick Bryda wrote:
> > Yep, seems to be working with 15.04
> >
> > On Monday, April 27, 2015 06:59:35 PM Torbjörn Moa wrote:
> > > The problem seems to have gone away in vivid. I just installed Kubuntu
> > > 15.04, and the issue is not there anymore. The WIFI reconnects nicely
> > > after sleep/resume without any tricks. I haven't tested very many
> > > networks yet, though.

[Ar2el (ar2el)]

Today I managed to solve this problem: I had once deactivated the KDE Wallet subsystem. I enabled it again, restarted the system, and the network manager started connecting automatically again.

However, I want the computer to connect without asking anything (I'm not always near it). But now it asks for my wallet password...

I solved it by entering a blank password, but that's a workaround. I've always disabled the kde wallet subsystem without a problem.

Problem solved, I want to share some thought about this issue.:

I can't help but saying that I seriously can't believe that this bug is still present, with medium priority and assigned to nobody. If this bug was present in windows (and for a year!), everyone of us would be making jokes about it. A whole release came and gone without anybody interested in solving this. It's really unbelievable.

Please don't tell me to upgrade because I use the computer for GPGPU and Plasma 5 breaks when installing nvidia proprietary drivers (so 15.04 isn't an option for me) and 14.04 *LTS* has another open bug that prevents it for being used for GPGPU with nvidia cards. So, I'm just thinking about changing OS.

Not caring about bugs is a serious issue these last years in *Ubuntu.

[Ezequias Rocha (ezequiascr)]

Post #50 doesn't work for me too.
Linux-3.19.0-22-generic-x86_64-with-ubuntu-15.04-vivid
LG electronics 22V240
intel 64

[Krzysztof Burliński (krzysztof-burlinski)]

Happens to me, almost everyday, on two computers. Ubuntu 15.04, unchanged kernel.

One is Thinkpad T430, the other is pc built in from parts. Both run 64 version, on intel cpus.

I have to choose "connect to a hidden network". Unfortunately, when my wife encounters that issue (she has no root access), ubuntu asks her for sudo password. Really disappointing bug.

[neilbags (neilbags)]

This is affecting me on a fresh install of 14.04 Ubuntu-MATE amd64 on boot and on resume.

I'm using the broadcom-sta driver (wl). Kernel version3.16.0-49-generic. The network is not hidden. All updates are applied.

None of the workarounds here are working for me, nor is restarting NetworkManager or killing wpa_supplicant.

[neilbags (neilbags)]

For me this was to do with my VPN connection and I have found a work-around. I edited the file matching the name of my VPN connection in:
/etc/NetworkManager/system-connections/

I changed 'password-flags=1' to 'password-flags=0'

and added a section like this:

[vpn-secrets]
password=XXXXXXXX

where XXXXXXX is my password in cleartext.

[Eduards Bezverhijs (mjasnik)]

I have this problem in 15.10, after wake up from suspend it does not even rescan networks at all, it shows old wifis from last place where I was connected to some wifi.

To overcome this I have to enable/disable wifi or try top connect to any old wifi AP which is in the list and I have entered secrets for, then it rescans the networks, even then it won't connect to known wifi at current place. I have to manually connect to it, then it works.

[Søren Holm (sgh)]

Eduards - that is most likely a different issue. If you look closer you will probably find that your network is not even listed in the networklist. This bugreport is about systems that do not reconnect even when the network is listed.

[Stefan Björk (bluebirch)]

It seems clear that therer are different causes of this problem. Sometimes it is about drivers, sometimes about NetworkManager itself. In my case, if I do a`sudo service network-manager restart`, NetworkManager do no attempt at connecting to any of the available wifi networks. I have to do that manually.

None of the workarounds mentioned above have worked for me.

Ubuntu 14.04.3 LTS.

[jpascher (johann-pascher)]

i don't see that the problem is fixed jet. I am on ubuntu 16.4.02

[Magnus Hoff (maghoff)]

FWIW, I did not experience this as fixed in 16.10, but now that I have updated to 17.04 it works well :)