[GH-ISSUE #13] MAC authentication still performing captive portal popup #9

New issue

Closed

opened 2026-03-04 14:52:19 +03:00 by kerem · 3 comments

kerem commented

2026-03-04 14:52:19 +03:00

Owner

Originally created by @PWJW on GitHub (Apr 23, 2024).
Original GitHub issue: https://github.com/f00b4r0/uspot/issues/13

We are testing the MAC authentication option within uspot and although it's working and the user is successfully authenticated from our RADIUS server, they still receive the captive portal popup window (which then briefly disappears on Android or the window changes to "Done" on iOS). They are fully online and can browse by dismissing the portal popup and show "Authenticated" when querying via the captive clients CLI script.

I've followed the instructions to have dnsmasq handle this via the custom script (as per readme) and then auth the device using ubus but they still get the popup.

"hotspot" is the uspot name/interface
$MACADDR and $IPADDR comes through via the dhcp script

ubus call uspot client_auth "{ \"uspot\":\"hotspot\", \"address\":\"$MACADDR\", \"client_ip\":\"$IPADDR\" }" > /dev/null
ubus call uspot client_enable "{ \"uspot\":\"hotspot\", \"address\":\"$MACADDR\" }" 2>/dev/null

Is this expected behaviour or am I missing something? It's like we need the mac authentication to happen before the client device tries to check for Internet connectivity and this is what redirects to the CPD code and shows the portal page...

Thanks

Originally created by @PWJW on GitHub (Apr 23, 2024). Original GitHub issue: https://github.com/f00b4r0/uspot/issues/13 We are testing the MAC authentication option within uspot and although it's working and the user is successfully authenticated from our RADIUS server, they still receive the captive portal popup window (which then briefly disappears on Android or the window changes to "Done" on iOS). They are fully online and can browse by dismissing the portal popup and show "Authenticated" when querying via the `captive clients` CLI script. I've followed the instructions to have dnsmasq handle this via the custom script (as per readme) and then auth the device using ubus but they still get the popup. "hotspot" is the uspot name/interface `$MACADDR` and `$IPADDR` comes through via the dhcp script ``` ubus call uspot client_auth "{ \"uspot\":\"hotspot\", \"address\":\"$MACADDR\", \"client_ip\":\"$IPADDR\" }" > /dev/null ubus call uspot client_enable "{ \"uspot\":\"hotspot\", \"address\":\"$MACADDR\" }" 2>/dev/null ``` Is this expected behaviour or am I missing something? It's like we need the mac authentication to happen before the client device tries to check for Internet connectivity and this is what redirects to the CPD code and shows the portal page... Thanks

kerem closed this issue

2026-03-04 14:52:19 +03:00

kerem commented

2026-03-04 14:52:20 +03:00

Author

Owner

@f00b4r0 commented on GitHub (Apr 23, 2024):

if you remove the /dev/null redirections after each call you'll see in the logs whether or not the clients are authenticated via this mechanism. It may happen that some clients are "too quick" in testing connectivity and do show a popup anyway, this is outside of uspot control (you'll notice the popups display device-generated messages without showing the uspot pages) and so not an uspot issue.

The DHCP-based auth bypass is more a hack than a proper feature anyway so your mileage may vary anyway. MAC-auth is supported by uspot via the web interface (without the bypass script), where a uspot-generated message would be displayed.

@f00b4r0 commented on GitHub (Apr 23, 2024): if you remove the `/dev/null` redirections after each call you'll see in the logs whether or not the clients are authenticated via this mechanism. It may happen that some clients are "too quick" in testing connectivity and do show a popup anyway, this is outside of uspot control (you'll notice the popups display device-generated messages without showing the uspot pages) and so not an uspot issue. The DHCP-based auth bypass is more a hack than a proper feature anyway so your mileage may vary anyway. MAC-auth is supported by uspot via the web interface (without the bypass script), where a uspot-generated message would be displayed.

kerem commented

2026-03-04 14:52:20 +03:00

Author

Owner

@PWJW commented on GitHub (Apr 23, 2024):

The auth was successful as the logs show it :)

MAC auth works "properly" with coovachilli and all other wifi vendors I've used like Cisco, Meraki, Ruckus, Aruba etc, so I don't think its an issue with the client. On all of these other types of implementations, the client never sees any popup or redirect and is immediately online when the RADIUS replies with Access-Accept (before the client tries to call a URL).

The traditional purpose of MAC auth is to authenticate a device before a captive portal is involved so I feel the current implementation isn't really usable as a true MAC auth solution in the current way it's implemented. It will work for some use cases though!

Is there any plan to revisit how this is implemented at all?

Thanks again.

@PWJW commented on GitHub (Apr 23, 2024): The auth was successful as the logs show it :) MAC auth works "properly" with coovachilli and all other wifi vendors I've used like Cisco, Meraki, Ruckus, Aruba etc, so I don't think its an issue with the client. On all of these other types of implementations, the client never sees any popup or redirect and is immediately online when the RADIUS replies with Access-Accept (before the client tries to call a URL). The traditional purpose of MAC auth is to authenticate a device before a captive portal is involved so I feel the current implementation isn't really usable as a true MAC auth solution in the current way it's implemented. It will work for some use cases though! Is there any plan to revisit how this is implemented at all? Thanks again.

kerem commented

2026-03-04 14:52:20 +03:00

Author

Owner

@f00b4r0 commented on GitHub (Apr 23, 2024):

Is there any plan to revisit how this is implemented at all?

No, but this is opensource: patches are always welcome.

@f00b4r0 commented on GitHub (Apr 23, 2024): > Is there any plan to revisit how this is implemented at all? No, but this is opensource: patches are always welcome.

kerem referenced this issue

2026-03-04 14:52:24 +03:00

[GH-ISSUE #25] Support traffic caps #16

kerem referenced this issue

2026-03-04 14:52:38 +03:00

[PR #28] [MERGED] Implement traffic accounting and limiting via an eBPF module #37