[Desktop-packages] [Bug 1849346]
I'll second that too. -- You received this bug notification because you are a member of Desktop Packages, which is subscribed to chromium-browser in Ubuntu. https://bugs.launchpad.net/bugs/1849346 Title: [snap] kerberos GSSAPI no longer works after deb->snap transition Status in Mozilla Firefox: New Status in chromium-browser package in Ubuntu: Triaged Status in firefox package in Ubuntu: Triaged Bug description: I configure AuthServerWhitelist as documented: https://www.chromium.org/developers/design-documents/http- authentication and can see my whitelisted domains in chrome://policy/ but websites that used to work with SPNEGO/GSSAPI/kerberos no longer work. I'm guessing the snap needs some sort of permission to use the kerberos ticket cache (or the plumbing to do so doesn't exist...). I can confirm that Chrome has the desired behavior. To manage notifications about this bug go to: https://bugs.launchpad.net/firefox/+bug/1849346/+subscriptions -- Mailing list: https://launchpad.net/~desktop-packages Post to : desktop-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~desktop-packages More help : https://help.launchpad.net/ListHelp
[Desktop-packages] [Bug 1968391] Re: Unreliable wifi with loads of CTRL-EVENT-BEACON-LOSS
Similar behavior, wifi keeps disconnecting and malfunction my hardware : laptop Asus N751JK Network controller: Qualcomm Atheros AR9462 Wireless Network Adapter (rev 01) Subsystem: AzureWave AR9462 Wireless Network Adapter I was runing Ubuntu 20.10, 21.04 up to Ubuntu 21.10 with Kernel 5.13.0 without any problem. I migrated to Ubuntu 22.04 which installs Kernel 5.15 then the problems started. I upgraded to Kernel 5.17.4 no improvement I disabled the power save at /etc/NetworkManager/conf.d/default-wifi-powersave-on.conf by passing from 3 to 2 NM_SETTING_WIRELESS_POWERSAVE_DISABLE (2): disable powersave NM_SETTING_WIRELESS_POWERSAVE_ENABLE (3): enable powersave without any improvement nor with Kernel 5.15 nor 5.17.4 Also the "intel_iommu=off" mentioned at https://groups.google.com/g/linux.debian.kernel/c/RFpPIp0cncA/m/v9ELDxLICgAJ Bug#994590 didn't help. I downgraded the kernel to 5.13.19-051319-generic and the problem has disappeared. There is no problem in my airpoint (router) nor my internet access, I have other computers working correctly. In addition the N751JK works correctly when using the Ethernet adapter for the physical cable. -- You received this bug notification because you are a member of Desktop Packages, which is subscribed to wpa in Ubuntu. https://bugs.launchpad.net/bugs/1968391 Title: Unreliable wifi with loads of CTRL-EVENT-BEACON-LOSS Status in wpa package in Ubuntu: Confirmed Bug description: Using the current beta of Jammy, I no longer have stable WiFi after April 5, 2022 update of wpasupplicant from 2:2.10-2 to 2:2.10-6. There is a chance it may also be related to network-manager going from 1.36.4-1ubuntu1 to 1.36.4-2ubuntu1, but the logs seems to point to wpasupplicant (see below) Wifi is stable often, but also often it fails to load webpages intermittently or fails to download the packages using apt for example, so it's not browser related. Example output of journalctl -xe -u wpasupplicant: Apr 08 19:26:28 weasel wpa_supplicant[772]: wlp13s0: CTRL-EVENT-CONNECTED - Connection to fc:34:97:23:4c:3c completed [id=0 id_str=] Apr 08 19:26:28 weasel wpa_supplicant[772]: wlp13s0: CTRL-EVENT-SIGNAL-CHANGE above=0 signal=-72 noise=-95 txrate=7200 Apr 08 19:26:32 weasel wpa_supplicant[772]: wlp13s0: CTRL-EVENT-BEACON-LOSS Apr 08 19:26:33 weasel wpa_supplicant[772]: wlp13s0: CTRL-EVENT-BEACON-LOSS Apr 08 19:26:34 weasel wpa_supplicant[772]: wlp13s0: CTRL-EVENT-BEACON-LOSS Apr 08 19:26:35 weasel wpa_supplicant[772]: wlp13s0: CTRL-EVENT-BEACON-LOSS Apr 08 19:26:36 weasel wpa_supplicant[772]: wlp13s0: CTRL-EVENT-BEACON-LOSS Apr 08 19:26:37 weasel wpa_supplicant[772]: wlp13s0: CTRL-EVENT-BEACON-LOSS Apr 08 19:26:38 weasel wpa_supplicant[772]: wlp13s0: CTRL-EVENT-BEACON-LOSS Apr 08 19:26:39 weasel wpa_supplicant[772]: wlp13s0: CTRL-EVENT-BEACON-LOSS Apr 08 19:26:39 weasel wpa_supplicant[772]: wlp13s0: CTRL-EVENT-DISCONNECTED bssid=fc:34:97:23:4c:3c reason=4 locally_generated=1 Apr 08 19:26:39 weasel wpa_supplicant[772]: wlp13s0: CTRL-EVENT-REGDOM-CHANGE init=CORE type=WORLD Apr 08 19:26:40 weasel wpa_supplicant[772]: wlp13s0: CTRL-EVENT-REGDOM-CHANGE init=BEACON_HINT type=UNKNOWN Apr 08 19:26:40 weasel wpa_supplicant[772]: wlp13s0: CTRL-EVENT-REGDOM-CHANGE init=BEACON_HINT type=UNKNOWN Apr 08 19:26:42 weasel wpa_supplicant[772]: wlp13s0: CTRL-EVENT-REGDOM-CHANGE init=BEACON_HINT type=UNKNOWN Apr 08 19:26:43 weasel wpa_supplicant[772]: wlp13s0: CTRL-EVENT-REGDOM-CHANGE init=BEACON_HINT type=UNKNOWN Apr 08 19:26:43 weasel wpa_supplicant[772]: wlp13s0: SME: Trying to authenticate with fc:34:97:23:4c:3c (SSID='CamplingVanDerKolk5G' freq=5260 MHz) Apr 08 19:26:43 weasel wpa_supplicant[772]: wlp13s0: Trying to associate with fc:34:97:23:4c:3c (SSID='CamplingVanDerKolk5G' freq=5260 MHz) Apr 08 19:26:43 weasel wpa_supplicant[772]: wlp13s0: Associated with fc:34:97:23:4c:3c Apr 08 19:26:43 weasel wpa_supplicant[772]: wlp13s0: CTRL-EVENT-SUBNET-STATUS-UPDATE status=0 Apr 08 19:26:43 weasel wpa_supplicant[772]: wlp13s0: CTRL-EVENT-REGDOM-CHANGE init=COUNTRY_IE type=COUNTRY alpha2=CA Apr 08 19:26:43 weasel wpa_supplicant[772]: wlp13s0: WPA: Key negotiation completed with fc:34:97:23:4c:3c [PTK=CCMP GTK=CCMP] Apr 08 19:26:43 weasel wpa_supplicant[772]: wlp13s0: CTRL-EVENT-CONNECTED - Connection to fc:34:97:23:4c:3c completed [id=0 id_str=] Apr 08 19:26:43 weasel wpa_supplicant[772]: wlp13s0: CTRL-EVENT-SIGNAL-CHANGE above=0 signal=-72 noise=-95 txrate=7200 Apr 08 19:29:23 weasel wpa_supplicant[772]: wlp13s0: CTRL-EVENT-SIGNAL-CHANGE above=1 signal=-66 noise=-94 txrate=27 Apr 08 19:49:04 weasel wpa_supplicant[772]: wlp13s0: CTRL-EVENT-SIGNAL-CHANGE above=0 signal=-73 noise=-95 txrate=27 Apr 08 19:59:04 weasel wpa_supplicant[772]: wlp13s0: WPA: Group rekeying completed with fc:34:97:23:4c:3c [GTK=CCMP] Apr 08 20:00:23 weasel wpa_supplicant[772]: wlp13s0: CTRL-EVENT-SIGNAL-CHANGE above=1 signal
[Desktop-packages] [Bug 1849346] Re: [snap] kerberos GSSAPI no longer works after deb->snap transition
@frigo Thanks for the tip. Unfortunately my systems requires pam_krb5 which has precedence over default_ccache_name and sets KRB5CCNAME directly. I tried to set ccache_dir in the pam section of krb5.conf but I didn't manage. While waiting for this to be fixed I'll continue with the not-snap version of firefox ... -- You received this bug notification because you are a member of Desktop Packages, which is subscribed to chromium-browser in Ubuntu. https://bugs.launchpad.net/bugs/1849346 Title: [snap] kerberos GSSAPI no longer works after deb->snap transition Status in Mozilla Firefox: New Status in chromium-browser package in Ubuntu: Triaged Status in firefox package in Ubuntu: Triaged Bug description: I configure AuthServerWhitelist as documented: https://www.chromium.org/developers/design-documents/http- authentication and can see my whitelisted domains in chrome://policy/ but websites that used to work with SPNEGO/GSSAPI/kerberos no longer work. I'm guessing the snap needs some sort of permission to use the kerberos ticket cache (or the plumbing to do so doesn't exist...). I can confirm that Chrome has the desired behavior. To manage notifications about this bug go to: https://bugs.launchpad.net/firefox/+bug/1849346/+subscriptions -- Mailing list: https://launchpad.net/~desktop-packages Post to : desktop-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~desktop-packages More help : https://help.launchpad.net/ListHelp
[Desktop-packages] [Bug 1849346]
In my brand new Ubuntu 21.10 Impish has forced the change of Firefox as Snap, so I'm suffering Kerberos not working from inside the Firefox snap. Kerberos works fine at Linux level.KInit, KList, etc... shows that the tickets are assigned and handle correctly when requested. Which is different in our case that for normal people is that the use of Kerberos requires to set in firefox the preference "network.negotiate-auth.trusted-uris" which by default is not set. In my case it is set as network.negotiate-auth.trusted-uris=cern.ch I have everything setup correctly, linux and firefox snap, and the problem present so if somebody could guide me a bit I can output any log file/debug you wish to spot where the magic disappears. -- You received this bug notification because you are a member of Desktop Packages, which is subscribed to chromium-browser in Ubuntu. https://bugs.launchpad.net/bugs/1849346 Title: [snap] kerberos GSSAPI no longer works after deb->snap transition Status in Mozilla Firefox: New Status in chromium-browser package in Ubuntu: Confirmed Status in firefox package in Ubuntu: Confirmed Bug description: I configure AuthServerWhitelist as documented: https://www.chromium.org/developers/design-documents/http- authentication and can see my whitelisted domains in chrome://policy/ but websites that used to work with SPNEGO/GSSAPI/kerberos no longer work. I'm guessing the snap needs some sort of permission to use the kerberos ticket cache (or the plumbing to do so doesn't exist...). I can confirm that Chrome has the desired behavior. To manage notifications about this bug go to: https://bugs.launchpad.net/firefox/+bug/1849346/+subscriptions -- Mailing list: https://launchpad.net/~desktop-packages Post to : desktop-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~desktop-packages More help : https://help.launchpad.net/ListHelp
[Desktop-packages] [Bug 1849346] Re: [snap] kerberos GSSAPI no longer works after deb->snap transition
There is a similar bug follow up at https://bugzilla.mozilla.org/show_bug.cgi?id=1734791 -- You received this bug notification because you are a member of Desktop Packages, which is subscribed to chromium-browser in Ubuntu. https://bugs.launchpad.net/bugs/1849346 Title: [snap] kerberos GSSAPI no longer works after deb->snap transition Status in chromium-browser package in Ubuntu: Confirmed Status in thunderbird package in Ubuntu: Incomplete Bug description: I configure AuthServerWhitelist as documented: https://www.chromium.org/developers/design-documents/http- authentication and can see my whitelisted domains in chrome://policy/ but websites that used to work with SPNEGO/GSSAPI/kerberos no longer work. I'm guessing the snap needs some sort of permission to use the kerberos ticket cache (or the plumbing to do so doesn't exist...). I can confirm that Chrome has the desired behavior. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/chromium-browser/+bug/1849346/+subscriptions -- Mailing list: https://launchpad.net/~desktop-packages Post to : desktop-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~desktop-packages More help : https://help.launchpad.net/ListHelp
[Desktop-packages] [Bug 1849346] Re: [snap] kerberos GSSAPI no longer works after deb->snap transition
Which is different in our case that for normal people is that the use of Kerberos requires to set in firefox the preference "network.negotiate-auth.trusted-uris" which by default is not set. In my case it is set as network.negotiate-auth.trusted-uris=cern.ch I have everything setup correctly, linux and firefox snap, and the problem present so if somebody could guide me a bit I can output any log file/debug you wish to spot where the magic disappears. -- You received this bug notification because you are a member of Desktop Packages, which is subscribed to chromium-browser in Ubuntu. https://bugs.launchpad.net/bugs/1849346 Title: [snap] kerberos GSSAPI no longer works after deb->snap transition Status in chromium-browser package in Ubuntu: Confirmed Status in thunderbird package in Ubuntu: Incomplete Bug description: I configure AuthServerWhitelist as documented: https://www.chromium.org/developers/design-documents/http- authentication and can see my whitelisted domains in chrome://policy/ but websites that used to work with SPNEGO/GSSAPI/kerberos no longer work. I'm guessing the snap needs some sort of permission to use the kerberos ticket cache (or the plumbing to do so doesn't exist...). I can confirm that Chrome has the desired behavior. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/chromium-browser/+bug/1849346/+subscriptions -- Mailing list: https://launchpad.net/~desktop-packages Post to : desktop-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~desktop-packages More help : https://help.launchpad.net/ListHelp
[Desktop-packages] [Bug 1849346] Re: [snap] kerberos GSSAPI no longer works after deb->snap transition
Today my brand new Ubuntu 21.10 Impish has forced the change of Firefox as Snap, so I'm suffering Kerberos not working from inside the Firefox snap. Kerberos works fine at Linux level.KInit, KList, etc... shows that the tickets are assigned and handle correctly when requested. Some closed door seems to isolate the snap from the real world... -- You received this bug notification because you are a member of Desktop Packages, which is subscribed to chromium-browser in Ubuntu. https://bugs.launchpad.net/bugs/1849346 Title: [snap] kerberos GSSAPI no longer works after deb->snap transition Status in chromium-browser package in Ubuntu: Confirmed Status in thunderbird package in Ubuntu: Incomplete Bug description: I configure AuthServerWhitelist as documented: https://www.chromium.org/developers/design-documents/http- authentication and can see my whitelisted domains in chrome://policy/ but websites that used to work with SPNEGO/GSSAPI/kerberos no longer work. I'm guessing the snap needs some sort of permission to use the kerberos ticket cache (or the plumbing to do so doesn't exist...). I can confirm that Chrome has the desired behavior. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/chromium-browser/+bug/1849346/+subscriptions -- Mailing list: https://launchpad.net/~desktop-packages Post to : desktop-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~desktop-packages More help : https://help.launchpad.net/ListHelp
