Portal timeout: devices do not get the portal
Portal timeout: devices do not get the portal
![](/avatar/default.png)
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!
- Copy Link
- Subscribe
- Bookmark
- Report Inappropriate Content
Upgrade firmware for the EAP245 and the controller:
https://www.tp-link.com/support/download/eap245/v3/#Firmware
Get the Latest Omada SDN Controller Releases Here - Subscribe for Updates
- Copy Link
- Report Inappropriate Content
Virgo's idea is a good one, 4.4 is pretty old for controllers (there's too many feature upgrades/bug fixes to read through to definitively see if a fix was made) but my Law of the Internet says basically 'You are not the first person to have this problem.' :)
- Copy Link
- Report Inappropriate Content
Yes, often you'll find that existing issues disappear after upgrading to the latest firmware, which firmware iteration fixes the problem, who knows? But upgrades deserve a try.
- Copy Link
- Report Inappropriate Content
@Virgo @d0ugmac1 thank you very much for your reply! I will have to wait till our tenants take off to update the controller, then.... perhaps after Easter.
As for updating of the controller, my controller is on Raspberry pi 4, I followed this instruction:
https://community.tp-link.com/en/business/forum/topic/261734
Would it be right if I do this:
1. save the config of the current one, then "stop" it on portainer
2. Install a new one exactly the same way. Upload the config. Check that everything works
3. delete the old one through portainer
?
Would it be also OK if I update EAP's first meanwhile ? That's a lot easier than updating the controller, takes just a few minutes, I don't have to wait till the people move out. But I'm a bit scared of updating the controller: I need time for it.
I am generally a bit worried about updating/upgrading because updating is where bad things happen with Unifi system. But if nobody suggests otherwise, I'm going to find a moment to update them.
Meanwhile, I decided to change the portal back to openNDS: I was using Omada Portal for a while because openNDS had some problem. But now the author of it fixed it and running stable on my other router (where Unifi APs' are), so I went back to it. Omada Portal doesn't have "idle out", so people will be kicked out after authentication time out, possibly in the middle of doing something. But with "idle time out" feature which openNDS has, if a device is off-line for a certain length of time (you can set how long), it will have to log in again when they come back on-line, thus resetting the authentication time, so unlikely to be interrupted, as long as auth-time-out is long enough (I set it 24h). Perhaps it's a feature to be considered for Omada-Portal as well ? Or perhaps already implemented?
- Copy Link
- Report Inappropriate Content
- Copy Link
- Report Inappropriate Content
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)
- Copy Link
- Report Inappropriate Content
@d0ugmac1 and Virgo
thank you for your replies! I think the link from Virgo is yet another method, not on a container like I have mine. I guess I will stick with it. @d0ugmac1 I guess you are right about updating of the Controller not being so scary: it's just that I've installed it about 1.5 years ago, and since then I haven't done anything, forgot everything, didn't even remember the port number of the portainer !! The fact that I didn't have to do anything is a good thing, though: there was simply no issue that was obviously because of the controller.
But yes, especially since I don't run the portal over the controller anymore, I shouldn't worry much about making a big time window, beyond the time needed for the APs to get adopted to the new controller. I can do your 1+2 at my convenient time, and for 3-5 I should perhaps get up at 4am to do it to have 1 hour.... something like that. Right?
In fact I've done something like this for Unifi, in fact many times, it should go the same.... but that's also a long time ago, I've forgotten.....
As for installation of the newer version, am I right that the instruction here:
https://community.tp-link.com/en/business/forum/topic/261734
is still valid, in terms of port numbers to enter, paths, etc?
And as for
@d0ugmac1 I run my Controller with host networking, if you use bridging
I don't know what I'm using (in other words, I don't know what a "host networking" is, nor "bridging") How can I tell ?
And, speaking of updating, I actually haven't updated raspi OS or anything on it. I just let Omada run on it, and a script for water-sensor in case of flood in the basement. Otherwise I don't do anything on that Raspi. Should I update the raspi OS, too?
- Copy Link
- Report Inappropriate Content
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.
- Copy Link
- Report Inappropriate Content
@d0ugmac1 wow, thanks a lot for detailed answers !!! I really appreciate it a lot!.
As for a backup for raspi, I do have one for each Raspi (one for Omada, one for Unifi). I am afraid of accidental power cycling (e.g. due to power outage) that might kill the card, and also it might die for whatever reason. I got a few of the high-end ones that were recommended back then, which are supposed not to die easily (Samsung endurance pro, and another similar one.). But if you recommend me some, that would be nice. I don't know what exactly "industry-grade" SD cards are.
I also have one spare raspi: it used to be a router (with openwrt), but I decided not to use raspi as a router. So that can be used as a replacement if something happens.
Do you know how to clone an SD card while running ? Or else, how do you clone fast? It takes hours using my laptop. (Macbook pro mid 2012: upgraded.)
As for the network, now I found it: mine is bridge. I think it was default. If "host networking" is so much easier, why isn't everybody using host networking? Is there any disadvantage to it?
Now, I think i found one maybe-answer to it on my own..... my Unifi controller is apparently "host networking": it doesn't show the IP. Whenever Raspi restarts, there is a weird competition of port with java. I have to kill the PID of java a few times till Unifi runs. Now I don't restart Raspi at all, so I don't have to worry much (I used to have a shut-off button installed, but the button was too sensitive/unstable, when I'm doing something else near by or move the raspi a bit, it shuts it off! So I uninstalled it), but perhaps it's related to the fact that it's host networking.....
I guess I will stay with bridge, since it's been working totally fine with omada.
And
@d0ugmac1 type magic should
What is a "type magic" ?
- Copy Link
- Report Inappropriate Content
Those two commands are the way I updated my Armbian OS, done as root, hence the # prompt. Should be very similar for Raspian.
- Copy Link
- Report Inappropriate Content
![](/avatar/default.png)
Information
Helpful: 0
Views: 1018
Replies: 16
Voters 0
No one has voted for it yet.