WiFi setup lost after reboot or shutdown

Setting up WiFi was originally painless and has worked since I installed Leap around June of last year. Now, for some reason, during a system update no less, the system will not connect to the router (FIOS on the 2.4 GHz band) after a reboot or shutdown. The last update seemed to cause the problem. I can setup WiFi an the morning to use the system during the day but not connect after a reboot.

Network controller: Qualcomm Atheros AR9485 Wireless Network Adapter (rev 01) made by TP Link (IIRC). We have a 100 Mbps FIOS setup from Verizon. Phones and tablet are fine. This PC runs an AMD 8320E CPU on an AMD 760 uATX mainboard. Everything else seems to work. I tried a USB stick temporarily but I’m too far away from the router to use those as this setup uses a larger antenna for extra gain across our apartment.

I looked at the libraries associated with Yast and noticed that Yast-online-update-configuration is showing as deprecated (red) on the list generated by Yast during a lookup. That’s the only odd thing I can find.

Should I have filed a bug report? Has anyone else seen this problem with wireless.

Please show


ip addr
ip route
cat /etc/resolv.conf

Further to the above, I assume that you’re using NetworkManager (and not wicked)? How is your wifi system connection defined? Examine the connection configuration defined in the /etc/NetworkManager/system-connections/ directory and report back. You can obfuscate the connection credentials if you want to share the config here. Is the connection defined as a user connection or system connection? Explanation about that here…

https://doc.opensuse.org/documentation/leap/reference/html/book.opensuse.reference/cha-nm.html#sec-nm-sec-types

The systemd journal can be examined for problems relating to the connection if necessary

sudo journalctl -u NetworkManager

That might help with determining the underlying cause of the connection issue.

As Requested:

bob@Osprey:~> ip addr
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
valid_lft forever preferred_lft forever
inet6 ::1/128 scope host
valid_lft forever preferred_lft forever
2: wlan0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
link/ether 14:cc:20:86:51:ad brd ff:ff:ff:ff:ff:ff
inet 192.168.1.181/24 brd 192.168.1.255 scope global wlan0
valid_lft forever preferred_lft forever
inet6 fe80::16cc:20ff:fe86:51ad/64 scope link
valid_lft forever preferred_lft forever
bob@Osprey:~> ip route
default via 192.168.1.1 dev wlan0 proto dhcp
192.168.1.0/24 dev wlan0 proto kernel scope link src 192.168.1.181
bob@Osprey:~> cat /etc/resolv.conf

/etc/resolv.conf is a symlink to /var/run/netconfig/resolv.conf

autogenerated by netconfig!

Before you change this file manually, consider to define the

static DNS configuration using the following variables in the

/etc/sysconfig/network/config file:

NETCONFIG_DNS_STATIC_SEARCHLIST

NETCONFIG_DNS_STATIC_SERVERS

NETCONFIG_DNS_FORWARDER

or disable DNS configuration updates via netconfig by setting:

NETCONFIG_DNS_POLICY=’’

See also the netconfig(8) manual page and other documentation.

Call “netconfig update -f” to force adjusting of /etc/resolv.conf.

search fios-router.home
nameserver 8.8.8.8
nameserver 8.8.4.4
nameserver 192.168.1.1
bob@Osprey:~>

Well, that confirms that wlan0 (wireless device node) is active, with IP address assigned and DNS servers configured. Is the problem that you’re just not getting connected automatically during boot?

sudo journalctl -u NetworkManager

– Logs begin at Fri 2020-03-20 16:16:55 EDT, end at Fri 2020-03-20 21:37:42 EDT. –
– No entries –

/etc/NetworkManager/system-connections is empty. No files.

What seems the most odd is that I have had this setup working for months before this.

Thanks for looking at this, fellows.

Bob

Yes. It’s like I setup the WiFi in Yast but the system has no record of it. It should return after shutdown or reboot but the connection is forgotten later.

Bob

You’re using wicked (not NetworkManager), so that is why there is no configuration in the /etc/NetworkManager/system-connections/ directory. Instead, the relevant config file is /etc/sysconfig/network/ifcfg-wlan0

I’m not sure why you’re not connecting at boot, but you can examine the log with

sudo journalctl -u wicked

Here is the openSUSE doumentation for both NetworkManager and wicked (configured via YaST)…

https://doc.opensuse.org/documentation/leap/reference/html/book.opensuse.reference/cha-nm.html
https://doc.opensuse.org/documentation/leap/reference/html/book.opensuse.reference/cha-network.html#sec-network-yast

I’m having a similar problem after one of the recent patches. My wlan configuration is not lost, but my wlan no longer starts automatically after a reboot. I can start it manually after login with “wicked ifup wlan0”. I have the following errors logged on boot but haven’t been able to figure out the problem. Not sure what patch broke it, one of the ones that came out in the last week or two.


Mar 21 09:00:18 HP-Linux dbus-daemon[1012]: [system] Failed to activate service 'fi.epitest.hostap.WPASupplicant': timed out (service_start_timeout=25000ms)
Mar 21 09:00:18 HP-Linux wickedd[1230]: ni_wpa_interface_bind(wlan0): Operation not permitted
Mar 21 09:00:18 HP-Linux wickedd[1230]: wpa_supplicant doesn't know interface wlan0
Mar 21 09:00:18 HP-Linux wickedd-nanny[1236]: device wlan0: call to org.opensuse.Network.Wireless.changeDevice() failed: General failure
Mar 21 09:00:18 HP-Linux wickedd-nanny[1236]: wlan0: failed to bring up device, still continuing
Mar 21 09:00:23 HP-Linux wicked[1237]: lo              up
Mar 21 09:00:23 HP-Linux wicked[1237]: wlan0           device-not-running
Mar 21 09:00:23 HP-Linux wicked[1237]: eth0            no-device
Mar 21 09:00:23 HP-Linux wicked[1237]: wlan0-save      no-device
Mar 21 09:00:23 HP-Linux systemd[1]: Started wicked managed network interfaces.
Mar 21 09:00:23 HP-Linux systemd[1]: Reached target Network.
Mar 21 09:00:23 HP-Linux systemd[1]: Starting OpenSSH Daemon...
Mar 21 09:00:23 HP-Linux systemd[1]: Starting WPA Supplicant daemon...
Mar 21 09:00:23 HP-Linux systemd[1]: Started Backup of /etc/sysconfig.

Can you switch to the “old” Version of wpa-supplicant and see, if it works?

S  | Name                         | Typ        | Version         | Arch   | Repository      
---+------------------------------+------------+-----------------+--------+-----------------
i+ | wpa_supplicant               | Paket      | 2.6-lp151.5.3.1 | x86_64 | OSS-Update      
v  | wpa_supplicant               | Paket      | 2.6-lp151.4.4   | x86_64 | OSS             
v  | wpa_supplicant               | Paket      | 2.6-lp151.5.3.1 | i586   | OSS-Update      
   | wpa_supplicant               | Quellpaket | 2.6-lp151.5.3.1 | noarch | OSS-Update      
   | wpa_supplicant-debuginfo     | Paket      | 2.6-lp151.4.4   | x86_64 | Debug-Repository
   | wpa_supplicant-debugsource   | Paket      | 2.6-lp151.4.4   | x86_64 | Debug-Repository
   | wpa_supplicant-gui           | Paket      | 2.6-lp151.5.3.1 | x86_64 | OSS-Update      
   | wpa_supplicant-gui           | Paket      | 2.6-lp151.4.4   | x86_64 | OSS             
   | wpa_supplicant-gui           | Paket      | 2.6-lp151.5.3.1 | i586   | OSS-Update      
   | wpa_supplicant-gui-debuginfo | Paket      | 2.6-lp151.4.4   | x86_64 | Debug-Repository

Or use wpa_supplicant from the network Repo:
https://download.opensuse.org/repositories/hardware/openSUSE_Leap_15.1/x86_64/

Because I see this:
https://bugzilla.opensuse.org/show_bug.cgi?id=1166933

Yes, if i downgrade wpa_supplicant to 2.6-lp151.4.4.x86_64 it works as before. I opened bug 1167319 1167319 – wlan fails to start on boot after wpa_supplicant upgraded to 2.6-lp151.5.3.1-x86_64

I opened bug 1167319 1167319 – wlan fails to start on boot after wpa_supplicant upgraded to 2.6-lp151.5.3.1-x86_64

Why not adding it to the bug I mentioned?

I installed the older version of wpa_supplicant using Yast. Isn’t the version that keeps trying to update my system the broken version or am I missing something? Installing the older version of wpa_supplicant does result in a network connection after a restart. Would copying the version shown above to my system and installing manually fix the problem? It seems like I’d end up unable to connect again.

Bob

Install the version that works. Then lock that version so it won’t update. To lock in Yast, right-click on the installed package, and select “protected - do not modify”.

You will probably get a conflict when running Yast online update, and one of the choices will be to skip that patch.

I probably should have. But that bugs description indicated a wifi setup failure and indicated the interface could only be managed by network manager and that wicked fails. My problem is only that my wlan fails to start on boot and can be managed by wicked with no problem other than needing a manual “wicked ifup wlan0” command at login. It is undoubtedly caused by the same patch, but not having any experience with openSUSE bug reporting I didn’t know how important it is to have an accurate description so I created my own. I figured it could always be closed as a dup if that was appropriate. I’m open to guidance on when to open a new bug or update a similar one.

As explained in the first bug report, on boot wpa_supplicant fails to start when wickedd attempts to setup interface; when you bring up interface manually, wpa_supplicant is already started so everything works.