Portal timeout: devices do not get the portal
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!
- Copy Link
- Subscribe
- Bookmark
- Report Inappropriate Content
- Copy Link
- Report Inappropriate Content
Hello! I got around to do the update, starting from Raspi updating. (By the way, I said mine was version 10, but it was wrong: it's 11. I kept this version, didn't burn a new card) Now, everything went fine up to creating a new controller with the latest version, making it run, and uploading the old config file. No error message. However, the access points do not get adopted: it shows "adopting" forever, like 40min. I noticed that a few APs' started saying "adoption failed". So I stopped the new container and started the old one again. Could you tell what could be the cause? Should I update the APs first? (Currently 5.0.4 Build 20211021 Rel. 57494) Or could I have done something on the APs that prevents them from being adopted from another controller and I forgot about it, or so?
I will appreciate your advice!
- Copy Link
- Report Inappropriate Content
I'm pretty sure 3+ year old firmware won't be compatible with the latest 5.X Controllers. My suggestion is upgrade one of the APs, and see if it can be successfully adopted by your new controller instance. If so, then you have you answer :) and can do the rest.
- Copy Link
- Report Inappropriate Content
@d0ugmac1 Thank you for your suggestion! I tried: went back to the old one, updated one of the APs, saved the config file, stopped, started the new controller, uploaded the new config file. But it doesn't get adopted....
- Copy Link
- Report Inappropriate Content
Are you using 'bridge' or 'host' networking for the docker container? You need to open more ports between the container and the host for the later firmware versions. Alternatively, just run the Omada container with 'host' networking instead of the default of bridge. You'll now if the container self identifies with a 172.17.0.X address instead of the IP assigned the Pi itself.
https://www.tp-link.com/ca/support/faq/3281/
The key ones are the 298XX ports
- Copy Link
- Report Inappropriate Content
@d0ugmac1 Thanks a lot for your tips! I didn't know about "more ports". I just went ahead with following your example, created another container with "host". Now it works !!! Thanks a million !
- Copy Link
- Report Inappropriate Content
Information
Helpful: 0
Views: 1308
Replies: 16
Voters 0
No one has voted for it yet.