im Guessing it might be related to the rfc7710bis / rfc8910 portal support
this means that via dhcp, the client is provided with an URL they can use to check the status of the device in the portal (whether they are still jailed or no) normally this information is served on the same interface as the portal if im not mistaken. you might want to check the logs for pf.log or the haproxy-portal log for urls matching "/rfc7710" if so.. it might be that the clients are too fast re-accessing that url and determining they are still locked in my case, forcing a disconnect via the COA will cause the client to re-issue a dhcp request.. and thus, a new portal request? On Wed, Jan 11, 2023 at 2:36 PM Ian MacDonald via PacketFence-users < packetfence-users@lists.sourceforge.net> wrote: > Daniel, > > The random MAC would seem like an obvious culprit, but it is not. > > On an iPhone, if you click on the little "i" for information next to each > connection, you see that the OS uses the same [random] mac per SSID, so it > will never change for a given WiFi network after is has connected. It will > be different for each SSID/network. > > Since it does not change per SSID, the MAC can be used for auth, but > obviously the OUI will no longer indicate it is an Apple device. > > cheers, > Ian > > > On Wed, Jan 11, 2023 at 11:48 AM Daniel Silva <dan...@unifor.br> wrote: > >> Good afternoon, >> >> We are having the same problem, in the new version people have captured >> random macs, and they redirect to a page with information on how to disable >> random macs. Would that really be the best way to solve it? I don't know, I >> just know that it generates complaints, tickets in our environment. If you >> have any idea of how to work around this situation, please send it to me at >> dan...@unifor.br, thank you in advance. >> >> >> >> >> *Daniel Ricardo* >> >> Analista de Infraestrutura >> NATI - Núcleo de Aplicação em Tecnologia da Informação >> >> Universidade de Fortaleza >> >> Tel.: (85) 3477.3302 >> >> >> >> Em qua., 11 de jan. de 2023 às 10:52, Ian MacDonald via PacketFence-users >> <packetfence-users@lists.sourceforge.net> escreveu: >> >>> 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 >>> >> >> Unifor.br <https://unifor.br/> | Instagram >> <https://www.instagram.com/uniforcomunica/?hl=pt-br> | Facebook >> <https://www.facebook.com/uniforoficial/> | Twitter >> <https://twitter.com/UniforOficial> | LinkedIn >> <https://www.linkedin.com/school/university-of-fortaleza/?originalSubdomain=pt> >> | TV Unifor <https://www.unifor.br/tv-unifor> | G1/Ensinando e >> Aprendendo >> <https://g1.globo.com/ce/ceara/especial-publicitario/unifor/ensinando-e-aprendendo/> >> ------------------------------ >> >> >> <https://g1.globo.com/ce/ceara/especial-publicitario/unifor/ensinando-e-aprendendo/> >> > _______________________________________________ > PacketFence-users mailing list > PacketFence-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/packetfence-users >
_______________________________________________ PacketFence-users mailing list PacketFence-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/packetfence-users
