Since I was curious on Option 114 and hadn’t tried NodeRED in years (nor in a Mikrotik container, which was surprising easy FWIW). This test I used a “Option 114 Only” approach, with NodeRED responding the RFC-8908 “Captive Portal API” request upon Wi-Fi connection (based on a NodeRED https url being provided in the DHCP).
My test here was using NodeRED container and using Option 114 to redirect to that container WITHOUT hotspot or /ip/proxy. And, on MacBook and iPhone at least, the Apple’s captive portal dialog appears. It is quite simple actually…
I had NodeRED just display some plain test in response to a /status “http in” flow…so this comes from NodeRED (e.g. could be some existing NodeRED status page).
And the above showed same on iPhone. Some notes on what I did:
NodeRED
-
You need a working NodeRED. For my test, I installed it in a container with NodeRED to test – using “nodered/node-red” docker image, adding mount for /data, and bridging its VETH to main lan.
-
In NodeRED, HTTPS needs to be enabled in it’s “settings.json” for NodeRED and point to the full path to the cert and key files for SSL. Creating certs is PITA, but totally needed here. NodeRED documents this here: https://nodered.org/docs/user-guide/runtime/securing-node-red … Self-signed certs might work IF the client devices connecting to Wi-Fi need to already trust a self-signed root (otherwise the captive portal will fail since certs if invalid/untrusted. Unlike a regular browser, the captive portal window does NOT let you just hit the it’s dangerous but “Continue Anyway” button).
-
I created a LE cert using certbot on a Mac with DNS validation, and copied them to the NodeRED directory (/data in my container case). In my case, I use Gandi plugin for DNS validation to a custom domain, but there are plug-in for most DNS providers (using nodered.example.link but replace the -d with a valid domain):
certbot certonly --authenticator dns-gandi --dns-gandi-credentials ./gandi.ini -d nodered.example.link --work-dir . --logs-dir . --config-dir .
- From NodeRED’s shell edit settings.json. I uncommented the “option 1” for HTTPS, and used the full path the files generated key/certs copied to from Mac to the NodeRED instance.
https: {
key: require("fs").readFileSync('/data/privkey.pem'),
cert: require("fs").readFileSync('/data/cert.pem')
},
- From NodeRED’s flow editor at :1880. Added an “http in” GET request for “/api”:
- In same flow, added a “template” and linked to the “http in” above, that contained the “status” to display from another NodeRED flow. I create another “http in” flow to test, but you should already have your status page… https:// part will come automatically from enable NodeRED for HTTPS as shown above
{
"captive": true,
"user-portal-url": "https://nodered.example.link:1880/status"
}
\
- Lastly, in the NodeRED flow editor, create an “http response”, make sure to “Content-Type” as “application/captive+json” as a header with 200 as return code & link that to the template above.
\
- Then “Deploy” the flow using the button in top right of NodeRED flow editor. As this point NodeRED will respond to a device’s RFC-8909 request… but the Mikrotik will need to use DHCP to send a device’s request for captive portal the above NodeRED flow.
RouterOS configuration
Assuming using VLAN-enable bridge and a new VLAN that does the “NodeRED status page captive portal redirect”, the following worked in my case (excluding unrelated configuration). In particular the Option 114 stuff is critical to link the above NodeRED:
# add DHCP Option 114 stuff...
/ip dhcp-server option add code=114 name=nodered value="'https://nodered.example.link:1880/api'"
/ip dhcp-server option sets add name=NODERED options=nodered
# using Virtual AP for testing...
/interface wifiwave2 add configuration.mode=ap .ssid=NodeRED disabled=nomaster-interface=wifi1 name=wifi3
# create new VLAN for the "NodeRED" SSID above...
/interface bridge [find] vlan-filtering=yes
/interface vlan add interface=bridge name=vlan114 vlan-id=114
/interface bridge port add bridge=bridge interface=wifi3 pvid=114
/interface bridge vlan add bridge=bridge tagged=bridge vlan-ids=114
/interface list member add interface=vlan114 list=LAN
/ip address add address=10.1.14.1/24 interface=vlan114 network=10.1.14.0
# now add a new DHCP server that uses the Option 114 that points to NodeRED
/ip pool add name=dhcp_pool2 ranges=10.1.14.2-10.1.14.254
/ip dhcp-server add address-pool=dhcp_pool2 dhcp-option-set=NODERED interface=vlan114 name=dhcp2
/ip dhcp-server network add address=10.1.14.1/24 dns-server=10.1.14.1 gateway=10.1.14.1
# Add static DNS to point to the NodeRED's IP address, that matches the DNS name used the HTTPS certificate
# Mikrotik DNS must used resolve the HTTPS name to the private NodeRED IP address, in my case that's 192.168.100.207
/ip dns set allow-remote-requests=yes
/ip dns static add address=192.168.100.207 name=nodered.example.link"
It took way longer to write this down than actually setting this up – but totally works at least on Apple devices when I connect to the “NodeRED” Wi-Fi SSID. Which uses JUST the Option 114, NO hotspot, NO proxy. Just HTTPS enabled in NodeRED using LE – with the above additional “NodeRED ‘flow’” that responds the /api HTTPS request to tell a Wi-Fi client to display the another “/status” page provided by same nodered instance.
I have no idea if works on Android, but both Mac and iPhone seem to work using roughly the above.
thanks!
. And, I was curious how well the Option 114 + “Captive Portal API” got triggered. It work surprising well actually, at least on Apple devices – this isn’t surprising given the RFC authors.
