Hide Forgot
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 How reproducible: Steps to Reproduce: 1. 2. 3. 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 info:
Does 'nmcli general' show that you are under a captive portal in the CONNECTIVITY column?
Seeing this problem as well. nmcli shows "limited" in the CONNECTIVITY colum after connecting, but the gnome shell does not pop up the login window as it used to in the past. Updated quite early to F29 (a week or two before the beta came out). Is there maybe a package missing or something that handles the captive portal stuff in Gnome?
I would expect CONNECTIVITY "portal". Can you enable level=TRACE logging (see [1] for hints) and either provide the logfile, or see if there is anything helpful there? Thanks. [1] https://cgit.freedesktop.org/NetworkManager/NetworkManager/tree/contrib/fedora/rpm/NetworkManager.conf#n28
Created attachment 1510364 [details] nm trace after switching on wlan and trying to a WLAN with captive portal "anything helpful there" -> saw this: """ connectivity: (wlp58s0) check completed: PORTAL; unexpected response """ Out of curiosity I curled http://fedoraproject.org/static/hotspot.txt and got this: """ <HTML><BODY><H2>Browser error!</H2>Browser does not support redirects!</BODY> <!-- <?xml version="1.0" encoding="UTF-8"?> <WISPAccessGatewayParam xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:noNamespaceSchemaLocation="http://www.wballiance.net/wispr_2_0.xsd"> <Redirect> <MessageType>100</MessageType> <ResponseCode>0</ResponseCode> <VersionHigh>2.0</VersionHigh> <VersionLow>1.0</VersionLow> <AccessProcedure>1.0</AccessProcedure> <AccessLocation>CDATA[[isocc=,cc=,ac=,network=HOTSPLOTS,]]</AccessLocation> <LocationName>CDATA[[colibri-00c03ac98c02]]</LocationName> <LoginURL>https://www.hotsplots.de/auth/login.php?res=wispr&uamip=192.168.44.1&uamport=80&challenge=f00e4c16a21901a4a15e9580fa68a952</LoginURL> <AbortLoginURL>http://192.168.44.1:80/abort</AbortLoginURL> <EAPMsg>AQEABQE=</EAPMsg> </Redirect> </WISPAccessGatewayParam> --> </HTML> """
> Out of curiosity I curled http://fedoraproject.org/static/hotspot.txt and got this: that looks OK. The captive portal intercepts the request and returns some other page. In the logfile, most of the time, there is connectivity: (wlp58s0) check completed: PORTAL; unexpected response as expected. Only once, there is for a short time connectivity: (virbr0) check completed: LIMITED; timeout unclear why. But that shouldn't be too harmful as it's only a glitch. I wouldn't expect that `nmcli general` shows "limited" as connectivity state... The system-wide connectivity state is determined by looking at all interfaces. In the logfile, there are only connectivity checks for wlp58s0. Is there another device that has a different connectivity state?
Created attachment 1510485 [details] Another debug run, from start to stop of NM again trace output from NM -- this time from start to stopping. Close to the end I authenticated to the captive portal over different means.
(In reply to Thomas Haller from comment #5) > I wouldn't expect that `nmcli general` shows "limited" as connectivity > state... I rechecked, it does: STATE CONNECTIVITY WIFI-HW WIFI WWAN-HW WWAN connected (site only) limited enabled enabled enabled enabled > The system-wide connectivity state is determined by looking at all > interfaces. In the logfile, there are only connectivity checks for wlp58s0. > Is there another device that has a different connectivity state? """ 1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000 link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 inet 127.0.0.1/8 scope host lo valid_lft forever preferred_lft forever inet6 ::1/128 scope host valid_lft forever preferred_lft forever 2: wlp58s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000 link/ether 9a:57:3c:d7:fe:64 brd ff:ff:ff:ff:ff:ff inet 192.168.46.188/22 brd 192.168.47.255 scope global dynamic noprefixroute wlp58s0 valid_lft 462sec preferred_lft 462sec inet6 fe80::63c5:63ca:cca0:b447/64 scope link noprefixroute valid_lft forever preferred_lft forever 3: virbr0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue state DOWN group default qlen 1000 link/ether 52:54:00:02:db:d0 brd ff:ff:ff:ff:ff:ff inet 192.168.122.1/24 brd 192.168.122.255 scope global virbr0 valid_lft forever preferred_lft forever 4: virbr0-nic: <BROADCAST,MULTICAST> mtu 1500 qdisc fq_codel master virbr0 state DOWN group default qlen 1000 link/ether 52:54:00:02:db:d0 brd ff:ff:ff:ff:ff:ff """ FWIW: Sorry, can't remember if virt-manager or boxes configured those virbr devices.
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 )
fix here: https://github.com/NetworkManager/NetworkManager/pull/255
Thanks for tracking this down. BTW, the update of Rawhide removed NetworkManager-config-connectivity-fedora from my system since this dependency was dropped from fedora-release [1]. Is the config file required for the captive portal detection or not? [1] https://src.fedoraproject.org/rpms/fedora-release/c/242d999c07eab498c7c79fd4c0dbc8ede4b9832e?branch=master
(In reply to Vít Ondruch from comment #10) > BTW, the update of Rawhide removed NetworkManager-config-connectivity-fedora > from my system since this dependency was dropped from fedora-release [1]. Is > the config file required for the captive portal detection or not? Ah, I wasn't aware of that. Thank you. yes, it is required, because it provides a configuration snippet /usr/lib/NetworkManager/conf.d/20-connectivity-fedora.conf to enable the connectivity check. I am not familiar with the change to "fedora-release". Do you know, the right place to fix this?
(In reply to Thomas Haller from comment #11) > I am not familiar with the change to "fedora-release". Do you know, the > right place to fix this? Well, ticket against fedora-release or PR reverting this could open the discussion why this happened, because it is not explained in the commit message nor changelog.
(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. Bringing this fix to Fedora 28, Fedora 29, and rawhide is still TODO. [1] https://cgit.freedesktop.org/NetworkManager/NetworkManager/commit/?id=54ebe32f68ddd4ead8a4a426ff05e05295964610
NetworkManager-1.12.6-3.fc29 has been submitted as an update to Fedora 29. https://bodhi.fedoraproject.org/updates/FEDORA-2018-3edec78f47
NetworkManager-1.10.12-3.fc28 has been submitted as an update to Fedora 28. https://bodhi.fedoraproject.org/updates/FEDORA-2018-03adc6f45c
NetworkManager-1.10.12-3.fc28 has been pushed to the Fedora 28 testing repository. If problems still persist, please make note of it in this bug report. See https://fedoraproject.org/wiki/QA:Updates_Testing for instructions on how to install test updates. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2018-03adc6f45c
NetworkManager-1.12.6-3.fc29 has been pushed to the Fedora 29 testing repository. If problems still persist, please make note of it in this bug report. See https://fedoraproject.org/wiki/QA:Updates_Testing for instructions on how to install test updates. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2018-3edec78f47
NetworkManager-1.12.6-3.fc29 has been pushed to the Fedora 29 stable repository. If problems still persist, please make note of it in this bug report.
NetworkManager-1.10.12-3.fc28 has been pushed to the Fedora 28 stable repository. If problems still persist, please make note of it in this bug report.