Portal timeout: devices do not get the portal
Hello! I have several EAP245s and Raspberry Pi 4B (2GB) as Omada Controller (4.4.6). I have a guest-net with "click and go" authentication (i.e. "no authentication".) I used to set the timeout to be 3 days. But then realized that iPhones are not getting the portal automatically when it expires. Then I learned that iPhones deactivate Captive Portal Detect when the device is on a certain wifi network for certain length of time, like about 24 hours. It has to be asked for login every 24 hours. I posted the hint on the wall that one should try to access h t t p : / / n e v e r s s l . c o m (I spaced out this way because otherwise I can't post!) in case the portal doesn't come up automatically. It does work on iPhones, but the problem is nobody reads it ! So I decided to make timeout to be 20 hours. That was yesterday.
Then today, several other devices got a problem with getting back on-line again, and this time it's worse: n e v e r s s l . c o m doesn't work either. Since they were in a meeting, I didn't want to check each device, I authenticated them manually on the controller, but one android still couldn't get back on-line. As he restarted the device, it worked.
I don't want them to have to restart the device to get going upon auth-timeout. What is the best practice of this matter? For now I changed the expiration to 20 days, because now I know that this way, the problem is only with iPhones, and n e v e r s s l . c o m does work 100% on them. Could anyone also explain to me what might restarting of android have done?
I would appreciate your hints!
Actually the Controller is less scary than updating the APs IMHO.
I recently went through this on my PI-clone controller platform, which also leverages Portainer, and also runs containers for PiHole and Wireguard.
Here is a time when one can really appreciate the magic of containers...
1. In existing controller, go into Maintenance and pull a full backup to a local file, tick the Preserve Users, and I went for 365 days of backup. This will take a few minutes to process and upload to your computer.
2. In Portainer, pull the latest image version of mbentley's Omada Controller for your architecture (arm7?). This will take a few minutes.
Full disclosure, I run my Controller with host networking, if you use bridging, then follow whatever steps you used the first time around
3. Stop your current Omada container ( I have to do this at this point to avoid port contention). This will only impact meshed devices if they need to re-organize or if you are using captive portals etc.
4. Start up the new (5.13?) container, and use the Portainer 'Logs' function to keep an eye on progress. It will take 5-10 minutes to build a working Omada environment. You'll know this because you'll start to see discovery logs from your devices with a 'Managed by others.' type message.
5. Point your webrowser at your new controller IP and create the admin account and password, and also cloud connect at this time if you use that feature/have a TPlink account. As soon as you complete those 2 section, clicking Next will ask if you want to setup as "new" or "from backup". Select backup, and point to the file you saved from Step 1. This can take a much longer time to process...upwards of 30min for my system.
There may be a few short outages as the new controller re-provisions your devices (shorter than an upgrade outage). But everything should stabilize within 5min.
6. Immediately make a backup of your new controller via Maintenance. Reason is I've seen the new controllers use different device admin passwords than the old one, so at a minimum, you want to be able to restore and discover what that password was so you can revert to an older controller if needed.
If anything goes wrong with the creating the new controller, simply shut the new controller container down and start up your old controller container.
(apparently I have already deleted my old containers)
Whole lotta questions in there :)
Ok. Since you seem to have a mission critical system AND you are running your controller on a Pi I'm going to suggest you basically start from scratch with a fresh industrial grade SD card (16 or 32GB should be plenty). The reason for this is that those SD card do die and when they do, it ain't pretty (ask me how I know). Sidebar, always keep a backup file, spare SD card and the current controller's admin device account info handy for this (catastrophic) event. I actually have an entire pre-built system in a drawer in case something goes wrong, a bit flips and the Pi doesn't boot anymore.
Ok, back to your questions
The instructions you posted seem reasonable, I didn't go through with a fine toothed comb, but they should work but you will have to add 29814 in to the mix. See here for more details for v5.x. https://www.tp-link.com/us/support/faq/3265/
Bridging vs Host. If you look at the screengrab above of my Portainer (port 9000 fyi :) you'll see all the other containers have an IP that starts with 172.X... and my mbentley controller image just has a dash. What that means is I do not have to map each port used on my controller to the host device os...if the controller wants port 8043, it just takes it. You can see it here too:
Lastly I would absolutely update the Raspian OS (I used Armbian for my platform) before doing anything else, a little
#apt-get update
#apt upgrade
type magic should do it.