Captive Portal not working on iOS devices only (DHCP 114)
-
Your last to phrases :
The fix to RFC8910.php suggested ...
and
For this reason, thermostats, ....
That's what I had in mind : 'thermostats', APs, smart switches and whatever other devices hosted on the portal network, these devices are typically white listed by using "Allowed IP" (and/or MAC probably) are mostly automates that don't know sh#t about portal login and/or don't use DHCP 114 (RFC8910) anyway - as you said already.
These devices won't consult the the portal's "venue-info-url" neither.The same type of filtering against the two "Allowed IP" and "MAC" lists isn't needed in the original portal's index.php
That said, devices have their MAC listed as "blocked" do inform the connected user with a message that his MAC is blocked (inviting him to change his MAC address ^^).Updated : I've also added MAC listed handling :
if (is_array($cpcfg['allowedip'])) { foreach ($cpcfg['allowedip'] as $ipent) { if ($ipent['ip'] == $clientip) { if ($ipent['dir'] != 'to') { // 'clientip' is part of the 'allowedip' list ob_flush(); return; } } } } $clientmac = pfSense_ip_to_mac($clientip); if (!is_array($clientmac)) { if (!isset($cpcfg['nomacfilter']) || isset($cpcfg['passthrumacadd'])) { /* unable to find MAC address - shouldn't happen! - bail out */ captiveportal_logportalauth("unauthenticated", "noclientmac", $clientip, "ERROR"); echo "An error occurred. Please check the system logs for more information."; log_error("Zone: {$cpzone} - Captive portal could not determine client's MAC address. Disable MAC address filtering in captive portal if you do not need this functionality."); ob_flush(); return; } } else if (is_array($cpcfg['passthrumac'])) { foreach ($cpcfg['passthrumac'] as $macent) { if ($macent['mac'] == $clientmac['macaddr']) { if ($macent['action'] == 'pass') { // 'clientmac' is part of the 'allowed MAC' list ob_flush(); return; } } } }I took the initial MAC testing directly from the portal's 'index.php' file : if no MAC was found, but MAC usage isn't' disabled, then messages are logged/shown.
-
@Gertjan
Good Work, I tested the fix(es) under Kea/Plus 24.08 Dev (0925) and they work as advertised. I suggest you publish the full updated RFC8910.php here so others can quickly get the current result of this project to date. -
Lately, I see more and more devices making use of DHCP option 114, which means they load the rfc8910.php file as soon as they connect to the portal wifi :
In just 5 hours :
2024-11-11 17:03:50.982716+01:00 logportalauth 4858 Zone: cpzone1 - cpzone1: rfc8910, NEW SESSION : portal.portal-url.tld:8003, 192.168.2.19 2024-11-11 15:59:16.128747+01:00 logportalauth 55790 Zone: cpzone1 - cpzone1: rfc8910, NEW SESSION : portal.portal-url.tld:8003, 192.168.2.145 2024-11-11 15:27:08.008311+01:00 logportalauth 94285 Zone: cpzone1 - cpzone1: rfc8910, NEW SESSION : portal.portal-url.tld:8003, 192.168.2.192 2024-11-11 14:51:05.807693+01:00 logportalauth 74770 Zone: cpzone1 - cpzone1: rfc8910, NEW SESSION : portal.portal-url.tld:8003, 192.168.2.173 2024-11-11 11:59:40.897204+01:00 logportalauth 33392 Zone: cpzone1 - cpzone1: rfc8910, NEW SESSION : portal.portal-url.tld:8003, 192.168.2.248and for what it's worth : since I'm using this 'addon' file I have the strong impression the portal access is working better as the native 'http intercept' method that pfSense offers.
Close to none come to the hotel reception anymore to ask confirmation about how to connect to the hotel's Wifi. People connect, login, and do their thing. -
@Gertjan said in Captive Portal not working on iOS devices only (DHCP 114):
People connect, login, and do their thing.
Yes, very little support required. The most common inquiries are due to auto login getting turned off (they click "use without internet") and don't understand they have to forget and reconnect. Typically that happens only once though. With Captive Portals that have "last login" set it is not unusual to see 4 or 5 logins per minute as families just there for the day share a 24_Hr voucher so it can get quite a workout. It has been trouble free.
The other feature in iOS is the "Open Portal Page" feature under iOS 17 and above. This opens the Venue URL option in RFC8910 and we use it to provide time and data quota remaining information. Once shown this, all the questions about how much time or data remains on their account also go away. This is particularly true for those with weekly and monthly access, especially those Portals that provide multi user/account access where Data Quota and Time Quota are shared. Once shown this feature (click the circled i beside the WiFi Network name) they also tend to not require any further support. At any point in time during the busy summer period, this could involve up to 500 connected devices so having no support for that quantity is a real compliment to RFC8910 and DHCP 114. iPhone users are also getting familiar with these features and starting to demand them. The RV Park now hands out a info page on WiFi that mostly explains how iPhone and Android support logins and how to use the "Open Portal Page" feature to track their account status. That helps reduce support as well.
We need pfSense to support DHCP 114 under Kea (there is an unsupported patch (see Redmine feature #15321) which is working for me in the Lab under 24.11 Oct Beta. Kea now includes DHCP 114 as a built in option, not a custom one as per ISC. It is just the pfSense Plus GUI that doesn't support it yet and I have been told it won't in the stable release of 24.11 either but it should be there after that. ISC does work as a custom option so no excuse not to implement it.
-
@EDaleH said in Captive Portal not working on iOS devices only (DHCP 114):
We need pfSense to support DHCP 114 under Kea (there is an unsupported patch (see Redmine feature #15321) which is working for me in the Lab under 24.11 Oct Beta. Kea now includes DHCP 114 as a built in option, not a custom one as per ISC. It is just the pfSense Plus GUI that doesn't support it yet and I have been told it won't in the stable release of 24.11 either but it should be there after that. ISC does work as a custom option so no excuse not to implement it.
It saw your redmine.
I was wondering for a while :
This - on the captive portal's configuration page - is not rocket science :
When the option is set, and the interface is known (and safety check : if a DHCP server is set up to run on this interface, which is imho pretty mandatory) then the portal setup page should modify the DHCP server settings of the interface to include :
where the portal URL is :
If https was chosen, the interface IPv4 otherwise.
The port number (8003 here) is avaible in the portal config.
The zone ID (name) is avaible in the portal config.
The file name "rfc8910.php" is arbitrary, and must exists in the /usr/local/captiveportal folder.What I don't like about this way of implementing things : a configuration setting on the captive portal's configuration page will "add" (replace ? remove ?) a configuration 'option' setting on the related DHCP server page.
Something in my head says that that is not the way of doing things.So: Plan B : way easier, but needs some action from the admin :
When the RFC8910 option is checked on the portal configuration page, have it appear an extra help line that shows what to do :Go to the DHCP server page, and under "Custom DHCP Options" add : Number : 114 Type : String Value : "https://portal.url.rld:8003/rfc8910.php?zone=cpzone1" (with the double quotes).Forgetting to do this won't break anything.
But unchecking the RFC8910 portal option needs a reminder that manually this option needs to be removed under the "Custom DHCP Options".
Hummm, not perfect good neither. -
I personally see RFC8910, DHCP option 114, as belonging in the DHCP setup exclusively. Currently with ISC there is the warning to enable DHCP on the Captive Portal and that warning should include a statement to the effect that DHCP option 114 should be configured for DHCP as well. Option 114 in Kea is not a custom option, it is one of the supported options that are included in their standard setup, you simply fill in the info.
Having said that, it is not simple, especially when you consider that option 114 also offers up both at True/False (for the login page) determination and a vendor URL option that is potentially unrelated to the Captive Portal. You bring up a good point that simplifying that for end users wouldn't hurt. To that extent, it would be nice if the GUI within Captive Portal had a check box to provide a sample set of code, not unlike what it does for the login page. It could then place that code into the appropriate directory and have a button to populate (or suggest) the DHCP option 114 for that specific interface.
There is no point in modifying ISC any longer and with no GUI for Kea yet, we don't know how they intend to handle all DHCP options, not just DHCP option 114.
We do have a working solution for the Plus 24.11 Oct 31 Beta that works with the code presented in this discussion and it appears we will need to continue using this until the Plus release starts with a 25. For CE users it is up and running as a custom option, also workable.
Maybe Netgate is listening and will acknowledge that Captive Portal use represents a substantial number of installations of the product and deserves addressing this in the next GUI for all future releases of both CE and Plus?
-
You're right.
Instead of mentioning RFC8910 on the captive portal configuration page, it should be mentioned on the DHCP server page (ISC, KEA, whatever).The "option 8910" should show up if the interface used by this DHCP is also used on a configured captive portal.
The info needed to create the "DHCP Option 114" URL can be sourced from the captive portal instance that is using this interface.
This is a cleaner solution.At the bottom of the captive portal configuration page, a reminder should be added here :
that an active captive portal has the new option "8910" available on the DHCP server page.
I get it, this will be something for the future.
For me, the RFC8910 is already working just fine for 6 months now, and it will also work for me whatever 24.11 offers (I'll patch it if needed).
Right now, adding 8910 is rather easy to do : adding a file and adding adding a "DHCP 114 option" and done.Normally, a DHCP server (ISC, Kea, whatever) offers DHCP options, and adding custom option isn't a ISC only thing. Kea supports them just fine. It's probably just the pfSense GUI front end that will be missing the needed logic to implement it.
-
@Gertjan said in Captive Portal not working on iOS devices only (DHCP 114):
Normally, a DHCP server (ISC, Kea, whatever) offers DHCP options, and adding custom option isn't a ISC only thing. Kea supports them just fine.
Yes, but as testing the patch demonstrated, Kea is very fussy about if the option is custom or built in. Enabling DHCP 114 as a custom option under Kea in the patch (https://redmine.pfsense.org/issues/15321) crashes Kea. It is essential you use the built in label for DHCP 114 in Kea, that label is "v4-captive-portal". You will place the string in association with that label in some unknown way as no GUI exists yet for Kea.
-
@Gertjan
Look at Redmine Feature #15904 at https://redmine.pfsense.org/issues/15904
and help move this along if you like the idea.The objective is to support RFC8910 on Captive Portal right out of the box by simply checking an automatic support checkbox in KEA when the GUI arrives.
I would also like to point out that the current RFC8910.php file is no longer compatible with the index.php implementation under 24.11, despite the fact it appears to work ... so far.
-
@EDaleH said in Captive Portal not working on iOS devices only (DHCP 114):
Look at Redmine Feature #15904 at https://redmine.pfsense.org/issues/15904
and help move this along if you like the idea.That the file I'm - my captive portal users - using since ... 6+ month now.
@EDaleH said in Captive Portal not working on iOS devices only (DHCP 114):
I would also like to point out that the current RFC8910.php file is no longer compatible with the index.php implementation under 24.11, despite the fact it appears to work ... so far.
Strange.
I didn't change my copy of "RFC8910.php" for several weeks or month now.
The one I'm using now, is the one I was using for month with 24.03.That said, my copy is somewhat different - I've less lines.
This is the copy shown in the redmine 15904 : https://redmine.pfsense.org/attachments/6335
My version is a bit smaller :Line 13 : Not needed. I commented it out. ( all the globals aren't used, not referenced in the file)
Line 26 : Not needed, I commented it out ( $cpzoneid isn't used anywhere)and that's it. The rest is the same.
Again : I didn't modify this file for months now. Ugraded to 24.11 and everything was working as before.
True, When switching to kea, I had to apply the patch and make this 100 % correct :
{ "option-data": { "opt2": [ { "name": "v4-captive-portal", "data": "https://portal.bhf.tld:8003/rfc8910.php?zone=cpzone1" } ] } }To make 'rfc8910' work.
"opt2" as my captive portal lives on "opt2", "rfc8910.php" is the name of the file. "cpzone1" is the name of my portal zone, "portal.bhf.tld:8003" is the URL of my https captive portal.
My entire JSON structure = kea config settings is somewhat bigger as I also use Unifi AP's for my captive portal and on my LAN interface ("lan") and these make use of a DHCP custom option 43.
This "43" one is special as it it not defined / not known to kea. The server needs to "learn" about it first, it has to be 'defined' before it's used.That's what the "option-def" and "name": "custom-option-vendor" and "data": "01 04 C0 A8 01 06" (== for me IP 192.168.1.6) is all about.
Actually, when you know what is needed, and what it does, it's really simple
For me, https://redmine.pfsense.org/issues/15321 was of great help.
Of course, the example Dale Harron showed missed a '{' quoto somewhere, but the general idea was ok.
You said it your self : kea does not allow mistakes - it doesn't allow fussy logic ^^ -
@Gertjan said in Captive Portal not working on iOS devices only (DHCP 114):
Actually, when you know what is needed, and what it does, it's really simple
There is no reason why pfSense can't support RFC8910 "out of the box" by simply checking off a checkbox in the GUI for either Captive Portal or Kea. Kea can still support customizing it directly in the Kea GUI once that editor exists but the default state should be that when you create a Captive Portal, the default login screen is sent via the RFC8910 JSON to the client automatically. This is the identical string that Captive Portal uses in index.php, it simply gets inserted into the Kea setup string as a " v4-captive-portal" entry for that interface, if one does not already exist, using the same principle applied in Kea DHCP Custom Options Support (IPv4 and IPv6). By doing so, an out of the box Captive Portal with the checkbox for RFC8910 support checked will work on an iPhone for example. This is what Redmine Feature #15904 is trying to promote.
As you said, "it's really simple".
If you want to know why the existing RFC8910.php file, based on index.php code, could become dangerous in some circumstances with MIM enabled, look at enabling-mim-causes-authentication-error-for-voucher-based-logins-in-captive-portal. Hint: skip to the bottom of the exchange.
By building support into the Captive Portal itself, current index.php logic (not that borrowed from an old index.php file in RFC8910.php) can be used to determine the string without us playing catchup with RFC8910.php every time a new version of pfSense is released. As this is becoming widely used, it is in Netgate's best interest to make it redundant in support of long term reliability. As Kea indicates, RFC8910 is mainstream and if it is a built in option for Kea, it may as well be built into Captive Portal when Kea is the DHCP server.
-
@EDaleH said in Captive Portal not working on iOS devices only (DHCP 114):
There is no reason why pfSense can't support RFC8910 "out of the box" by simply checking off a checkbox in the GUI for either Captive Portal or Kea. Kea can still support customizing it directly in the Kea GUI once that editor exists but the default state should be that when you create a Captive Portal, the default login screen is sent via the RFC8910 JSON to the client automatically. This is the identical string that Captive Portal uses in index.php, it simply gets inserted into the Kea setup string as a " v4-captive-portal" entry for that interface, if one does not already exist, using the same principle applied in Kea DHCP Custom Options Support (IPv4 and IPv6). By doing so, an out of the box Captive Portal with the checkbox for RFC8910 support checked will work on an iPhone for example. This is what Redmine Feature #15904 is trying to promote.
rfc8910, for captive portal handling, will be the future.
No more DNS redirection needed. Just a web server that listens on 'some' port, waiting for a portal device to connect. The device will connect to the portal login page server as it was told to do so when it obtained a DHCP lease, and thus the got the option 114.
This method has another advantage : it will bring us the IPv6 capable portal access.
So, yes rfc8910 simplifies portal detection a lot as there is non detection needed anymore (read : devices with extremely crappy OSes that don't handle portal detection very well) . The device what to do.
A status page, logout page, it's all handled.If we forget for a moment the "kea options question", the current 'manual' rfc8910 implementation is dead easy : put a file in place, add an DHCP ISC option 114 and done.
No thrills, no risks, it works.Right now, you and me use this rfc8910 method. Probably some others also. More people need to mention here with a "Hey, Netgate, can we get this done ?"
@EDaleH said in Captive Portal not working on iOS devices only (DHCP 114):
If you want to know why the existing RFC8910.php file, based on index.php code, could become dangerous in some circumstances with MIM enabled, look at enabling-mim-causes-authentication-error-for-voucher-based-logins-in-captive-portal. Hint: skip to the bottom of the exchange.
I've read that thread.
I even compared the 'pfSense 2.7.2' - /usr/local/captiveportal/index.php from Github with mine (24.11).
I didn't saw any MIM additions.
One or two known bug fixes, I know them all, and the "XML storage array" access method have been replaced for the newer ones (I thought this was needed as PHP 8.x was asking for this, not the MIM support).
Anyway : you've changed a pfSense core file (usr/local/captiveportal/index.php), then upgraded pfSense, and then took the old core file back in. That, yeah, that can ( will !) break things ^^ -
@Gertjan said in Captive Portal not working on iOS devices only (DHCP 114):
yeah, that can ( will !) break things
When advice is given in these forums that results in customization of code, independent of the file, captiveportal.inc is a common example, but using index.php to create RFC8910.php is as well. You may have noticed minor changes to the shared lines in the 24.11 index.php and I am now testing the RFC8910.php version derived from the 24.11 stable version of index.php.
I think it is important to remind ourselves how easy it is to get complacent. I have added checking file differences in index.php vrs RFC8910.php to my pfSense version upgrade checklist along with a a long standing detailed review of new-vrs-old captiveportal.inc. I had to completely re-integrate my updates for the 24.11 Stable release of captiveportal.inc as there are quite a few subtle changes. It is critical for the installation to work, pfSense is just along for the ride, it is the logic driving the Captive Portal workflow that matters and that starts with DHCP providing an IP address that includes RFC8910 JSON data on option 114. As long as it is not done within pfSense itself, the custom RFC8910.php file derived from a prior version of index.php will continue to be a potential liability. Every line of custom code running addresses a deficiency in the Captive Portal implementation, all of them are covered by Redmines. That custom code needs to be checked every time there is a new release until those Redmines are integrated into pfSense and they are not scheduled for the next release. This recent need to update (keep up) is driven by ISC becoming End of Life and thus potentially no longer receiving security updates.
-
G Gertjan referenced this topic
-
@Gertjan said in Captive Portal not working on iOS devices only (DHCP 114):
quote from EDaleH: I would also like to point out that the current RFC8910.php file is no longer compatible with the index.php implementation under 24.11, despite the fact it appears to work ... so far.
Testing has demonstrated what I consider a serious problem:
With Kea reclaiming IPs very quickly and often reassigning them seconds later, the Captive Portal database can be out of date in a couple of hours. This results in confusion when the client returns, gets a different IP that is no longer authorized based on current code (index.php, RFC8910.php), the client logs in and now there are two IPs authorized with the same MAC. Then Kea gives out the original IP to a client that now shows up with a different MAC. index.php thinks they are authorized but the CP code does not so their system just sits there with no internet access or it pops up a logout page. To observe this, simply connect a few devices, let the leases expire. Then connect a a few more or connect in a different order and you should see IP conflicts and duplicate MACs in the CP database of authorized users.
I have suggested that both index.php and a hopefully "built-in" RFC8910 DHCP 114 Kea support should be checking the MAC in the CP database and updating that database to reflect the current IP instead. See: lBuilt-in Captive Portal Support for RFC8910, DHCP option 114 in Kea
One side effect of this approach is that it will make the transition from ISC to KEA simpler as it will automatically reassign the IPs in the database based on an authorized MAC address in the CP database as KEA assigns new IPs to devices as they connect. This will be seamless, they will not have to re-login. They can also be absent for extended periods of time and when they return, if their authorization has not timed out, they will reconnect without tying up an IP in their absence.
-
@EDaleH said in Captive Portal not working on iOS devices only (DHCP 114):
To observe this, simply connect a few devices, let the leases expire.
I'll try this.
Default leases are 120 minutes ? (more ? I'll see, and adapt if needed).
I presume I have to de activate the wifi after logging into the portal, otherwise my device will simply, at 120/2 renew the lease and I'll wait forever.
I also have to raise the soft idle timeout - mine is set to 60 minutes right now. Knowing that the value should be smaller then the DHCP lease (I don't recall the exact logic, but there were discussion about this eons ago.@EDaleH said in Captive Portal not working on iOS devices only (DHCP 114):
the Captive Portal database can be out of date in a couple of hours
That how many logged in portal users ?? 50K or so ? My personal record is 200.
@EDaleH said in Captive Portal not working on iOS devices only (DHCP 114):
should be checking the MAC in the CP database and updating that database to reflect the current IP instead
Hummm.
So,
IF (MAC-device is found in the portal database)
THEN replace the IP-device with the IP in the database, in the found record.That's no rocket science but the list with side effect is probably not 'zero'.
Next-best : if the MAC was found (so a previous logged instance exists), but the IP changed, then delete the record (do a log out of user). The user will be thrown back to the login page, and from there it's just a 'comfort thing', but the user will know what to do.I've a question based upon pure on "me thinking" : isn't a DHCP server serving IPs out of the pool, and it will chose the one that wasn't used for the longest period ?
After all, if a connection breaks for a moment, which is more then typical with a wifi connection,the same MAC will be presented and the DHCP will know that that device was using that IP.
A device that disconnects for more then a few moments, and the IP that was used during it's initial lease is already occupied by another device ... doesn't that mean that your DHCP pool is way to small ?
I know a device can ask for a "preferred" IP (lease) - but I really thought there were some condition to be met before kea actually grants such a request. Like : everybody want "192.168.2.2", and kea hands one out to the very first who is asking for it. If this lease isn't renewed, another device might get it, if it was asking also for 192.168.2.2.Btw : I start to see the reason why the portal soft idle time out should be, if possible, shorter as the DHCP lease duration. This will take care of things ...
kea knows what it did in the past, even if you restart it : see the 2 (or 4) files here : /var/lib/kea/
Btw : right now, my captive portal KEA DHCP server is using a pool : 192.168.2.10 to 192.168.2.254 or about 244 lease are possible before something nasty happens.
Right now, the risk I see more then 30 users is .... close to zero.edit : If you think I didn't get the issue, say so.
-
@Gertjan said in Captive Portal not working on iOS devices only (DHCP 114):
Btw : right now, my captive portal KEA DHCP server is using a pool : 192.168.2.10 to 192.168.2.254 or about 244 lease are possible before something nasty happens.
Right now, the risk I see more then 30 users is .... close to zero.Fully understanding the issue is not necessary, best to focus on the results. With ISC, it maintained a list of expired leases and you can see those through Status, DHCP Leases, Show all configured leases. The snapshot below is of the Production 8 Portal RV site that closed on Oct 15th. You will notice that the configured leases still fill 3 of the pools. It stays that way after a month or so because so many devices connect that do not log in but do get a lease before they move on.
Everything works fine because ISC appears to re-allocate from the oldest lease and it has never allocated an IP that is recent enough to cause any issues. I suspect many Captive Portals work this way. Even though your lease expired, when you return, you get your old IP and can reconnect, even if your CP timeout is a month for example.
Yes, the lease should be longer than the idle timeout on the user, suggesting they will be timed out at/before the lease expires. That is not the real world though. Even though your lease expired, when you return, you get your old IP and can reconnect, even if your CP logout timer is a month for example. With Kea limited to 24 hr leases, that would mean week, month and forever could not exist but they are in common use, particularly if you use freeRadius. With ISC, those CP time limits are matching those durations associated with the account, be it a voucher or freeRadius "forever" account (they have day, week, month built in). So it is all about if you want the user to be logging back in all the time. If you set the time limit to < or = the lease time, they will have to log in every time they leave or are out of wifi range for longer than the DHCP lease. Yes, they get very angry when they pay for a month of access and only get 2 hrs away before they have to log in again, for example, every time they go buy groceries. They want to log in once and automatically be logged out at the end of the time they paid for. They don't wan to miss email just because they did not notice their phone popped up a login screen when they got back and as a result is not connected. It should work like it does at home, just simply reconnect when you get to the driveway. To achieve that, we can't disconnect them from the portal. With ISC, even though we have filled the pool, we are safely within that month or so time before the lease gets reallocated to a different MAC.
The difference is how Kea manages expired leases. If you watch a lease expire in Kea, it disappears from the "Show All configured leases" in seconds. Now it is in the pool and Kea loves to allocate the lower IPs frequently. During testing I was trying to create a duplicate by logging other systems in one after the other once 3 leases had expired. It only took 3 tries and two minutes before the IP was allocated to a different MAC, that IP was XXX.XXX.XXX.002, the first IP in the pool. Now I logged that user in and sure enough, I had two of the same IPs in the CP database with different MACs. When I try to use one or the other, the CP will look up the sessionid for the first IP in the database and one of them can't connect at all. Now you immediately say, but I broke the rules, the CP account should have expired with the lease and that would prevent the duplicate. True based on the CP warning in the GUI, but not real world and more important, very different from the experience with ISC as the DHCP Server.
There is absolutely no reason why the CP account authentication has to expire with the IP lease, as demonstrated in the logic presented in the example code. Unfortunately it appears to loop while the login screen is on the remote client and waiting for entry of login credentials so pfSense programmers need to get involved in making it CPU efficient.
It also really messes up Smart Devices that use DHCP 114 as if the IP/Mac is not in sync, they will just get stuck in the temporary browser screen trying to load either the login or logout page and of course appear to be hung.
Fixing the CP db IP in the index.php file leaves all existing CP code intact and functional. Pretty basic stuff and a permanent solution that works with ISC and KEA and even lets you switch back and forth between them without disconnecting the users as index.php will now sort out the IP conflicts automatically.
I hope this make sense to you. For us, it is critical to retaining functionality on a very successful installation(s). 0 support requests in 2024 vrs 20 complaints in the first day when authentication was tied to lease timeouts (that was in 2021 when it first went into service). pfSense has been running at this site since 2010 or so. I have supported it that entire time. Without this fix, we stick with the exceptionally stable CE 2.7.2 and ISC (running on Netgate XG-1541 maxes because Plus was not as stable and difficult to keep up with, case in point!)
-
@EDaleH said in Captive Portal not working on iOS devices only (DHCP 114):
The difference is how Kea manages expired leases. If you watch a lease expire in Kea, it disappears from the "Show All configured leases" in seconds
A wild shot :
https://kea.readthedocs.io/en/kea-2.0.0/arm/dhcp4-srv.html#why-is-lease-file-cleanup-necessary
Look what lfc-interval can do for you ?
pfSense doesn't add that config setting, so there must be some 'default' value. Dono what it is.
You suggest : within seconds. Looking at my time stamps, you're not far of.I've added this into my kea-dhcp4.conf file (by editi,ng /etc/inc/services.inc) :
with 2592000 is the number of seconds in a month.
It won't get overboard, as I haven't that many lease to offer.
In theory, the leases file will now grow (not cleaned) ? We'll see.edit : be aware : you use 2.7.2, the kea implementation might be somewhat different.
-
@Gertjan said in Captive Portal not working on iOS devices only (DHCP 114):
edit : be aware : you use 2.7.2, the kea implementation might be somewhat different.
No, the production site is on 2.7.2 and has no issues at all, that snapshot was of it today. The lab site is the subject of this post, i.e. the next upgrade, is on 24.11 Stable with Kea patched for RFC8910.
wrt to extending the life of a lease, that is not a good solution because we do have enough traffic to run out of leases, it is far superior to manage the IP assigned to the "authorized" MAC in the Captive Portal Database. That will survive most attempts to lock up the available leases, be it deliberate or a feature of the usage. The Captive Portal would be able to support more users than there are leases, like a fast food place for example where a lot of people come and go but at any one time they are within the DHCP pool size. Log in once and you reconnect automatically every time you go there, much like you can select to auto login to the WiFi itself.
Now is the time to fix this so Kea can go into service and meet it's high availability goals and we can create portals with logins that never expire unless we want them to, a dramatic improvement in functionality.
-
@Gertjan said in Captive Portal not working on iOS devices only (DHCP 114):
I've added this into my kea-dhcp4.conf file (by editi,ng /etc/inc/services.inc) :
I continued to focus on living with the IP changing frequently due to agressive reclamation of leases by Kea as that is the default setting and in our favor if the network gets heavily loaded so that leases are available.
I did find some coding typos and a logic error in my earlier index.php and RFC8910.php attempts to achieve this. I have uploaded the most recent files that passed my lab test today. I think they will demonstrate how this could work. If you want to do any testing yourself, the files are attached to Redmines 15854 and 15904. I will keep those proof-of-concept files up to date if further changes are necessary.
I am optimistic that we can not only adopt Kea in place of ISC sooner, but improve the Captive Portal at the same time. If you see this potential as well, let's encourage Netgate to incorporate a Mac authentication based Captive Portal (i.e. IPs can change anytime) and incorporate a default RFC8910 DHCP 114 support into Captive Portal/Kea so that Smart Devices like the iPhone will work with a first time setup without forcing those new to Captive Portals to read through massive user form entries to achieve a basic functionality with all devices.
-
@EDaleH said in Captive Portal not working on iOS devices only (DHCP 114):
I continued to focus on living with the IP changing frequently due to agressive reclamation of leases by Kea
Kea, if not asked for, doe nothing. It doesn't spam leases into a LAN. It only answers to a device that is asking for a lease. [sorry, had to say this ^^]
With any APs and many SSID type devices, like a lot (thousands) I can presume that your Kea is actually handling a lot of requests.
@EDaleH said in Captive Portal not working on iOS devices only (DHCP 114):
but improve the Captive Portal at the same time.
Your kidding ? This will open the door to full IPv6 support also. And IPv6 that will handle your 'pool full' issue ;)
@EDaleH said in Captive Portal not working on iOS devices only (DHCP 114):
If you see this potential as well, let's encourage Netgate to incorporate a Mac authentication based Captive Portal (i.e. IPs can change anytime) and incorporate a default RFC8910 DHCP 114 support into Captive Portal/Kea so that Smart Devices like the iPhone will work with a first time setup without forcing those new to Captive Portals to read through massive user form entries to achieve a basic functionality with all devices.
Well, sure thing.
You mean lobbying ? Like in the states ?
If there is one guy at Netgate that takes a look what RFC8910 does, that its been test driven for the better part of a year now, that it doesn't need any code changes in the actual portal scripts (code) - that it can be activated or de activated with a click (I've made this in the GUI just for the fun) , that, yes, a DHCP Kea option 114 is needed - which tells me Marcos (Netgate, right ?) is already aware of what RFC8910 does.
But : from their point of view : what do they gain ? I never fully understood the real reason of making things more complicate ... euh .. sorry, adding more gadgets every day.
Gadgets have to be supported.
The average pfSense admin knowledge level isn't getting better every day neither (talking about myself of course).
And one last thing : I do see your issue, but I can 'lobby' for a feature that I do not use myself. Only if it works for me, and, yes, I'll repeat again : RFC8910 works even better as the original 'Netgate' portal implementation. So : we should all be winners ?I'm pretty sure 'they' already know about this RFC8910 things, but what or who is able to put the RFC8910 implementation order higher up in the "must this do first" list... I don't have his or her phone number and something says me this person doesn't use the forum (neither redmine).
@EDaleH said in Captive Portal not working on iOS devices only (DHCP 114):
default RFC8910 DHCP 114 support into Captive Portal/Kea so that Smart Devices like the iPhone will work with a first time setup without forcing those new to Captive Portals to read through massive user form entries to achieve a basic functionality with all devices.
Not really an issue for me.
Because my iPhone 'knows' about 'my captive portal', and when I switch from native portal 'pfSense' portal mode to RFC8910 'assisted' mode (or back to 'Netgate' mode), my phone has difficulties to connect as it keeps profiles of each Wifi connection that it has used in the past. I have to zap the profile, and case closed.
I agree, before, I don't recall I had to do this anywhere else. I didn't even kown I could 'delete' the profile. (well, I did, but didn't saw the usage of it)
Other people, like my clients, who bring in their iPhone or iPad (and other devices also) will connect to my SSID (portal) and don't have any issues at all with my captive portal ruunning on RFC8910 mode.
This issue is probably an Apple iOS issue. Let's contact apple devs ?