upgrades and compatibility
This thread has been locked for further replies. You can start a new thread to share your ideas or ask questions.
TP-Link could have made the upgrade process better.
Referring to Omada Controller and EAP225/245.
Omada Software Controller 3.2 does not work with EAP firmware 2.20.
Omada SDN Controller 4.1 requires EAP firmware 2.20.
This means that a user cannot just upgrade one part of their system and maintain compatibility, which is generally how you want to perform upgrades.
If you upgrade an EAP to 2.20, you need to have the new SDN controller running for that EAP.
If you upgrade the controller to 4.1, you need to upgrade EAPs to 2.20.
Either way, you need to upgrade multiple devices, or have your network split across multiple controllers. Less of a concern for a home user, but in a larger enterprise deployment that relies upon portal, logging, accounting and seamless roaming, this is very suboptimal. In $dayjob, we (and our competitors) would pushback on $vendor and make them fix it, though they all seem to know better anyway.
I would encourage TP-Link to not repeat this mistake in the future. Have an easier upgrade path that allows users a more seamless upgrade, particularly your larger enterprise customers, a segment I am sure you want to grow.
I will have even more than 100 EAPs to update (~ 175) for our customers, almost all sites with slightly different setups. So I have to define, prepare and test an upgrade path which will minimize downtime, even though we always upgrade firmwares at 03:30 in the morning.
Since I did test it before, there is not much which can go wrong. But if it does, we have a plan B even for cases where the power supply fails during an upgrade (in the past we already had such a seldom case with one customer, where an OC200 was bricked b/c of a power failure during a remotely initiated firmware upgrade). That's the reason why we won't upgrade EAPs before the SDN controller is up and running. If the OC200 gets bricked due a power failure, the customer gets a new one at the same day.
So the way to go is to first migrate existing controller settings to the new SDN Controller and to manually set up the features which can't be migrated automatically as listed in the Upgrade Guide.
Next, the EAPs running old firmware versions show up as »Connected« in the new SDN Controller. If you choose to set up the SDN Controller's configuration from the very beginning, EAPs need to be adopted in the SDN Controller. In this case make note of the device account set in the old controller (or set it back to »admin/admin« before shutting down the old controller or hard-reset the EAPs to factory defaults).
I show the procedure for one EAP here, but you will see later – when upgrading its firmware – that it can be done in a batch job, too.
First, the EAP will show up in the SDN controller either as »Connected« (if the old controller has been migrated) or as »Pending« (if the SDN Controller's configuration has been manually set up from the beginning). Note the firmware version of the EAP:
If the EAP appears to be »Pending«, adopt it. SDN Controller informs you that the EAP needs an upgrade in order to become manageable in SDN Controller. It does not say that you can't upgrade the firmware (it says quite the opposite), but it informs that you cannot fully manage the EAP (yet):
Next, upgrade all EAP's firmwares in batch mode. Don't mind the firmware filename, we have our own nomenclature for firmware file names, which is a bit more uniform compared to the original names used by TP-Link:
If the upgrade did succeed:
the EAP is being configured by SDN controller. Note the new firmware version:
If something goes wrong, it's possible to downgrade the whole hotspot system by just reversing the steps shown above.
It's very thoughtful of you to be concerned about the approach of companies needing to update 100+ EAPs, but then you should have at least gone once through the most easy upgrade path with the shortest downtime before complaining about the upgrade process being too complex.
You are right when you say that the timing of the release of firmware versions appeared somewhat uncoordinated, but it affected only early bird adopters who are typically not found in companies and who had been somewhat impatient IMO. As a company we will even wait for the next SDN Controller version to be released before rolling out SDN Controller to our customers.
No offense intended, but please don't make a drama out of the upgrade path. In my opinion TP-Link has implemented this very well.
I will have even more than 100 EAPs to update (~ 175) for our customers, almost all sites with slightly different setups. So I have to define, prepare and test an upgrade path which will minimize downtime, even though we always upgrade firmwares at 03:30 in the morning.
Since I did test it before, there is not much which can go wrong. But if it does, we have a plan B even for cases where the power supply fails during an upgrade (in the past we already had such a seldom case with one customer, where an OC200 was bricked b/c of a power failure during a remotely initiated firmware upgrade). That's the reason why we won't upgrade EAPs before the SDN controller is up and running. If the OC200 gets bricked due a power failure, the customer gets a new one at the same day.
So the way to go is to first migrate existing controller settings to the new SDN Controller and to manually set up the features which can't be migrated automatically as listed in the Upgrade Guide.
Next, the EAPs running old firmware versions show up as »Connected« in the new SDN Controller. If you choose to set up the SDN Controller's configuration from the very beginning, EAPs need to be adopted in the SDN Controller. In this case make note of the device account set in the old controller (or set it back to »admin/admin« before shutting down the old controller or hard-reset the EAPs to factory defaults).
I show the procedure for one EAP here, but you will see later – when upgrading its firmware – that it can be done in a batch job, too.
First, the EAP will show up in the SDN controller either as »Connected« (if the old controller has been migrated) or as »Pending« (if the SDN Controller's configuration has been manually set up from the beginning). Note the firmware version of the EAP:
If the EAP appears to be »Pending«, adopt it. SDN Controller informs you that the EAP needs an upgrade in order to become manageable in SDN Controller. It does not say that you can't upgrade the firmware (it says quite the opposite), but it informs that you cannot fully manage the EAP (yet):
Next, upgrade all EAP's firmwares in batch mode. Don't mind the firmware filename, we have our own nomenclature for firmware file names, which is a bit more uniform compared to the original names used by TP-Link:
If the upgrade did succeed:
the EAP is being configured by SDN controller. Note the new firmware version:
If something goes wrong, it's possible to downgrade the whole hotspot system by just reversing the steps shown above.
It's very thoughtful of you to be concerned about the approach of companies needing to update 100+ EAPs, but then you should have at least gone once through the most easy upgrade path with the shortest downtime before complaining about the upgrade process being too complex.
You are right when you say that the timing of the release of firmware versions appeared somewhat uncoordinated, but it affected only early bird adopters who are typically not found in companies and who had been somewhat impatient IMO. As a company we will even wait for the next SDN Controller version to be released before rolling out SDN Controller to our customers.
No offense intended, but please don't make a drama out of the upgrade path. In my opinion TP-Link has implemented this very well.
