updating wpa_supplicant causes interruption of wireless network
In the last couple of days, $SUBJ has hit me twice, so I had to wonder if I could somehow prevent it? Hardware is a Nano Pi Neo Air, access is via ssh. first I patched a 15.2 Leap system, and when wpa_supplicant was updated, output over ssh just stops, although the process continues on the ARM board. (verified via a serial console). just now, I was running a zypper dup from 15.1 to 15.2, and the same thing happens. wpa_supplicant is installed, network is interrupted. Over the serial console, I can tell the wlan interface is down, which explains what happens. I don't always have the luxury of having a serial console attached, so updating could leave me with no access to the ARM board. I need to fix a few things after the zypper dup, so I need to retain the network access - any suggestions? -- Per Jessen, Zürich (3.8°C) http://www.dns24.ch/ - your free DNS host, made in Switzerland.
On 14.03.2021 15:58, Per Jessen wrote:
In the last couple of days, $SUBJ has hit me twice, so I had to wonder if I could somehow prevent it?
Hardware is a Nano Pi Neo Air, access is via ssh.
first I patched a 15.2 Leap system, and when wpa_supplicant was updated, output over ssh just stops, although the process continues on the ARM board. (verified via a serial console).
just now, I was running a zypper dup from 15.1 to 15.2, and the same thing happens. wpa_supplicant is installed, network is interrupted.
On update wpa_supplicant runs systemctl try-restart wpa_supplicant.service. Workarounds are - globally disable restart of any service (see /etc/sysconfig/services, DISABLE_RESTART_ON_UPDATE) - set YAST_IS_RUNNING=instsys before running zypper (affects all packages in this zypper run) Irrespectively I would open bug report to discuss whether wpa_supplicant should be exempt from restarting on update. D-Bus is ...
Over the serial console, I can tell the wlan interface is down, which explains what happens.
I don't always have the luxury of having a serial console attached, so updating could leave me with no access to the ARM board. I need to fix a few things after the zypper dup, so I need to retain the network access - any suggestions?
On 2021-03-14 9:43 a.m., Andrei Borzenkov wrote:
On 14.03.2021 15:58, Per Jessen wrote:
In the last couple of days, $SUBJ has hit me twice, so I had to wonder if I could somehow prevent it?
Hardware is a Nano Pi Neo Air, access is via ssh.
first I patched a 15.2 Leap system, and when wpa_supplicant was updated, output over ssh just stops, although the process continues on the ARM board. (verified via a serial console).
just now, I was running a zypper dup from 15.1 to 15.2, and the same thing happens. wpa_supplicant is installed, network is interrupted.
On update wpa_supplicant runs systemctl try-restart wpa_supplicant.service. Workarounds are
- globally disable restart of any service (see /etc/sysconfig/services, DISABLE_RESTART_ON_UPDATE)
Ah, 'cos it isn't easy to remove wpa_supplicant. its not as if networking is about plugins. # zypper rm wpa_supplicant The following 3 packages are going to be REMOVED: NetworkManager NetworkManager-branding-openSUSE wpa_supplicant -- “Reality is so complex, we must move away from dogma, whether it’s conspiracy theories or free-market,” -- James Glattfelder. http://jth.ch/jbg
Andrei Borzenkov wrote:
- set YAST_IS_RUNNING=instsys before running zypper (affects all packages in this zypper run)
Today when I ran a 'zypper patch' I noticed yet another wpa_supplicant update - I decided on trying this: YAST_IS_RUNNING=instsys zypper update wpa_supplicant zypper patch. Brilliant!
Irrespectively I would open bug report to discuss whether wpa_supplicant should be exempt from restarting on update.
boo#1183495 -- Per Jessen, Zürich (6.5°C) http://www.dns24.ch/ - your free DNS host, made in Switzerland.
On Sun, 14 Mar 2021 13:58:09 +0100 Per Jessen <per@computer.org> wrote:
In the last couple of days, $SUBJ has hit me twice, so I had to wonder if I could somehow prevent it?
Hardware is a Nano Pi Neo Air, access is via ssh.
first I patched a 15.2 Leap system, and when wpa_supplicant was updated, output over ssh just stops, although the process continues on the ARM board. (verified via a serial console).
just now, I was running a zypper dup from 15.1 to 15.2, and the same thing happens. wpa_supplicant is installed, network is interrupted.
Which network management system are you using? Maybe it's worth trying a # systemctl daemon-reload # systemctl restart network[ing] but quite how you would automate that if it works is beyond my pay grade. I suppose a frequently run cronjob could run a script that checked for wlan down and restarted it if necessary? But maybe there's a systemd incantation?
Over the serial console, I can tell the wlan interface is down, which explains what happens.
I don't always have the luxury of having a serial console attached, so updating could leave me with no access to the ARM board. I need to fix a few things after the zypper dup, so I need to retain the network access - any suggestions?
Dave Howorth wrote:
On Sun, 14 Mar 2021 13:58:09 +0100 Per Jessen <per@computer.org> wrote:
In the last couple of days, $SUBJ has hit me twice, so I had to wonder if I could somehow prevent it?
Hardware is a Nano Pi Neo Air, access is via ssh.
first I patched a 15.2 Leap system, and when wpa_supplicant was updated, output over ssh just stops, although the process continues on the ARM board. (verified via a serial console).
just now, I was running a zypper dup from 15.1 to 15.2, and the same thing happens. wpa_supplicant is installed, network is interrupted.
Which network management system are you using?
wicked.
Maybe it's worth trying a # systemctl daemon-reload # systemctl restart network[ing]
but quite how you would automate that if it works is beyond my pay grade.
After the 'zypper dup', the network interface cannot be brought up manually (over the serial console), except by unloading/reloading the driver 'brcmfmac'. Even on a running system (after the zypper dup), a "systemctl try-restart wpa_supplicant" causes the wlan0 interface to remain down. Something's not quite right. -- Per Jessen, Zürich (5.0°C) http://www.cloudsuisse.com/ - your owncloud, hosted in Switzerland.
On 14.03.2021 17:39, Per Jessen wrote: ...
wicked.
...
After the 'zypper dup', the network interface cannot be brought up manually (over the serial console), except by unloading/reloading the driver 'brcmfmac'.
Even on a running system (after the zypper dup), a "systemctl try-restart wpa_supplicant" causes the wlan0 interface to remain down. Something's not quite right.
I tested with NetworkManager (not on openSUSE) and it recovers after wpa_supplicant restart.
Andrei Borzenkov wrote:
On 14.03.2021 17:39, Per Jessen wrote: ...
wicked.
...
After the 'zypper dup', the network interface cannot be brought up manually (over the serial console), except by unloading/reloading the driver 'brcmfmac'.
Even on a running system (after the zypper dup), a "systemctl try-restart wpa_supplicant" causes the wlan0 interface to remain down. Something's not quite right.
I tested with NetworkManager (not on openSUSE) and it recovers after wpa_supplicant restart.
Hehe, I did the exact same test :-) but on openSUSE Leap 15.2. Yes, on my laptop with NetworkManager and Intel 3160 wifi, it works fine. -- Per Jessen, Zürich (5.1°C) http://www.dns24.ch/ - free dynamic DNS, made in Switzerland.
On Sun, 14 Mar 2021 15:52:22 +0100 Per Jessen <per@computer.org> wrote:
Andrei Borzenkov wrote:
On 14.03.2021 17:39, Per Jessen wrote: ...
wicked.
...
After the 'zypper dup', the network interface cannot be brought up manually (over the serial console), except by unloading/reloading the driver 'brcmfmac'.
Even on a running system (after the zypper dup), a "systemctl try-restart wpa_supplicant" causes the wlan0 interface to remain down. Something's not quite right.
I tested with NetworkManager (not on openSUSE) and it recovers after wpa_supplicant restart.
Hehe, I did the exact same test :-) but on openSUSE Leap 15.2. Yes, on my laptop with NetworkManager and Intel 3160 wifi, it works fine.
I think I mentioned elsewhere that I'd had grief with wicked on a pi ...
Dave Howorth wrote:
On Sun, 14 Mar 2021 15:52:22 +0100 Per Jessen <per@computer.org> wrote:
Andrei Borzenkov wrote:
On 14.03.2021 17:39, Per Jessen wrote: ...
wicked.
...
After the 'zypper dup', the network interface cannot be brought up manually (over the serial console), except by unloading/reloading the driver 'brcmfmac'.
Even on a running system (after the zypper dup), a "systemctl try-restart wpa_supplicant" causes the wlan0 interface to remain down. Something's not quite right.
I tested with NetworkManager (not on openSUSE) and it recovers after wpa_supplicant restart.
Hehe, I did the exact same test :-) but on openSUSE Leap 15.2. Yes, on my laptop with NetworkManager and Intel 3160 wifi, it works fine.
I think I mentioned elsewhere that I'd had grief with wicked on a pi ...
But you tried it with Raspbian? In general, I have no issues with my Nano Pis running openSUSE Leap (since 15.0) and wicked, and wicked also worked fine on my only running Raspberry. -- Per Jessen, Zürich (4.1°C) http://www.dns24.ch/ - your free DNS host, made in Switzerland.
On 2021-03-14 8:58 a.m., Per Jessen wrote:
just now, I was running a zypper dup from 15.1 to 15.2, and the same thing happens. wpa_supplicant is installed, network is interrupted.
Let's see if I understand this: Under 15.1 it was stable, it worked. Applying CHANGES, disturbed that stability. Let's mention this to Carlos in another thread, eh? -- “Reality is so complex, we must move away from dogma, whether it’s conspiracy theories or free-market,” -- James Glattfelder. http://jth.ch/jbg
Anton Aylward wrote:
On 2021-03-14 8:58 a.m., Per Jessen wrote:
just now, I was running a zypper dup from 15.1 to 15.2, and the same thing happens. wpa_supplicant is installed, network is interrupted.
Let's see if I understand this: Under 15.1 it was stable, it worked. Applying CHANGES, disturbed that stability.
Well, not quite - it continues to work in 15.2, except when wpa_supplicant is restarted.
Let's mention this to Carlos in another thread, eh?
:-) -- Per Jessen, Zürich (4.9°C) http://www.cloudsuisse.com/ - your owncloud, hosted in Switzerland.
participants (4)
-
Andrei Borzenkov -
Anton Aylward -
Dave Howorth -
Per Jessen