Description of problem: I have to always type password for my wifi because of 2 Factor authentication. And this is a reason of option "Ask for this password every time" When I try to connect to such wifi I can see window with title "WiFi Network Authentication Required" But I cannot see any field where I can put my password. Just buttons Cancel, Connect Version-Release number of selected component (if applicable): rpm -qf /usr/bin/nm-applet network-manager-applet-1.8.20-1.fc30.x86_64 How reproducible: Deterministic on my laptop Additional info: I can see following message in log when running nm-appet from command line nm-applet-Message: 18:12:14.963: No keyring secrets found for MY-WIFI/802-1x; asking user.
I can provide screenshot or more info if needed.
My workaound is downgrade to: * network-manager-applet-1.8.18-2.fc30.x86_64 * nm-connection-editor-1.8.18-2.fc30.x86_64 Then I can see text fields for username and password.
This bug be fixed by https://gitlab.gnome.org/GNOME/network-manager-applet/merge_requests/39
Is there an ETA for new version in rawhide?
https://koji.fedoraproject.org/koji/buildinfo?buildID=1216645
(In reply to Beniamino Galvani from comment #5) > https://koji.fedoraproject.org/koji/buildinfo?buildID=1216645 It is still broken for me with that build
> When I try to connect to such wifi I can see window with title "WiFi Network Authentication Required" > But I cannot see any field where I can put my password. Just buttons Cancel, Connect Is it still the same problem or a different one?
(In reply to Beniamino Galvani from comment #7) > > When I try to connect to such wifi I can see window with title "WiFi Network Authentication Required" > > But I cannot see any field where I can put my password. Just buttons Cancel, Connect > > Is it still the same problem or a different one? Yes; the same problem.
I can't reproduce on F30 with network-manager-applet-1.8.20-2.fc30. Can you please double check you are running this version and attach a screenshot of the broken authentication dialog?
Created attachment 1543126 [details] screenshot from up to date rawhide (In reply to Beniamino Galvani from comment #9) > I can't reproduce on F30 with network-manager-applet-1.8.20-2.fc30. > > Can you please double check you are running this version and attach a > screenshot of the broken authentication dialog? BTW I rebooted machine to be sure I used network-manager-applet-1.8.20-2.fc30 Sure
I still use 1.8.18-2 as a workaround. Cause I need this functionality :-) let me now if you need more data (strace/ltrace output ...)
Do you know which authentication protocol is required by the wifi network?
(In reply to Beniamino Galvani from comment #12) > Do you know which authentication protocol is required by the wifi network? Where can I find such info ?
nmcli -o connection show "Red Hat" (I guess it's the corporate Red Hat network, so it should be PEAP+GTC)
(In reply to Beniamino Galvani from comment #14) > nmcli -o connection show "Red Hat" > > (I guess it's the corporate Red Hat network, so it should be PEAP+GTC) nmcli -o connection show "Red Hat" | grep sec 802-11-wireless-security.key-mgmt: wpa-eap 802-11-wireless-security.auth-alg: open 802-11-wireless-security.wep-key-flags: 0 (none) 802-11-wireless-security.psk-flags: 0 (none) 802-11-wireless-security.leap-password-flags:0 (none) and in GUI I can see Security: WPA & WPA2 Enterprise Authentication: Proteceted EAP (PEAP) PEAP version: Automatic Inner authentication: GTC
The issue was that I had older version of libnma. Cause I updated packages from koji and I updated just network-manager-applet, nm-connection-editor. It is quite common that there is requires for the same version of sub-package to prevent such issues. e.g. https://src.fedoraproject.org/rpms/systemd/blob/master/f/systemd.spec#_120 https://docs.fedoraproject.org/en-US/packaging-guidelines/#_requiring_base_package
> The issue was that I had older version of libnma. > Cause I updated packages from koji and I updated just network-manager-applet, nm-connection-editor. That would be a bug. libnma implement linker symbol versioning. Hence, the network-manager-applet RPM should have a dependency on a suitable libnma version. If RPM didn't complain about a missing dependency, it should be fine to not upgrade libnma.
(In reply to Thomas Haller from comment #17) > > The issue was that I had older version of libnma. > > Cause I updated packages from koji and I updated just network-manager-applet, nm-connection-editor. > > That would be a bug. > > libnma implement linker symbol versioning. Hence, the network-manager-applet > RPM should have a dependency on a suitable libnma version. If RPM didn't > complain about a missing dependency, it should be fine to not upgrade libnma. symbol versioning in libraries can help with solving backward compatible changes. e.g. sb added new symbol/function into libnma and network-manager-applet requires that new function. But it cannot help with such one-line bugfixes which does not change API/ABI This bug be fixed by https://gitlab.gnome.org/GNOME/network-manager-applet/merge_requests/39 So it can easily happen that there are installed packages network-manager-applet-1.8.20-2.fc30.x86_64 nm-connection-editor-1.8.20-2.fc30.x86_64 libnma-1.8.20-1.fc30.x86_64 ^^^ sh$ rpm -q --provides libnma libnma = 1.8.20-1.fc30 libnma(x86-64) = 1.8.20-1.fc30 libnma.so.0()(64bit) libnma.so.0(libnma_1_2_0)(64bit) libnma.so.0(libnma_1_8_0)(64bit) libnma.so.0(libnma_1_8_12)(64bit) libnma.so.0(libnma_1_8_20)(64bit) sh$ rpm -q --whatrequires 'libnma.so.0(libnma_1_8_20)(64bit)' network-manager-applet-1.8.20-2.fc30.x86_64
> It is quite common that there is requires for the same version of sub-package to prevent such issues. Your problem was that libnma had a bug, and you upgraded only the GUI (the library user, not the library). Hence, the issue was still present. If you instead had used - gnome-control-center with a buggy libnma version - nm-applet with a buggy libmm-glib then the GUIs (library users) don't express explicit dependencies to a non-buggy library version either. Doing so would be cumbersome as you would have to rebuild gnome-control-center as a new libnma version gets released. Generally RPM package dependencies don't protect you against buggy library versions. You need to update the libraries to the latest version. The GUIs nm-applet/nm-connection-editor use libnma like any other regular library, relying on the stable API/ABI that libnma provides. Indeed, it happens to be that nm-applet/nm-connection-editor and libnma are built from the same source RPM, so it would be not cumbersome to add an explicit dependency for the latest libnma version. Maybe it's preferable to add this dependency as you say. But I could also imagine cases where you want to run nm-applet against an older libnma version. What if libnma-1.8.20-2.fc30.x86_64 introduced a bug and libnma-1.8.20-1.fc30.x86_64 would work better? You may upgrade to the latest version with `dnf upgrade`. Should we really add an explicit package dependency to nm-applet to enforce that?
(In reply to Thomas Haller from comment #19) > > It is quite common that there is requires for the same version of sub-package to prevent such issues. > > Your problem was that libnma had a bug, and you upgraded only the GUI (the > library user, not the library). Hence, the issue was still present. > If you instead had used > > - gnome-control-center with a buggy libnma version > gnome-control-center is a different src.rpm > - nm-applet with a buggy libmm-glib > libmm-glib is also from different src.rpm If gnome-control-center stops working and gnome-control-center was not in latest dnf update transaction then I would check some of dependencies. and downgrade it back as a workaround. But this BZ is about dependencies between sub-packages built from the same src.rpm > then the GUIs (library users) don't express explicit dependencies to a > non-buggy library version either. Doing so would be cumbersome as you would > have to rebuild gnome-control-center as a new libnma version gets released. > Generally RPM package dependencies don't protect you against buggy library > versions. You need to update the libraries to the latest version. > > The GUIs nm-applet/nm-connection-editor use libnma like any other regular > library, relying on the stable API/ABI that libnma provides. Indeed, it > happens to be that nm-applet/nm-connection-editor and libnma are built from > the same source RPM, so it would be not cumbersome to add an explicit > dependency for the latest libnma version. > I already mention it is a best practice in fedora packaging. Especially if sub-packages are not independent. https://src.fedoraproject.org/rpms/systemd/blob/master/f/systemd.spec#_120 https://docs.fedoraproject.org/en-US/packaging-guidelines/#_requiring_base_package > Maybe it's preferable to add this dependency as you say. But I could also > imagine cases where you want to run nm-applet against an older libnma > version. What if libnma-1.8.20-2.fc30.x86_64 introduced a bug and > libnma-1.8.20-1.fc30.x86_64 would work better? You may upgrade to the latest > version with `dnf upgrade`. Should we really add an explicit package > dependency to nm-applet to enforce that? libnma, network-manager-applet and nm-connection-editor are build from single src.rpm If libnma-1.8.20-2.fc30.x86_64 introduced a bug in rawhide I downgrade all packages from broken koji build. Because I do not know which sub-package is buggy. For me whole build is broken. (I did not do that in comment 6 because I overlooked it due to different names) And if there are strict requirements between sub-packages then dnf will not allow to downgrade just single package.
(In reply to Beniamino Galvani from comment #3) > This bug be fixed by > https://gitlab.gnome.org/GNOME/network-manager-applet/merge_requests/39 Could you backport patches also to rawhide ? ATM, there is just build for f30 sh# dnf repoquery network-manager-applet Last metadata expiration check: 0:15:52 ago on Wed 15 May 2019 02:13:05 PM CEST. network-manager-applet-0:1.8.20-1.fc30.x86_64 sh# cat /etc/os-release NAME=Fedora VERSION="31 (Rawhide)" ID=fedora VERSION_ID=31 VERSION_CODENAME="" PLATFORM_ID="platform:f31" PRETTY_NAME="Fedora 31 (Rawhide)" ANSI_COLOR="0;34" LOGO=fedora-logo-icon CPE_NAME="cpe:/o:fedoraproject:fedora:31" HOME_URL="https://fedoraproject.org/" DOCUMENTATION_URL="https://docs.fedoraproject.org/en-US/fedora/rawhide/system-administrators-guide/" SUPPORT_URL="https://fedoraproject.org/wiki/Communicating_and_getting_help" BUG_REPORT_URL="https://bugzilla.redhat.com/" REDHAT_BUGZILLA_PRODUCT="Fedora" REDHAT_BUGZILLA_PRODUCT_VERSION=rawhide REDHAT_SUPPORT_PRODUCT="Fedora" REDHAT_SUPPORT_PRODUCT_VERSION=rawhide PRIVACY_POLICY_URL="https://fedoraproject.org/wiki/Legal:PrivacyPolicy"
I've done a f31 build: https://koji.fedoraproject.org/koji/taskinfo?taskID=34894324
Created attachment 1580762 [details] [PATCH] Add dependencies to same version of libnma How about this patch to ensure the versions of nm-applet, editor and libnma match?
(In reply to Beniamino Galvani from comment #23) > Created attachment 1580762 [details] > [PATCH] Add dependencies to same version of libnma > > How about this patch to ensure the versions of nm-applet, editor and libnma > match? lgtm
https://src.fedoraproject.org/rpms/network-manager-applet/c/b8ad58f6901e7ae59ed537d4b4582c083ebafbb5?branch=master