I was talking with a friend asking how to upgrade AP firmware and we noticed the only difference was that he was signed into Omada cloud and I was not. As soon as I signed I was able to trigger updates for the firmware on all my APs. Is this a requirement for this feature or is there another way to enable it?
Posted Dec 14, 2021, 8:43 AM UTC
I have the same question, for auto-updates it requires you to login.
Seems to be. I have had auto-update enabled the entire time but not Cloud and I noticed my devices haven't been updated at all this year.
I recently turned off cloud access b/c of log4j concerns and I noticed that the "check for updates" feature is also unavailable. So even if you are content with manually updating things you have to manually find and download the firmware to update.
Regarding log4j, I use this docker container which has already patched the vulnerability: https://github.com/mbentley/docker-omada-controller
I guess I’ll just manually turn on and off cloud access when I need to easily update :/
How did you manage to update the image? I use that on my pi and I'm deathly afraid to try to update the container out of fear of breaking omada.
As long as you aren’t using a dynamic volume you should be fine, but probably best to ensure you have a backup of your data before messing with it.
My systemd config looks like this
[Unit]
Description=Omada Controller Service
After=docker.service
Requires=docker.service
[Service]
TimeoutStartSec=0
Restart=always
User=omada
ExecStartPre=/usr/bin/docker pull mbentley/omada-controller:4.4
ExecStart=/usr/bin/docker run --rm \
--name omada-controller \
--net host \
-e MANAGE_HTTP_PORT=9088 \
-e MANAGE_HTTPS_PORT=9043 \
-e PORTAL_HTTP_PORT=9088 \
-e PORTAL_HTTPS_PORT=9843 \
-e SHOW_SERVER_LOGS=true \
-e SHOW_MONGODB_LOGS=false \
-e TZ=Etc/PST \
-v omada-data:/opt/tplink/EAPController/data \
-v omada-work:/opt/tplink/EAPController/work \
-v omada-logs:/opt/tplink/EAPController/logs \
mbentley/omada-controller:4.4
ExecStop=-/usr/bin/docker stop omada-controller
[Install]
WantedBy=multi-user.target
So I just updated it to use the latest version then ran systemctl daemon-reload && service omadac restart
FYI, I don't make any breaking changes within a given tag. So if you're on the 3.2 tag, you can be assured that unless there is some sort of of software update that is out of my control, I will not change any default behaviors on that version; only possibly add new features (if warranted) so it is safe to regularly pull the image and cycle the container as u/programstuff is doing. I would strongly recommend it, actually.
I do daily builds but with buildx image caching, the only changes that will occur would be if there is an actual change to the base image or an actual update in the repo.
You are awesome
I love your container setup, it's TP link I don't trust lol. I've nuked my network more than once with this controller my wife won't even touch the internet when I announce an upgrade lol. But I will say since switching to your container stability has been great, except when the pi randomly locks up, that's not on you tho that's a hardware problem on my end I'm troubleshooting. For something so integrated into my network I may just pick up an oc300 and not have to mess with it anymore. I'm reaching a point in my life where the desire to tinker is waning, and being replaced by ole dogs and grand kids lol.
I can only guess about the reasoning, but... those who choose not to connect to the Omada cloud likely don't want their network "phoning home" for any reason, to keep it isolated. Or you don't want TP-Link keeping an inventory of your devices, etc. Enabling auto-updates would immediately break this gap you've created, as your network is now auto-communicating with the cloud just for updates. So some would argue that this is functionally no different than just keeping yourself logged into the cloud anyway.
I know it's not exactly the same thing (like access to your network from outside), but that is likely their reasoning.
I’m much more ok with an outgoing api call being made to check if firmware is out of date compared to enabling full remote access to my controller and network.
My assumption is this is more of a business reason ($$).