Switching to Fedora and back to openSUSE renders wireless interface dormant

When booting again openSUSE wlan wouldn’t work:

erlangen:~ # ip link
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN mode DEFAULT group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
2: wlp3s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP mode DORMANT group default qlen 1000
    link/ether <filter> brd ff:ff:ff:ff:ff:ff
3: enp0s31f6: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP mode DEFAULT group default qlen 1000
    link/ether <filter> brd ff:ff:ff:ff:ff:ff
erlangen:~ # 

Only deleting the interface with Yast and adding again would fix the problem. Any idea?

After reading and re-reading I come to the conclusion that you probably mean with “switching”: booting from different installs in a multi-boot situation, and not: installing the one over the other.

I changed the message title.

Does this happen every time, or was this a one time action needed?
If every time, does the same thing happen if you shutdown from Fedora, then boot openSUSE, instead of rebooting?
Could it be the issue is caused by Fedora not shutting down the interface properly?

Installing Fedora was straight forward. However dhcp4 would fail, the configuration being persistently overwritten: Fedora 29 Workstation - Network is Unreachable. While tinkering with fedora switching between the two OSs worked without side effect.

Later I discovered that dhcp4 would not work with wlp3s0 under Fedora. I don’t remember how I got it to work, but in the end I succeeded. Only then wlp3s0 stopped to work under openSUSE.

If every time, does the same thing happen if you shutdown from Fedora, then boot openSUSE, instead of rebooting?
I performed shutdown and complete power off using a mechanical breaker before Christmas. Upon power on in the new year wlp3s0 was rendered DORMANT again. Updating with zypper dup and rebooting wouldn’t change this.

Could it be the issue is caused by Fedora not shutting down the interface properly?
I am clueless regarding shutting down the interface.

The wifi state with ‘mode DORMANT’ is unusual here…

2: wlp3s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP mode DORMANT group default qlen 1000
    link/ether <filter> brd ff:ff:ff:ff:ff:ff/

Anything unusual reported via dmesg?

dmesg| egrep -i 'firmware|wlp3s0'

I assume from your mentioning of YaST that you’re using wicked?

If so, you could try manually changing the mode with

sudo ip link set wlp3s0 mode default

then toggle the interface

sudo ifdown wlp3s0 && sudo ifup wlp3s0

Does that result in a working wifi connection?

Rebooted from openSUSE into Fedora and got state UP mode DORMANT. dhcp6 worked, but dhcp4 failed Running ip link set wlp3s0 mode default established ‘state UP mode default’ ifdown wlp3s0 and ifup wlp3s0 complained:

erlangen:~ # cat /Fedora/root/ifdown.out 
Could not load file '/etc/sysconfig/network-scripts/ifcfg-wlp3s0'
Error: '/etc/sysconfig/network-scripts/ifcfg-wlp3s0' is not an active connection.
Error: no active connection provided.
erlangen:~ # cat /Fedora/root/ifup.out 
Could not load file '/etc/sysconfig/network-scripts/ifcfg-wlp3s0'
Error: unknown connection '/etc/sysconfig/network-scripts/ifcfg-wlp3s0'.
erlangen:~ # 

But finally both dhcp6 and dhcp4 worked under Fedora.

When rebooting from Fedora into openSUSE exactly the same symptoms were observed: state UP mode DORMANT, working dhcp6 and timeout of dhcp4:


    0.150818] Spectre V2 : Enabling Restricted Speculation for firmware calls
    0.538461] ACPI: [Firmware Bug]: BIOS _OSI(Linux) query ignored
    2.256882] [drm] Finished loading DMC firmware i915/skl_dmc_ver1_27.bin (v1.27)
    3.614373] ath9k 0000:03:00.0 wlp3s0: renamed from wlan0
    4.111738] IPv6: ADDRCONF(NETDEV_UP): wlp3s0: link is not ready
    5.045169] wlp3s0: authenticate with ...
    5.067078] wlp3s0: send auth to ... (try 1/3)
    5.069516] wlp3s0: authenticated
    5.070514] wlp3s0: associate with ... (try 1/3)
    5.079062] wlp3s0: RX AssocResp from ... (capab=0x431 status=0 aid=2)
    5.079177] wlp3s0: associated
    5.101278] IPv6: ADDRCONF(NETDEV_CHANGE): wlp3s0: link becomes ready
Jan 05 06:06:07 erlangen systemd[1]: Starting wicked DHCPv4 supplicant service...
Jan 05 06:06:07 erlangen systemd[1]: Started wicked DHCPv4 supplicant service.
Jan 05 06:06:49 erlangen wickedd-dhcp4[4407]: wlp3s0: Request to acquire DHCPv4 lease with UUID df39305c-0763-0700-a603-000016000000
Jan 05 06:06:59 erlangen wickedd-dhcp4[4407]: unable to confirm lease
Jan 05 06:07:04 erlangen wickedd-dhcp4[4407]: wlp3s0: defer timeout 15 reached (state INIT)
Jan 05 06:08:13 erlangen wickedd-dhcp4[4407]: wlp3s0: DHCP4 discovery failed
Jan 05 06:09:18 erlangen wickedd-dhcp4[4407]: wlp3s0: DHCP4 discovery failed
Jan 05 06:10:22 erlangen wickedd-dhcp4[4407]: wlp3s0: DHCP4 discovery failed
Jan 05 06:11:12 erlangen wickedd-dhcp4[4407]: ni_dhcp4_device_close: timer active for wlp3s0
Jan 05 06:11:24 erlangen wickedd-dhcp4[4407]: wlp3s0: Request to acquire DHCPv4 lease with UUID df39305c-0763-0700-a603-00001b000000
Jan 05 06:11:35 erlangen wickedd-dhcp4[4407]: unable to confirm lease
Jan 05 06:11:40 erlangen wickedd-dhcp4[4407]: wlp3s0: defer timeout 15 reached (state INIT)
Jan 05 06:12:49 erlangen wickedd-dhcp4[4407]: wlp3s0: DHCP4 discovery failed
Jan 05 06:13:53 erlangen wickedd-dhcp4[4407]: wlp3s0: DHCP4 discovery failed
Jan 05 06:14:57 erlangen wickedd-dhcp4[4407]: wlp3s0: DHCP4 discovery failed
Jan 05 06:16:01 erlangen wickedd-dhcp4[4407]: wlp3s0: DHCP4 discovery failed
Jan 05 06:16:21 erlangen wickedd-dhcp4[4407]: ni_dhcp4_device_close: timer active for wlp3s0
Jan 05 06:16:23 erlangen wickedd-dhcp4[4407]: wlp3s0: Request to acquire DHCPv4 lease with UUID df39305c-0763-0700-a603-000025000000
Jan 05 06:16:33 erlangen wickedd-dhcp4[4407]: unable to confirm lease
Jan 05 06:16:38 erlangen wickedd-dhcp4[4407]: wlp3s0: defer timeout 15 reached (state INIT)
Jan 05 06:17:24 erlangen wickedd-dhcp4[4407]: ni_dhcp4_device_close: timer active for wlp3s0
Jan 05 06:17:30 erlangen systemd[1]: Stopping wicked DHCPv4 supplicant service...

Running ip link set wlp3s0 mode default established ‘state UP mode default’. ifdown wlp3s0 and ifup wlp3s0 worked without complaint, but did not restore dhcp4. Switching from wicked to NetworkManager and back to wicked finally fixed dhcp4.

Yes, but your wireless interface name may well be different in Fedora? The interface name needs to be applicable to the OS. Or perhaps NetworkManager controlled in Fedora?

Looks like a DHCP problem more than a wifi connectivity problem as such. Did you try rebooting your wireless router yet?

When I installed Fedora the AR9287 did not work. As a last resort I configured openSUSE with NetworkManager and copied the configuration file to Fedora:

erlangen:~ # ll /Fedora/etc/sysconfig/network-scripts/
total 12
-rw-r--r--. 2 root root 434 Dec 19 14:30 ifcfg-FRITZ-Box_Karl_Mistelberger
-rw-r--r--. 2 root root 434 Dec 19 14:30 ifcfg-wlp3s0
-rw-------. 1 root root  29 Dec 19 14:30 keys-FRITZ-Box_Karl_Mistelberger
erlangen:~ # 

Thus I have the same interface name on openSUSE, Fedora and Xubuntu 18.04. There are no side effects when rebooting from openSUSE into Xubuntu and back again. They only occur with Fedora.

Disconnected router from power and connected again. That didn’t change things. Problems with Fedora persisted. Had a closer look at router’s configuration of host erlangen. It used a fixed address 192.168.178.20. That worked well with openSUSE and Xubuntu. However Fedora insisted on using 192.168.178.29.>:)

Many thanks for joining the discussion and considering every possibility.

Are you using DHCP reservation on the router? Have you explicitly specified a MAC address in either of your network configurations (Fedora and openSUSE)?

All devices have the menu item “Always assign this network device the same IPv4 address” checked.

“By default, the FRITZ!Box always assigns the same IP address to each device. For this, the FRITZ!Box permanently stores the device’s MAC address with the first IP address assigned to it”: https://en.avm.de/service/fritzbox/fritzbox-7360/knowledge-base/publication/show/201_Configuring-FRITZ-Box-to-always-assign-the-same-IP-address-to-a-network-device/

On the router the entry for the desktop machine had hostname=erlangen and IPv4 address=192.168.178.20. OS Hostnames were openSUSE: erlangen, Xubuntu: xubuntu-test and Fedora: linux. Xubuntu (as all other systems installed previously) didn’t mind and went ahead. Fedora refused to use 192.168.178.20 and tried 192.168.178.29, while the router still used 192.168.178.20. The issue went away when I ran “hostnamectl set-hostname erlangen” on Fedora. Now I have hostname=erlangen and IPv4 address=192.168.178.29. DHCP now works for all 3 OSs installed without any issues.

Ok, so all working as expected now by what I’m reading here?

Networking with the FRITZ!Box 7360 as a dhcp server was rock solid for some four years. Installed dozens of distributions on different hardware with default settings working out of the box. Fedora on the i7-6700K however was different due to a configuration problem: FRITZ!Box assigned 192.168.178.20 and hostname erlangen in 2014.

Distro, hostname, IP, result

  • opensuse, linux-xxxx, 192.168.178.20, success
  • Xubuntu, xubuntu-test, 192.168.178.20, success
  • Fedora, linux, 192.168.178.29, fail
  • Fedora, erlangen, 192.168.178.29, success

Fedora didn’t work with the default hostname ‘linux’ assigned during installation. Changing to ‘erlangen’ fixed the problem.

Booting Fedora. dhcp4 has again time out. Insists now using 192.168.178.20. Unchecked “Always assign this network device the same IPv4 address” at the Fritz!Box router and immediately got dhcp4 working.>:)

Yes, when using DHCP it’s all down to the (configured) router behaviour itself. :wink:

Problem are gone since using a static hostname in each installed system (needs not be the same) which is never changed through DHCP.:wink:

Yep :wink: