upgrades and compatibility

This thread has been locked for further replies. You can start a new thread to share your ideas or ask questions.
This thread has been locked for further replies. You can start a new thread to share your ideas or ask questions.
upgrades and compatibility
upgrades and compatibility
2020-07-17 16:22:52 - last edited 2020-08-14 02:54:07
Model: EAP225
Hardware Version: V3
Firmware Version: 2.20

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.

1
1
#1
Options
1 Accepted Solution
Re:upgrades and compatibility-Solution
2020-07-18 09:28:15 - last edited 2020-08-14 02:54:07

 

nojak wrote

It's not an issue for me with my 6 EAPs, but if I had 100...

 

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.

༺ 0100 1101 0010 10ཏ1 0010 0110 1010 1110 ༻
Recommended Solution
2
2
#5
Options
5 Reply
Re:upgrades and compatibility
2020-07-17 18:37:19 - last edited 2020-07-17 18:47:13

@nojak 

 

The Upgrade is really easy. Before Upgrade you have to backup your current settings. Then you have to do the Controller-Upgrade and import the backuped settings. If the EAP225/245 have the old 2.7.0/2.4.0 Firmware, the new Controller-Software can detect and adopt the EAPs correctly, but the Controller shows a warning, because the 2.7.0/2.4.0 Firmware isn't optimal for the new Controller-Software. For this reason you have to upgrade the EAP225/245 Firmware as the last step.

0
0
#2
Options
Re:upgrades and compatibility
2020-07-18 00:06:54 - last edited 2020-07-18 00:10:39

 

nojak wrote

Either way, you need to upgrade multiple devices, or have your network split across multiple controllers.

 

Wrong. You can set up the SDN Controller, adopt the EAPs running old firmware in the new controller and then update the EAP's firmware device by device in SDN Controller. EAPs with old firmware will continue to run even if the old controller has been shut down or upgraded.

 

All you need for this scheme is the device password set in the old controller. If you did migrate your old site to the SDN Controller before adopting the EAPs, the device password has been set already in SDN Controller during restore of your site's settings.

༺ 0100 1101 0010 10ཏ1 0010 0110 1010 1110 ༻
0
0
#3
Options
Re:upgrades and compatibility
2020-07-18 02:00:02 - last edited 2020-07-18 02:01:08

@R1D2 yet the release notes say that 2.20 is needed, which means that older versions do not work. 
 

So if you are an enterprise with say 100 APs, using portal, logging and seamless roaming, all those continue to work with old EAP firmware and the new SDN controller?

 

I'm thinking of the use case where you did testing, everything seemed ok, you upgraded and then realized there is a problem. How easy to go back, with 100 EAP and a controller?

Should just be restore the old controller and you're good. Or just downgrade the EAPs if the issue turns out to be the EAP firmware, but keep the SDN controller. 
 

It's not an issue for me with my 6 EAPs, but if I had 100...

0
0
#4
Options
Re:upgrades and compatibility-Solution
2020-07-18 09:28:15 - last edited 2020-08-14 02:54:07

 

nojak wrote

It's not an issue for me with my 6 EAPs, but if I had 100...

 

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.

༺ 0100 1101 0010 10ཏ1 0010 0110 1010 1110 ༻
Recommended Solution
2
2
#5
Options
Re:upgrades and compatibility
2020-08-14 03:02:38

Dear @nojak,

 

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.

 

 

Thank you so much for your valued feedback and suggestion.

 

TP-Link persists in innovation and constantly update our products and technologies to better serve customers.

 

If you have any suggestions for us, please feel free to share your idea here. We are happy to receive all kinds of ideas from our customers.

 

Best regards!

New to the TP-Link Community? Getting Started from this thread: https://community.tp-link.com/en/business/forum/topic/551684
0
0
#6
Options