OC200 firmware update 1.32.6 broke internet access on 2 sites
Yesterday I updated my OC200 V1 controller which manages 4 sites from the previously released FW 1.31.3 to 1.32.6 to see if it solved the issue of not being able to update devices on remote sites behind an omada router. I did this while on one of the a remote site. This FW includes support for new omada routers, among other major changes.
There are a total of 4 sites on this OC200:
Local OC200 Site: ISP (bridged) router - Omada Router ER7206 v2.0 (PPPoE)
Remote Site 1: ISP (bridged) router - Omada Router ER605 v2.0 (PPPoE)
Remote Site 2: ISP (unbridgerable) router - Omada Router TL-R605 v1.0 (DynamicIP)
Remote Site 3: ISP (unbridgerable) router (no omada router)
This update caused both Local and remote site 1 to lose connection to internet upon OC200 reboot. After about 4 hours tinkering back and forth between these 2 sites (less than 1 km appart) I was unable to get either site back online, including a few whole system ISP + omada routers + controller reboots.
I also downgraded to FW 1.31.3 which factroy resets the OC200 and used that mornings automatic daily USB config backup file to restore the controller. Still no internet connection (PPPoE dialing fails).
To end the internet blackout I had to unbridge the routers and leave omada routers connected with DynamicIP and unmilitarize the omada router IP.
Today I compared omada router PPPoE config with a 5th site that has the same ISP bridged router as the 2 failed sites but managed by an OC300 controller. The only difference was the "802.1Q Tag" option was enabled on the no-longer working routers while it is disabled on this 5th site. So I disabled this option on the Local OC200 Site, unbridged the ISP router and everything was back no tormal. This was still on the downgraded FW 1.31.3.
To try and reproduce the error I upgraded OC200 again to FW 1.32.6, but the "802.1Q Tag" did not reactivate.
So there are a few questions that arise:
Could the OC200 FW update activate the "802.1Q Tag" option on both routers?
In that case, why did the FW downgrade + config restore keep this option activated? I'm not 100% sure that it wasn't activated before the original FW update.
If it did, why didn't the same thing happen the 2nd time around?
I'm posting this mainly so if someone else has the same problem they can quickly fix it, but also so TP-Link takes a look into the issue, as the .cfg settings backup file is not plain text.