AC88U Merlinwrt 386.2_2 not accessible after update

[Hinnerk]

I have just flashed the 386.2_2 Merlinwrt for my AC88U. It is working mostly nicely - that is, I'm currently using that router as I am writing these lines.
However, I cannot login to the router anymore. I had it configured to use https only and had added a self signed certificate. Now, when I try to connect by router.asus.com:8443 it takes a while and then a timeout error occurs (Fehler: Netzwerk-Zeitüberschreitung). No warnings or errors due to the certificate, but I included it in this report to give you the full picture.

How can I get back in?

Best,

Hinnerk

 

[Hinnerk]

Somehow it works now. Beats me.

 

[Deleted member 22229]

If you had read the change log you would have seen this.


- NOTE: Some users upgrading might have to go through some
database maintenance on first boot, which means the
router might be slower or have a non-responsive webui
for a while.
This can take anywhere from 5 minutes up to an hour,
depending on your model, just give it time to complete
the process.

 

[swin66]

Is there any way to tell if this is what it is doing? (is there a process monitor of some sort?)

I upgraded and have been waiting for well over an hour, internet and wifi works but not UI.

I can log in via SSH but not sure what command I can use to give me a clue as to what it's currently doing.

 

[RMerlin]

Is there any way to tell if this is what it is doing? (is there a process monitor of some sort?)

I upgraded and have been waiting for well over an hour, internet and wifi works but not UI.

I can log in via SSH but not sure what command I can use to give me a clue as to what it's currently doing.

Run "top" over SSH. nt_center is the process that does this one-time maintenance after moving from 384.xx to 386.xx.

 

[Centrifuge]

Is there any way to tell if this is what it is doing? (is there a process monitor of some sort?)

I upgraded and have been waiting for well over an hour, internet and wifi works but not UI.

I can log in via SSH but not sure what command I can use to give me a clue as to what it's currently doing.

top

 

[swin66]

Run "top" over SSH. nt_center is the process that does this one-time maintenance after moving from 384.xx to 386.xx.

nt_center and
[jffs2_gcd_mtd9]
are hogging CPU, 20% and 40% respectively

Upgrade was about 5hrs ago, is it still possible for it to be running the maintenance task this long? (AC86U)

 

[RMerlin]

Upgrade was about 5hrs ago, is it still possible for it to be running the maintenance task this long? (AC86U)

I guess it depends on the size of the database, but your info does confirm it`s doing database maintenance. Maybe you had a very large database with lots of entries.

 

[swin66]

I guess it depends on the size of the database, but your info does confirm it`s doing database maintenance. Maybe you had a very large database with lots of entries.

I guess it must have, as it's all ok this morning.

Out of interest, what is in the database and is this something I need to be aware of or do regular maintenance on?

 

[RMerlin]

I guess it must have, as it's all ok this morning.

Out of interest, what is in the database and is this something I need to be aware of or do regular maintenance on?

I don't know the details, but Asus stores activity data in that database, such as wifi connections/disconnections. No idea either what it's used for, maybe for sharing info between AiMesh nodes?

Again, I don't know the details either, but I suspect that between 384 and 386 Asus added functionality to trim the size of the database to prevent it from filling the whole JFFS partition. So that first trim is probably taking a long time, as there is a lot of entries to trim and that database is stored in slow flash rather than in RAM. Once that one is done, future trims should be much faster, as there won't be as much to trim.

This is just based on outside observation, as I don't have access to the nt_center source code.

 

[MvW]

I guess it must have, as it's all ok this morning.

Thanks for your patience. It gives us the opportunity to inform users that it might just as easily take longer than the 5 minutes to an hour as mentioned in the release note/changelog and that it eventually complete it's maintenance. Hopefully it's a one time thing, as many users have had issues with it (which I can imagine, as unfortunately changelogs aren't read that well) and it's good to hear that your patience has been rewarded with a working GUI overnight. @RMerlin, maybe you want to consider to change it from '5 minutes to an hour' to '5 minutes to several hours', as there's a huge difference between users, all eager to log back in again immediately after updating.

 

[RMerlin]

@RMerlin, maybe you want to consider to change it from '5 minutes to an hour' to '5 minutes to several hours', as there's a huge difference between users, all eager to log back in again immediately after updating.

This was the 386.1 changelog, a bit late to change it now. And as shown by posts on the forums, people don't even read it, so what's the point.

I based my initial estimation on the feedback received during the beta, as well as my own personal experience. It's only after the release that a few exception cases appeared taking insanely long time.

 

[Tech9]

I guess it depends on the size of the database

What data this database contains, @RMerlin? I tried to reproduce this updating process jumping from 384.15 straight to 3862_2 and the UI comes back right after the update. The test router is AC86U. Do I need to run it on 384.x for some time to "collect" data or what?

 

[RMerlin]

What data this database contains, @RMerlin? I tried to reproduce this updating process jumping from 384.15 straight to 3862_2 and the UI comes back right after the update. The test router is AC86U. Do I need to run it on 384.x for some time to "collect" data or what?

I don`t know the details, only that it contains at the very least data from wireless clients connecting/disconnecting. So, the existence and the size of the database will depend on what firmware version you ran before, and for how long. If you just jump back and forth between 384.xx and 386.xx, you won't get the maintenance happen again unless you were to fill up the database while under 384.xx I assume.

 

[Wade Coxon]

I know that a month or two before this update, my jffs partition had completely filled up with this database. At the time, I ended up just deleting the database, and it more or less stayed at a reasonable size after that.

When the update rolled around, the trim procedure barely took any time at all luckily for me.
I can only imagine how long it might take for someone who's database was in a similar state to what mine was.

 

[MvW]

This was the 386.1 changelog, a bit late to change it now. And as shown by posts on the forums, people don't even read it, so what's the point.

I understand what you're saying, but then it's senseless to try and 'educate' other members to read the changelog and refer them to it. In that case I'll better copy these lines from the changelog and add them to Expanso or Text Expander and keep repeating them. The point is: once you write down 'up to an hour' everyone who hasn't got their UI back after 61 minutes, will see it fit to file a complaint...

 

[bacon612]

Chiming in here with my experience. Upgraded a 68u at my parents place that has been in service for ages. Went from 384.19 to 386.2_2. Its been about 3 hours and while the router is passing traffic and will accept my user name and password over remote https, the gui wont display and seems to hang on a TLS handshake. Ill wait overnight and see if I have luck logging in tomorrow. Just curious to know if i should be trying anything else. The fact that i at least get the login screen is a good sign, right? I live quite far from my parents and walking them through something as simple as installing teamviewer in the past has been an ordeal. Hoping that some patience solves this issue.

Edit: Patience paid off. Working fine a day later