We are using a local instance of IC2 to control a bunch of Max Transits. Our IC2 has no internet connectivity. Connectivity between IC2 and Max Transit units is also heavily firewalled.
We want to upgrade our Max Transit units (through IC2) so all are running the same (latest) version. Currently they are running everything from 7.0.0 through 8.0.1.
I found How to Better Manage Firmware Updates, but it only shows uploading to individual units. Upgrading Firmware - The InControl2 Method shows device level and claims equal steps should work for Organisation or group level. It does not. On those levels I simply do not have any Firmware Management option but rather a Firmware Policy option that does not appear to allow any upload.
Secondly, this seems to only allow linking to firmware through a http link? Is there a solution for our non-connected IC2?
So my questions:
How do I upload a new firmware to our IC2 instance so it can upgrade the connected Max Transit units?
in order to allow this specific traffic, what protocol/ports would be used between IC2 and Max Transits to upgrade?
You then need to save the firmware file(s) to an internal web server. Once the file(s) are accessible internally (without your InControl instance needing to have internet access), you can then “point” your InControl to the appropriate internal URL’s for the firmware updates. The screen shots below are taken from Group Level Firmware Policy:-
When this is applied, your InControl instance will tell your Max Transits to upgrade using the same URL - therefore, to answer your second question, the Transits must be able to access the file in the URL link. InControl is just telling the transit where the file is.
Weird upgrade process if you ask me. Why isn’t there a local upload features and have the Max Transits download its firmware from the IC2 server, just like they do with their config?
So if anyone from peplink reads this; I would love the explanation for this.
I guess I will be upgrading my units one by one for now.
Let’s call the local instance of InControl as ICA, and the Peplink’s hosted InControl as IC2. ICA share the same code as the IC2. IC2 was released earlier than ICA.
By design, we decoupled the hosting of firmware files from IC2 to a download site. The design could offload the “file server” role to an external download site. It also allows users to upload firmware files to their own device-accessible local web server. Devices would download the files locally instead of our download site on the Internet. This will not only save bandwidth but also make downloads faster.
The design may be less useful for ICA installations because ICAs may already be local to the devices. We may enhance this area in future releases. For the time being, to manage firmware on IC2, I suggest you host firmware files on a local webserver.
Hi @Michael, thank you for the clarification.
I guess our setup is not immediately typical as our Max Transits do not have internet access from their semi-private 4G network. And on the other end their access is also considered non-secure so they only have access to ICA.
I guess I will upgrading one by one or get them access to download the firmware elsewhere.
We changed permission here and there and have set up the firmware on a server which the Max Transits should be able to reach.
We have allowed access from Max Transits to http://dwnldsrvip/firmware.bin.
When setting this link in ICA however we immediately get an “Error: Download firmware failed.”. If we enter a bogus ip address this verification seems to take a lot longer before ending with the same error.
Is there a log where we can see why the download failed? Did it time out? Was the file corrupt?Is ICA unable to reach the download server? Or is it the Transit Max that can’t reach it?
That is what I understood, but we are currently stuck on setting the download url in ICA. It wants to verify the download link before allowing to save it.
So this verification is what exactly? ICA trying to reach the link itself? Seems most logical (but again not really with an ICA setup without internet as it is the routers that need to be able to reach this link, not ICA itself).
That said, our ICA is in the same subnet as the download server with no firewall policies anywhere. So why it would be failing is a unclear.
mm, that option (after clicking Add firmware for multiple products) greys out the page and pops up a single line for me. Tried with both Chrome and Internet Explorer.
When you click the “verify link”, the ICA will attempt to download the firmware from the URL and read its header in order to identify whether the firmware corresponds to the product model you are defining for. If your ICA cannot reach the URL, you will get an error. That means the firmware URL will have to be accessible by both the ICA and the devices.
