RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Bug 1658217 - Captive portal detection does not work
Summary: Captive portal detection does not work
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: Red Hat Enterprise Linux 8
Classification: Red Hat
Component: NetworkManager
Version: 8.0
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: rc
: 8.0
Assignee: Thomas Haller
QA Contact: Desktop QE
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2018-12-11 14:26 UTC by Thomas Haller
Modified: 2019-06-14 00:01 UTC (History)
9 users (show)

Fixed In Version: NetworkManager-1.14.0-9.el8
Doc Type: If docs needed, set a value
Doc Text:
Clone Of: 1619873
Environment:
Last Closed: 2019-06-14 00:01:40 UTC
Type: Bug
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)

Description Thomas Haller 2018-12-11 14:26:13 UTC
+++ This bug was initially created as a clone of Bug #1619873 +++

[[thaller:REDACTED, see original bug for all details]]


Description of problem:
It seems that captive portal detection does not work in Fedora. Whenever I connect to a network with captive portal, the network does not work until I open FF, which luckily detect the captive portal and lets me log in, but this used to be done by NM together with Gnome if I am not mistaken.


Version-Release number of selected component (if applicable):
$ rpm -q NetworkManager
NetworkManager-1.12.2-2.fc29.x86_64

$ rpm -q gnome-shell
gnome-shell-3.29.90-2.fc29.x86_64


Actual results:
The captive portal is not detected/login window is not displayed.


Expected results:
The captive portal is detected/login window is displayed.

--- Additional comment from Thomas Haller on 2018-12-03 09:13:10 UTC ---

in the log, there are two devices: virbr0 and wlp58s0.

Connectivity check on virbr0, always returns LIMITED (as expected)
Connectivity check on wlp58s0 changes from LIMITED -> PORTAL -> FULL (also expected).

The global connectivity state is the combination of the per-device state.

So we see first:
  manager: connectivity checking indicates LIMITED
then:
  manager: connectivity checking indicates FULL


That is, because of https://cgit.freedesktop.org/NetworkManager/NetworkManager/tree/src/nm-manager.c?id=ba6c2211e8f6aebc5e5b07b77ffee938593980a6#n2829

note, how the "best" connectivity state is just the numeric maxiumum.

However, that way, PORTAL is worse than LIMITED: https://cgit.freedesktop.org/NetworkManager/NetworkManager/tree/libnm-core/nm-dbus-interface.h?id=ba6c2211e8f6aebc5e5b07b77ffee938593980a6#n181


Broken since 1.10.0 ( https://cgit.freedesktop.org/NetworkManager/NetworkManager/commit/?id=6b7e9f9b225e81d365fd95901a88a7bc59c1eb39 )

--- Additional comment from Thomas Haller on 2018-12-11 10:39:42 UTC ---

(In reply to Thomas Haller from comment #9)
> fix here: https://github.com/NetworkManager/NetworkManager/pull/255

this got merged to master as https://cgit.freedesktop.org/NetworkManager/NetworkManager/commit/?id=b7429d0a95eda7cada2bde7634ba0a7f31eeb18d



A relevant fix got backported to branches

nm-1-8:  https://cgit.freedesktop.org/NetworkManager/NetworkManager/commit/?id=e91ed81206c3462cac6cda30759909766dfa371b
nm-1-10: https://cgit.freedesktop.org/NetworkManager/NetworkManager/commit/?id=7e0938d5bda212f93e312113673f69b414713b35
nm-1-12: https://cgit.freedesktop.org/NetworkManager/NetworkManager/commit/?id=18103b00d8dd6dd99c9ff17d03cdf568a56d6720
nm-1-14: https://cgit.freedesktop.org/NetworkManager/NetworkManager/commit/?id=d1e98e334dd71b8fafa2512911b737adffddf569

I think, on those branches there is still a subtle issue which is fixed on master [1]. But that requires too many changes for a backporting. So, I presume, the fix on the stable branches are sufficient.

[1] https://cgit.freedesktop.org/NetworkManager/NetworkManager/commit/?id=54ebe32f68ddd4ead8a4a426ff05e05295964610

Comment 1 Thomas Haller 2018-12-11 14:35:28 UTC
while at it, also backport the fix for crash https://cgit.freedesktop.org/NetworkManager/NetworkManager/commit/?id=7f05debf99ab30227180acd7b24a363013c957f2

This patch is merged upsteam for months already (giving confidence that it's good). Also, the crash is indeed nasty.


With this, src/nm-connectivity.[hc] in rhel-8 build is identical to current upstream nm-1-14 branch.

Comment 3 Filip Pokryvka 2018-12-18 13:07:11 UTC
After activation of connection `nmcli general` shows conectivity portal, but gnome does not show any dialog to login (it looks like gnome-shell part). After login in FF, connectivity is full and after logout in firefox, connectivity is changed back to portal. So, NM part works, putting to VERIFIED.


Note You need to log in before you can comment on or make changes to this bug.