u/fraughtication

Just had another saving session email ping through for anyone who's interested - keep an eye out in your inbox.

I could really get used to these daily saving sessions, even on rainy and overcast days like today it means I'm easily crossing into net profit thanks to PV and a battery, and the grid benefits too.

It appears the Blue Iris front-end and back-end are down today.

The website returns a "error establishing a database connection" and the software can't seem to connect to the back-end.

Edit: Back online, latest software downloads check out fine with Virus Total and Metadefender.

I have a fairly well established Omada SDN system with an ER7206 V2.2 as the gateway connected to the latest version of the Omada controller on Windows.

I've noticed that the DPI/ Application Analytics function has stopped working after working fine previously, with nothing displayed on the analytics insights page or anywhere else in the web GUI or Android app. It simply says "no categories selected" (and there're no categories to select).

I've checked the Omada controller - it's got application control and traffic logging enabled.

I've checked Windows Firewall and Omada is configured as required, and verified via netstat that TCP 29815 is both listening on the controller and established to the gateway.

I've checked client data logging is on in the controller.

I've confirmed hardware offload is disabled on the gateway.

IDS/ IPS is enabled and working fine.

I've rebooted the gateway and controller to no avail.

As far as I know, every other function is working fine.

Has anyone experienced similar and solved this issue?

I'm not sure if I've seen this before on the Tapo P1xx series sockets, I don't remember them cycling the output before, it certainly come as a surprise when I updated this time around.

​

Before last week, I'd used Google Authenticator as my TOTP authentication app for probably over a decade, it has served me well, doing what it needed to do, with ≈ 40 codes in there.

As, for a good while, it didn't have a backup capability, I'd always replicated it onto a spare phone I had, exporting codes periodically to the spare phone so I always had two copies - which served me well until it didn't.

Last week I was doing a periodic export of my codes from my phone to the backup phone, for some reason it wasn't working, so I had to try a few times. One of those times, I hit "import" on my main phone, and all my TOTP codes disappeared. After already wiping the codes from my backup phone for re-importing.

I genuinely felt a cold sweat wash over me, a desperate close and re-open of the app, a switch of the profile from my Google account back to local only, a phone restart - nothing brought those codes back.

So began the long night of recovery.

My password manager was the twitchiest one - locking myself out of this with an incorrect master password entry or one too many biometric attempts would have been a disaster as I wouldn't be able to authenticate back in, thankfully I was able to export my vault via the logged in app on my phone, so I exported my vault after checking my master password a dozen thousand times, fortunately that worked fine, I then deleted and re-created my password manager.

Luckily, my main Microsoft and Google accounts were easily recoverable as I was logged in on my phone and could authorise into re-enrolling a new authenticator app, which I thought would be the worst ones to recover. Every other online account I could recover fairly easily with an e-mail to the support desk of the company the account was related to.

The big ones left were then my self hosted services mainly my Omada SDN controller, Uptime Kuma and Home Assistant.

Thankfully I was logged into Home Assistant on my phone and could simply remove and enable MFA via the Companion app, no issue there.

Uptime Kuma was a bit trickier but thankfully had MFA reset via the SQL database documented online.

Omada was the big one - my entire network setup and configuration worked on over years, my VPN profiles, my IP and MAC bindings, ACLs, VLANs. I was told by TP Link support this was not possible, but I wasn't going to let that stop me.

After prying through the MongoDB database for my SDN controller I was able to find the MFA flags and set them to false, and voila, I was able to login again, after holding my breath for about twenty minutes.

I'm now happily using Aegis with a proper backup plan in place for my TOTP codes, I've got multiple break glass arrangements, digital and physical, and hopefully never have to go through that stress again!

So, overall, what did I learn:

• Mainly, I got far too complacent with a janky setup.

• Don't ignore websites or apps when they tell you to save backup access tokens.

• Don't rely on shaky backup methods like exporting codes every now and then.

• Prepare for the worst and test it.

• Have break glass accounts or plans, physical and digital, in case the worst happens.

• Google Authenticator is out of the window, I continued to use it because I was invested in it with 40+ TOTP codes, but the no (offline) backup was really terrible.

• Just change from Google Authenticator now, don't wait for a disaster (unless you use Google account backup).

• I got lucky with still having access to my phone - if the reason I didn't have access to my devices were because they were melted lumps in a house fire I'd be completely done for.

Before last week, I'd used Google Authenticator as my TOTP authentication app for probably over a decade, it has served me well, doing what it needed to do, with ≈ 40 codes in there.

As, for a good while, it didn't have a backup capability, I'd always replicated it onto a spare phone I had, exporting codes periodically to the spare phone so I always had two copies - which served me well until it didn't.

Last week I was doing a periodic export of my codes from my phone to the backup phone, for some reason it wasn't working, so I had to try a few times. One of those times, I hit "import" on my main phone, and all my TOTP codes disappeared. After already wiping the codes from my backup phone for re-importing.

I genuinely felt a cold sweat wash over me, a desperate close and re-open of the app, a switch of the profile from my Google account back to local only, a phone restart - nothing brought those codes back.

So began the long night of recovery.

My password manager was the twitchiest one - locking myself out of this with an incorrect master password entry or one too many biometric attempts would have been a disaster as I wouldn't be able to authenticate back in, thankfully I was able to export my vault via the logged in app on my phone, so I exported my vault after checking my master password a dozen thousand times, fortunately that worked fine, I then deleted and re-created my password manager.

Luckily, my main Microsoft and Google accounts were easily recoverable as I was logged in on my phone and could authorise into re-enrolling a new authenticator app, which I thought would be the worst ones to recover. Every other online account I could recover fairly easily with an e-mail to the support desk of the company the account was related to.

The big ones left were then my self hosted services mainly my Omada SDN controller, Uptime Kuma and Home Assistant.

Thankfully I was logged into Home Assistant on my phone and could simply remove and enable MFA via the Companion app, no issue there.

Uptime Kuma was a bit trickier but thankfully had MFA reset via the SQL database documented online.

Omada was the big one - my entire network setup and configuration worked on over years, my VPN profiles, my IP and MAC bindings, ACLs, VLANs. I was told by TP Link support this was not possible, but I wasn't going to let that stop me.

After prying through the MongoDB database for my SDN controller I was able to find the MFA flags and set them to false, and voila, I was able to login again, after holding my breath for about twenty minutes.

I'm now happily using Aegis with a proper backup plan in place for my TOTP codes, I've got multiple break glass arrangements, digital and physical, and hopefully never have to go through that stress again!

So, overall, what did I learn:

• Mainly, I got far too complacent with a janky setup.

• Don't ignore websites or apps when they tell you to save backup access tokens.

• Don't rely on shaky backup methods like exporting codes every now and then.

• Prepare for the worst and test it.

• Have break glass accounts or plans, physical and digital, in case the worst happens.

• Google Authenticator is out of the window, I continued to use it because I was invested in it with 40+ TOTP codes, but the no (offline) backup was really terrible.

• Just change from Google Authenticator now, don't wait for a disaster (unless you use Google account backup).

• I got lucky with still having access to my phone - if the reason I didn't have access to my devices were because they were melted lumps in a house fire I'd be completely done for.

Recently I had a disaster where both my primary and backup TOTP authentication methods were lost; the wave of cold chills that washed over me when I saw a blank Authenticator display was one thing, but not as much as the sinking feeling of potentially having to start from scratch with my Omada setup!

Fortunately, I discovered a self-recovery method where you can disable MFA on your Omada SDN deployment through editing the MongoDB database.

Omada SDN Controller (for Windows at least) stores MFA settings across multiple collections in its bundled MongoDB instance, simply disabling MFA in one place isn't enough, you need to clear it in three separate places, as shown below.

Prerequisites

• Physical or RDP access to the Windows machine running Omada Controller.

• Administrator access on Windows.

• Omada Controller must be running for MongoDB to be accessible.

The Process

Step 1 - Open Command Prompt as an Administrator.

Step 2 - Navigate to Omada's MongoDB bin folder in the command prompt.

cd "C:\Program Files\Omada\bin"

Step 3 - Connect to MongoDB.

mongo.exe --port 27217

You should see the MongoDB shell prompt, if you get "connection refused", make sure the Omada Controller service is running first, or try again.

Step 4 - Switch to the Omada database.

use omada

Step 5 - Disable MFA in three locations for site, global and user configurations:

db.tenant.updateMany({},{$set:{enable\_mfa:false}})

db.identityaccessomadac.updateMany({},{$set:{mfa_enable:false}})

db.globalsetting.updateMany({},{$set:{mfa_enable:false}})

Each command should return "modifiedCount" : 1 or more confirming it worked.

Step 6 - Restart the Omada Controller service.

Step 7 - Log in.

You should now be able to log in with just your username and password, with no TOTP prompt.

Step 8 - Re-enable MFA for the site, global and user (strongly recommended) - site and global are configuration toggles in the Omada SDN interface, user is re-enabled by enrolling your account into MFA via an authenticator app.

Hopefully this saves anyone else who ends up in the situation I was in.

Security/ responsible disclosure disclaimer:

I don't believe this represents a vulnerability for the following reasons:

• Local admin access is required.

• MongoDB without authentication is a known and documented behaviour in many bundled database deployments.

• I believe MFA on Omada is designed to protect the web interface from remote attackers, not from someone with local admin access to the underlying server.

• This is a recovery procedure for legitimate system owners.

If anyone from TP-Link disagrees with this assessment, I'm happy to discuss. I attempted to obtain official recovery guidance from TP-Link support before pursuing this approach and was told they could not advise.

​

Recently I had a disaster where both my primary and backup TOTP authentication methods were lost; the wave of cold chills that washed over me when I saw a blank Authenticator display was one thing, but not as much as the sinking feeling of potentially having to start from scratch with my Omada setup!

Fortunately, I discovered a self-recovery method where you can disable MFA on your Omada SDN deployment through editing the MongoDB database.

Omada SDN Controller (for Windows at least) stores MFA settings across multiple collections in its bundled MongoDB instance, simply disabling MFA in one place isn't enough, you need to clear it in three separate places, as shown below.

Prerequisites

• Physical or RDP access to the Windows machine running Omada Controller.

• Administrator access on Windows.

• Omada Controller must be running for MongoDB to be accessible.

The Process

Step 1 - Open Command Prompt as an Administrator.

Step 2 - Navigate to Omada's MongoDB bin folder in the command prompt.

cd "C:\Program Files\Omada\bin"

Step 3 - Connect to MongoDB.

mongo.exe --port 27217

You should see the MongoDB shell prompt, if you get "connection refused", make sure the Omada Controller service is running first, or try again.

Step 4 - Switch to the Omada database.

use omada

Step 5 - Disable MFA in three locations for site, global and user configurations:

db.tenant.updateMany({},{$set:{enable_mfa:false}})

db.identityaccessomadac.updateMany({},{$set:{mfa_enable:false}})

db.globalsetting.updateMany({},{$set:{mfa_enable:false}})

Each command should return "modifiedCount" : 1 or more confirming it worked.

Step 6 - Restart the Omada Controller service.

Step 7 - Log in.

You should now be able to log in with just your username and password, with no TOTP prompt.

Step 8 - Re-enable MFA for the site, global and user (strongly recommended) - site and global are configuration toggles in the Omada SDN interface, user is re-enabled by enrolling your account into MFA via an authenticator app.

Hopefully this saves anyone else who ends up in the situation I was in.

Security/ responsible disclosure disclaimer:

I don't believe this represents a vulnerability for the following reasons:

• Local admin access is required.

• MongoDB without authentication is a known and documented behaviour in many bundled database deployments.

• I believe MFA on Omada is designed to protect the web interface from remote attackers, not from someone with local admin access to the underlying server.

• This is a recovery procedure for legitimate system owners.

If anyone from TP-Link disagrees with this assessment, I'm happy to discuss. I attempted to obtain official recovery guidance from TP-Link support before pursuing this approach and was told they could not advise.