Hi Packetfence, We have been struggling with some newer model mobile devices with our WiFi captive portal implementation using Packetfence, and have not seen any change in the behavior on 11.0 thru 12.1 with our current connection profile.
We do not use an inline configuration, and now we are upgraded to 12.1 on Debian 11, though we have not seen any related changelogs for specific device enumeration related to our issue, so we believe there is some new capabilities in how these platforms handle WiFi Login that we are missing configuration for. A bit more about our environment. Our switch groups are OpenWRT/hostapd based with CoA configured for Registration/Isolation/Management VLANs connected to our server, and a Default local VLAN for Internet access that varies depending on the switch location. Based on MAC, devices connect, and receive Internet access for a short period of time, before completing email-based activation to grant them a longer access window. All devices detect the WiFi login request on the registration network and prompt users for an email to complete authentication. When the email is sent, PF completes radius accounting, sets the device MAC as registered and issues a CoA to boot the device after a brief delay to account for hostapd delay in processing radius changes. It is at this point where the process fails for some devices. Samsung Galaxy S9 / S10 devices (Android 12) move through this step and are handed the default redirection page per their connection profile. Newer S22 and iPhone 14 devices are shown a Packetfence error occurred page, which shows the IP address of the gateway for the Default VLAN and MAC:0. So they made it to the Normal/Default VLAN and in packetfence they are registered. It seems that right after the CoA disconnect, when the device reconnects to the WiFi on the correct VLAN, it detects a sign-in requirement (Or simply retries the login page) and heads to the portal on the server which feeds it an error message. But is on the Default VLAN, so a smart user can cancel the Login and choose to "stay connected without Internet" and they are fine. Clearly the Internet detection is failing for the device, or it believes this due to cancelling a login process. Just reading this makes me think perhaps we are missing a setting defined for newer devices, as the config is pretty simple (from the command line anyway). I think it is time to try a default connection profile configured from scratch and see if it adds something we are missing. If anyone has experience with this issue, feel free to post back so we can shortcut our triage, and finally move on to upgrading our production systems from 11.0 and fixing these newer mobile devices. cheers, Ian Our profile in testing: [Lab] description=Captive Portal filter=ssid:PFTest_WiFi locale= redirecturl=https://someplace.com/ logo=/common/logo.png sources=email preregistration=disabled Our switch config has one setting I am not sure about, but otherwise has our VLANs, radius creds in it. always_trigger=1 Of pf.conf [Captive Portal] includes: wispr_redirection=enabled network_detection_ip=<The IP of a reachable Web Server> network_redirect_delay=25s
_______________________________________________ PacketFence-users mailing list PacketFence-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/packetfence-users
