RFC8910 Captive Portal

lobo83 · Fri Jan 28, 2022 4:35 pm

I know this has already been discussed, but has anyone had success?

This is what i have done for now.

We have valid certificate installed, and dhcp option 114 enabled.

I see requests for option 114 coming from the clients in wireshark

Option: (55) Parameter Request List
Length: 9
Parameter Request List Item: (1) Subnet Mask
Parameter Request List Item: (121) Classless Static Route
Parameter Request List Item: (3) Router
Parameter Request List Item: (6) Domain Name Server
Parameter Request List Item: (15) Domain Name
Parameter Request List Item: (108) Removed/Unassigned
Parameter Request List Item: (114) DHCP Captive-Portal
Parameter Request List Item: (119) Domain Search
Parameter Request List Item: (252) Private/Proxy autodiscovery

And the ACK looks like this:

Option: (114) DHCP Captive-Portal
Length: 38
Captive Portal: https://hotspot.xxxxxx.com/api

This is what i get when i enter this page, accesed via HTTPS.

{
"captive": true,
"user-portal-url": "https://hotspot.xxxxx.com/login",
"can-extend-session": true,
"info-venue-url": "https://hotspot.xxxxxx.com"
}

The api.json is stored in hotspot folder.

But, I dont see any requests for the captive portal API, instead I see the old method (captive.apple.com - get-hotspot / Generate 204 + 302 redirections) happening.

Tested with Android 11, IOS 15, and Big Sur.

Any clue to go further? What more could I debug?

Is there anything more to do to make this happen? I read you have to make the client capable to reach oscp or ntp servers to validate your certificate, but how could I know if this is what is happening here?

Mikrotik says:

"This DHCP option field is enabled automatically, but only if the router has a DNS name configured and has a valid SSL certificate (so that the login page can be accessed over HTTPS). When these requirements are met, a special DHCP option will be sent, containing a link to https://<dns-name-of-hotspot>/api. This link contains information in JSON format, instructing the client device of the captive portal status, and the location of the login page."

lobo83 · Sun Jan 30, 2022 11:08 pm

Why this is just ignored?

Sob · Tue Feb 01, 2022 6:44 am

Not that many people are interested in hotspot at all. And the whole thing seems like chicken and egg problem, most clients don't support it, and most hotspots probably don't either. It will take years to catch on. In the meantime, any client must expect that random hotspot doesn't support it yet, and must be able to use old method. So there's no pressure for hotspots to add this, because every client can use old method, which mostly works. It's like IPv6 adoption, why bother when everyone can use IPv4, which mostly works. I'm not saying that I like it.

I have nothing I could test this with, but if client asks for dhcp option and router provides it, then next action should come from client, I assume.

lobo83 · Tue Feb 01, 2022 3:53 pm

Thank you for answering,

I am aware there isn't much interest in it, but we are an Hotel, and for now, I don't know how to get rid of hotspot and give the same kind of service.

I see in older post about this ppl complaining about the inability of mikrotik to "force dhcp options", but it's not the case. And since I can see clients asking for DHCP option 114 (android, IOS, and OSX), I was wondering if they already switched to the new method.

Android support states that devices (from android 11) will ask for the API support First, and then, if the server doesn't support, it will change to the old method.

https://developer.android.com/about/ver ... ive-portal

I wouldn't care about this that much, because I could bypass this, but we have a Chromecast solution that need the client to login to pair him with his chromecast, so bypass is not an option. We are a luxury hotel and any loss of service leads to complaints.

So I am just looking for someone who can confirm that my "server side" is configured properly. I saw in other pages people saying that we had success in it, but using packetfence or dnsmasq.

https://developer.apple.com/forums/thread/660827
https://github.com/inverse-inc/packetfence/issues/5638

Thank you,

Sob · Wed Feb 02, 2022 1:08 am

I see in older post about this ppl complaining about the inability of mikrotik to "force dhcp options", but it's not the case.

I think it's still the case, it's about sending some option even when client doesn't ask for it. But yours do, so it's not a problem.

According to changelog, since 6.48 there's this:

*) hotspot - added support for captive portal advertising using DHCP (RFC7710);

It was replaced by RFC8910, but I don't see any mention of that in RouterOS changelog. But since it says that:

This document replaces RFC 7710 [RFC7710], which used DHCP code point 160. Due to a conflict, this document specifies 114.

And you see option 114, it looks like it was updated.

If I was you, I'd try to test some other hotspot server, to make sure that client works with it, and then the same client should work also with RouterOS. If not, you could compare what's different. A bit annoying, because it should just work, but what else can you do when it doesn't.

olivier2831 · Tue Aug 22, 2023 1:23 pm

Reading this not so old thread, have OP met success with RFC8910 since asking here ?
What about Win10 and Win11 clients ?

Tue Aug 22, 2023 2:44 pm

All should be compatible, as far as we have seen. The standard is implemented.

pe1chl · Tue Aug 22, 2023 3:15 pm

Unfortunately the standard is awkward. It would be quite helpful when the built-in http server would include some capability to return a JSON file (with the proper mime type) as required by the RFC8910 spec.
(of course the definition of that option is completely silly but that is not something "we" can change)

Tue Aug 22, 2023 3:21 pm

It can and it does already, RTFM

https://help.mikrotik.com/docs/pages/vi ... d=56459266

Guscht · Tue Aug 22, 2023 4:06 pm

Well Normunds, thats a bit vague:

[...]or manually add/edit the api.json file to have the above contents, for Hotspot detection to work.

Wehre do I have to place the file? Anywhere, a special location or folder? Which filename is used? Which DHCP-Option "a special DHCP option will be sent" should we add and how? Is the manual adding supported by ROSv6 too? In wour Wiki you write on top ROS v6.48 but in the manual adding section you mention only ROS v7.3.

BTW: As Mikrotik (!!!!!!!!!!!!!!!) to tell people RTFM, YOU GUYS NEED TO WRITE AT FRIST A GOOD MANUAL!!!

Tue Aug 22, 2023 4:08 pm

Please read the next sentence too!

> It is located in the router files menu.

It continues "you will have to use "Reset HTML" function, or manually add/edit the api.json file". If you click on the "reset html" button, the file is generated for you. You will not have to make or place it anywhere. It will be there automatically!

as for the contents, the link is provided with full example:
https://developer.apple.com/news/?id=q78sq5rv

We do make manuals, but people do not read them, even when provided with links.

Tue Aug 22, 2023 4:11 pm

P.S: forget about v6. Everything is about v7 now for 2 years already. Time to move on.

Amm0 · Tue Aug 22, 2023 4:19 pm

I'm not sure Windows respects the DHCP Option 114 / RFC-7110 / RFC-8910 scheme in the first place – Mikrotik can't change that

Windows does older check for redirects, which /ip/hotspot supports.

pe1chl · Tue Aug 22, 2023 4:45 pm

P.S: forget about v6. Everything is about v7 now for 2 years already. Time to move on.

Did you already tell that to the department that runs the performance tests and puts the results on the products website?
I think it is time to update them to v7 numbers,

BrianHiggins · Tue Aug 22, 2023 5:51 pm

I'm not sure Windows respects the DHCP Option 114 / RFC-7110 / RFC-8910 scheme in the first place – Mikrotik can't change that

confirmed it does not.

Also, for anyone trying to replicate this by uploading a text file to a webserver with the appropriate JSON string, that will not work. The webserver response content type must be set to Content-Type: application/captive+json in order for clients to accept & act on the values. Simply uploading a text file to a webserver will display the correct JSON string in your webbrowser, but it will be transmitted as Content-Type: text/plain and when accessed by the client, no redirection actions will be performed.

Tue Aug 22, 2023 5:53 pm

P.S: forget about v6. Everything is about v7 now for 2 years already. Time to move on.
Did you already tell that to the department that runs the performance tests and puts the results on the products website?
I think it is time to update them to v7 numbers,

new products have them. devices that ship with v6 have v6 results. we cant change devices that are already in distributor shops.

Amm0 · Tue Aug 22, 2023 6:03 pm

The webserver response content type must be set to Content-Type: application/captive+json in order for clients to accept & act on the values.

But to be clear, content type is actually set when using /ip/hotspot AFAIK. To @normis point, I tested /ip/hotspot docs a few a months ago actually, and if you follow them – especially the ones about HTTPS and certs — you end up with a hotspot that seem to work on Apple things at least.

Now when you files uploaded via branding/etc and do NOT use /ip/hotpot... totally right you cannot set a content-type of those files.

pe1chl · Tue Aug 22, 2023 6:06 pm

Did you already tell that to the department that runs the performance tests and puts the results on the products website?
I think it is time to update them to v7 numbers,
new products have them. devices that ship with v6 have v6 results. we cant change devices that are already in distributor shops.

As you know very well, there are devices that were initially shipped with v6, have v6 test results on the site, but at this moment are shipped
with v7 and cannot be downgraded to v6 to get the performance that was advertised.
Are you going to update all the performance figures for shipping devices to v7?
Why is it so difficult to add the information like RouterOS version used to get these test result (and IP protocol version) to each test result table?

BrianHiggins · Tue Aug 22, 2023 6:14 pm

The webserver response content type must be set to Content-Type: application/captive+json in order for clients to accept & act on the values.
But to be clear, content type is actually set when using /ip/hotspot AFAIK. To @normis point, I tested /ip/hotspot docs a few a months ago actually, and if you follow them – especially the ones about HTTPS and certs — you end up with a hotspot that seem to work on Apple things at least.

Now when you files uploaded via branding/etc and do NOT use /ip/hotpot... totally right you cannot set a content-type of those files.

I made no claim one way or another regarding the content type on the data returned from the hotspot service. My point was relating to lobo83's comments regarding uploading the files somewhere and that it loaded correctly from their webbrowser but didn't redirect from the client.

Amm0 · Tue Aug 22, 2023 6:27 pm

My point was relating to lobo83's comments regarding uploading the files somewhere and that it loaded correctly from their webbrowser but didn't redirect from the client.

I think @normis thinks it works... because /ip/hotspot does in fact work correctly in V7.

But you're right there is still a feature request/bug here, outside of /ip/hotspot. You should be able to upload the api.json needed for Option 114 via branding kit and have it work independently of /ip/hotspot. e.g. RouterOS http server using the right MIME-type for the captive portal JSON file, by uploading it to a specific path using branding kit. That would be useful.

BrianHiggins · Tue Aug 22, 2023 7:23 pm

I think @normis thinks it works... because /ip/hotspot does in fact work correctly in V7.

I would be more surprised if it didn't work than hearing it does work. It's a pretty simple function to implement there really isn't much to it code wise, I wrote the whole functionality to support it for our platform in 1 day, including testing and release.

But you're right there is still a feature request/bug here, outside of /ip/hotspot. You should be able to upload the api.json needed for Option 114 via branding kit and have it work independently of /ip/hotspot. e.g. RouterOS http server using the right MIME-type for the captive portal JSON file, by uploading it to a specific path using branding kit. That would be useful.

I actually disagree, I think there's little reason it should be supported on the built in web server via any uploaded file. I even disagree that the hotspot should even read a config file at all. I think the hotspot should simply have a settings parameter that can specify the URL and then a static path defined on the webserver like hotspot/redirect that when called it just computationally generates the 4 lines of JSON text needed. There is no need for the api.json text file at all unless it can be demonstrated somehow that reading the file, parsing the contents, replacing the variables, then rendering the output, is somehow faster than just appending the variables and a few strings then rendering the output.

Remember all it needs to do is generate the following string, there's more characters of variables than there is content that's being read from the file on disk/flash

{
"captive":"true",
"user-portal-url":"https://yoururl.com/landingpage"
}

venue-info-url is optional and not required...

RFC8910 Captive Portal

RFC8910 Captive Portal

Re: RFC8910 Captive Portal

Re: RFC8910 Captive Portal

Re: RFC8910 Captive Portal

Re: RFC8910 Captive Portal

Re: RFC8910 Captive Portal

Re: RFC8910 Captive Portal

Re: RFC8910 Captive Portal

Re: RFC8910 Captive Portal

Re: RFC8910 Captive Portal

Re: RFC8910 Captive Portal

Re: RFC8910 Captive Portal

Re: RFC8910 Captive Portal

Re: RFC8910 Captive Portal

Re: RFC8910 Captive Portal

Re: RFC8910 Captive Portal

Re: RFC8910 Captive Portal

Re: RFC8910 Captive Portal

Re: RFC8910 Captive Portal

Re: RFC8910 Captive Portal

Re: RFC8910 Captive Portal