u/Zestyclose_Jacket924

ASUS GT-BE98 Pro SSH suddenly rejects known-good admin password after scheduled reboot
Router: ASUS GT-BE98 Pro
Firmware: 3.0.0.6.102_39262 — stock ASUS firmware
Operation mode: Router Mode
LAN: 192.168.1.1/24
Admin account: BE98admin

The router is approximately two months old. SSH has worked normally since initial configuration. The router has one administrator account, and the same administrator credentials have successfully been used for the WebUI, SSH, and Telnet. The username/password have not been changed.
After a scheduled router reboot, SSH authentication suddenly stopped working. The same username/password still successfully authenticates to both the ASUS WebUI and Telnet, but SSH rejects the password with:
Permission denied, please try again.
SSH is configured:
Enable SSH: LAN only
Port: 22
Allow Password Login: Yes
Dropbear is running and listening normally:
0.0.0.0:22 LISTEN dropbear
:::22 LISTEN dropbear
The administrator account exists normally:
BE98admin:x:0:0:BE98admin:/root:/bin/sh
NVRAM also reports:
sshd_pass=1
sshd_port=22
During troubleshooting, repeated failed SSH authentication attempts caused ASUS to dynamically insert this rule into PTCSRVLAN:
DROP tcp -- 192.168.1.69 0.0.0.0/0 tcp dpt:22
That produced a second and separate symptom: SSH connections then timed out completely. I removed that specific DROP rule, and SSH immediately became reachable again and returned to presenting the password prompt. The original authentication failure remains.

So there are two distinct events:
1. Original problem: SSH reaches Dropbear and prompts for the password, but rejects the known-good administrator password.
2. Secondary problem: repeated failed SSH attempts trigger ASUS brute-force protection, which blocks the client IP on TCP/22 and causes connection timeouts. Removing that rule restores SSH connectivity but does not fix authentication.
The password itself is not newly configured or untested. This exact username/password previously worked over SSH on this exact router, and it continues to work right now through both the WebUI and Telnet. Nothing was intentionally changed before the scheduled reboot.

I am specifically trying to determine what could change during an ASUSWRT reboot that causes Dropbear password authentication to reject an existing, previously working administrator credential while ASUS WebUI and Telnet authentication continue to accept it.
Has anyone reproduced this on GT-BE98 Pro / ASUSWRT 3.0.0.6.102_39262, or identified an ASUS/Dropbear authentication-state issue associated with this firmware?

I don't have an image, but every say... week I have to "calibrate" my camera because the PTZ slowly starts to droop down.

Any experience or ideas? I suppose I could create a script to do it, but I haven't look that hard into the reolink CLI yet. Anyone on CLI as well?

Problem 1: I have the ROG Rapture GT-BE98 Pro router. I'm having a problem with (probably) an AIMesh related log entry. From all the research I can find, this problem has existed since 2021.

• "already exist in UDB, can't add it" ... example:
• "192.168.1.12 already exist in UDB, can't add it 192.168.1.177 already exist in UDB, can't add it xx:xx:xx:xx:xx:x1 not exist in UDB, can't delete it xx:xx:xx:xx:xx:x2 not mesh client, can't delete it"

From what I understand, these are harmless log entry and AIMesh related (I have 3 x ASUS BE5000 satellites). I've also read that Merlin does not fix this. ... but my OCD refuses to let it go.

Problem 2: persistent scripts. I have a script that I use for my dual WAN, basically opening up the 2nd WAN. I've got it running fine, yet, during reboots, it does not automatically run the script as I've written it to.

Is this a time for Merlin now to fix the persistent script issue?

TIA...

TL;DR: If you're considering a Reolink OMVI 3i with Blue Iris LE, be aware that you'll need the full Blue Iris license to view and record both lenses.

First, the good: I'm genuinely impressed with Blue Iris. I repurposed an old i7-7700K into an NVR, added an 8 TB WD Purple Pro, enabled Intel+VPP, and everything has been running exceptionally well.

Where I got caught was licensing.

I purchased the Blue Iris LE license because I own one Reolink OMVI 3i. What I learned is that the OMVI 3i exposes two independent RTSP streams (one panoramic and one PTZ). Blue Iris treats those as two separate camera objects, even though they're housed in a single physical camera with one IP address.

To verify this, Blue Iris support suggested testing the RTSP streams directly in VLC. Both streams worked perfectly, confirming the camera was functioning correctly. The limitation turned out to be licensing, not configuration.

By comparison, the Reolink app (Windows and iOS) displays both lenses simultaneously because it understands they're part of the same physical device.

I'm not saying Blue Iris is wrong, technically, each independently recordable stream is a separate camera object. I just expected a single physical camera license to include all streams provided by that device.

Hopefully this saves someone else a little time if they're planning an OMVI 3i deployment.

I live in southwest Florida. My current provider is Xfinity running 2000/350. Surprisingly, I give it a 99.99% uptime and high SLA since moving in 5 years ago; however, I noticed T-Mobile Fiber (TFiber) running through our main thoroughfare about 3 weeks ago. I think the contractor is Tillman Fiber.

I was curious and my address qualified for 2000/2000 tier. Cool! I pre-ordered and expected to wait up to a year or more. No biggie, I'm not in a hurry.

FFW to 3 weeks after pre-order: they're running the microduct underground to my friggin house!! It's about a 1/8-1/4 mile run. Wha...t??!

I'm old school network guy. I remember "pre-order-->1 year or more deployment" and scheduling hell. Not this. I saw the deployment, saw who was rolling, pre-ordered and (probably) full 2k/2k to the house within a month. The even asked me this morning where I wanted the demarc on my house? ONT inside or out? (I picked inside next to my comms rack)

Saying all that: I've read the complaints. I've seen North Carolina get absolutely wrecked, so ... I'm going to be running both services in parallel. Xfinity and TFiber. New rollouts usually are still cleaning up bugs or connectivity/power issues, so we'll see.

Thank you all for your honest opinions. I've got a lot to look out for and if it doesn't work out, well, y'all warned me for sure.