[ 386.7 alpha Build(s) ] Testing available build(s)

[John Fitzgerald]

It means your partition either filled itself up, or it's not mounting properly due to an issue or content corruption.

Based on this screenshot you can see that the restored JFFS image use is very small. I don't know how it would have grown to an unusable size. The drive was fresh formatted not that long ago and the 3 scripts were loaded new as well. The drive is in good health.

Could there be a problem / clash among the scripts? I'm scratching my head on this one.

Thanks for all you do.

 

[QuikSilver]

Flashed new alpha on my RT-AX86U, getting similar issue as @John Fitzgerald above.

 

[QuikSilver]

So Aimesh AC86u unit disappeared

Gonna downgrade back to 386_5_2 release to see if everything comes back to normal.

Edit: Put old firmware back on, no longer getting the ! message and jffs is mounted, but it looks like everything is gone including swap file.

Edit 2: restored jffs and rebooted, seems back to normal for now.

 

[SomeWhereOverTheRainBow]

Based on this screenshot you can see that the restored JFFS image use is very small. I don't know how it would have grown to an unusable size. The drive was fresh formatted not that long ago and the 3 scripts were loaded new as well. The drive is in good health.

Could there be a problem / clash among the scripts? I'm scratching my head on this one.

Thanks for all you do.

View attachment 41665

Corrupt traffic analyzer/monitor data resulting from the flash could cause it to fill quick.( that is just one example).

 

[John Fitzgerald]

So Aimesh AC86u unit disappeared
View attachment 41669

Gonna downgrade back to 386_5_2 release to see if everything comes back to normal.

Edit: Put old firmware back on, no longer getting the ! message and jffs is mounted, but it looks like everything is gone including swap file.

Edit 2: restored jffs and rebooted, seems back to normal for now.

I'm on the Alpha but I had to wipe JFFS and restore fresh image done just before flash.

It seems to be OK now.

 

[John Fitzgerald]

Corrupt traffic analyzer/monitor data resulting from the flash could cause it to fill quick.( that is just one example).

Are the scripts not keeping pace with the firmware upgrades in terms of compatibility?
I only run the 3 listed.

 

[SomeWhereOverTheRainBow]

Are the scripts not keeping pace with the firmware upgrades in terms of compatibility?
I only run the 3 listed.

Well traffic monoitor/analyzer is not a script but a built in router feature that keeps track of client data usage. It stores daily weekly, and even monthly statistics if that part of the feature is enabled. There was a firmware update once upon a time that cause such corruption to jffs. The solution is to make sure this data is deleted before flashing.

 

[John Fitzgerald]

Well traffic monoitor/analyzer is not a script but a built in router feature that keeps track of client data usage. It stores daily weekly, and even monthly statistics if that part of the feature is enabled. There was a firmware update once upon a time that cause such corruption to jffs. The solution is to make sure this data is deleted before flashing.

Does weekly rebooting clear the logs?

 

[SomeWhereOverTheRainBow]

Does weekly rebooting clear the logs?

No it is stored in jffs in a corruptable .db format. Any changes to the traffic monitor process could have easily corrupted the .db causing it to exponentially grow insize. The .db database is compressed but when it becomes corrupt it loses this quality.

 

[John Fitzgerald]

No it is stored in jffs in a corruptable .db format. Any changes to the traffic monitor process could have easily corrupted the .db causing it to exponentially grow insize. The .db database is compressed but when it becomes corrupt it loses this quality.

Any way this is a memory leak or hardware issue.

 

[SomeWhereOverTheRainBow]

Any way this is a memory leak or hardware issue.

It really is a feature issue. It can be turned off and completely deleted. I have mine turned off. The gui tab path is:
Traffic Analyzer>Statistics

 

[John Fitzgerald]

It really is a feature issue. It can be turned off and completely deleted. I have mine turned off. The gui tab path is:
Traffic Analyzer>Statistics

I just rechecked before I replied, but I have never had this feature turned on.

 

[SomeWhereOverTheRainBow]

I just rechecked before I replied, but I have never had this feature turned on.

View attachment 41672

Keep an eye on storage size in /jffs/.sys and it's subdirectories after flashing.

 

[John Fitzgerald]

Keep an eye on storage size in /jffs/.sys and it's subdirectories after flashing.

OK, Thanks.

 

[dbell]

Successfully upgraded my mesh (pair AX86Us) with the latest non-cferom build.

 

[capncybo]

Well well well... I have to eat my previous words. Got home from work & apparently...
Simply "Rebooting my RT-AC68U Node" was enough to re-establish the AiMesh Connection with my RT-AX86U Router. Very nice & didn't require me to move the node closer or directly connect it via Ethernet.
So Bravo & Thx

 

[DiGz_Au]

Ax86u running fine on latest alpha with 0.0.0.6 CFE

 

[learning_curve]

~~ I can access the WebUI using IPv6 as I can access it using IPv4, meaning using the IP addresses of the br0 interface, but in the internet browser address field, the IPv6 address has to be encapsulated by square brackets [ ] because the four hexadecimal delimiting character in the IPv6 address (human friendly) representation is the colon : , same as the one used to delimiting the port from the ip. So while for IPv4 the address is https://192.168.0.1:8443, for IPv6 the address is https://[fe80::aaaa:bbbb:cccc:dddd]:8443. This is the Link-local IPv6 address, but it works with the Global IPv6 one as well ~~

That's one route I didn't mention (or use) in my 2 previous, IPv6 related posts in this thread (one & two), but not because of the IPv6 address browser requirements, which you've helpfully, clearly re-stated there and which are often forgotten, but because of the SSL warnings etc that you'll receive if / when trying to access the WebUI via IP address only (IPv4 OR IPv6). That's the main reason for using an FQDN instead, as explained in this helpful post from @Jeffrey Young that I'd already referred to early. The above post by @AurelM should be useful for you @qiuyan81 as it too, confirms that WebUI access via IPv6 is fully available in these latest Alpha releases.

 

[SomeWhereOverTheRainBow]

OK, Thanks.

Yea sometimes it is very hard to say when dealing with these newer AX models. Let me know if anything changes, or what you do find out. It may help another user here.

 

[LimJK]

Updated my AiMesh Router and Nodes, no problem so far Thanks!