[Release] Asuswrt-Merlin 384.16 (and 384.13_6) are now available

[pattiri]

Any idea what does these logs mean? (High memory usage related maybe?)

Apr 20 14:03:44 FaTiii-E61E027-C kernel httpds: page allocation failure. order:6, mode:0x40d0
Apr 20 14:03:44 FaTiii-E61E027-C kernel [<8005701c>] (unwind_backtrace+0x0/0xf8) from [<800b4b04>] (__alloc_pages_nodemask+0x3b8/0x58c)
Apr 20 14:03:44 FaTiii-E61E027-C kernel [<800b4ce8>] (__get_free_pages+0x10/0xfc) from [<80061ff8>] (dev_nvram_read+0x150/0x180)
Apr 20 14:03:44 FaTiii-E61E027-C kernel [<80061ff8>] (dev_nvram_read+0x150/0x180) from [<800dfaec>] (vfs_read+0xb0/0x144)
Apr 20 14:03:44 FaTiii-E61E027-C kernel [<800dfbc0>] (sys_read+0x40/0x70) from [<80050ac0>] (ret_fast_syscall+0x0/0x30)
Apr 20 14:03:44 FaTiii-E61E027-C kernel DMA per-cpu:
Apr 20 14:03:44 FaTiii-E61E027-C kernel active_anon:11939 inactive_anon:20416 isolated_anon:0
Apr 20 14:03:44 FaTiii-E61E027-C kernel  active_file:16130 inactive_file:18638 isolated_file:0
Apr 20 14:03:44 FaTiii-E61E027-C kernel  unevictable:0 dirty:5 writeback:0 unstable:0
Apr 20 14:03:44 FaTiii-E61E027-C kernel  mapped:2187 shmem:453 pagetables:476 bounce:0
Apr 20 14:03:44 FaTiii-E61E027-C kernel DMA free:20512kB min:20480kB low:25600kB high:30720kB active_anon:47756kB inactive_anon:81664kB active_file:64520kB inactive_file:74556kB unevictable:0kB isolated(anon):0kB isolated(file):0kB present:520192kB mlocked:0kB dirty:20kB writeback:0kB mapped:8748kB shmem:1812kB slab_reclaimable:2752kB slab_unreclaimable:120772kB kernel_stack:1200kB pagetables:1904kB unstable:0kB bounce:0kB writeback_tmp:0kB pages_scanned:0 all_unreclaimable? no
Apr 20 14:03:44 FaTiii-E61E027-C kernel lowmem_reserve[]: 0 0 0
Apr 20 14:03:44 FaTiii-E61E027-C kernel DMA: 720*4kB 886*8kB 339*16kB 28*32kB 10*64kB 4*128kB 0*256kB 0*512kB 1*1024kB 1*2048kB 0*4096kB = 20512kB
Apr 20 14:03:44 FaTiii-E61E027-C kernel 46690 total pagecache pages
Apr 20 14:03:44 FaTiii-E61E027-C kernel 11466 pages in swap cache
Apr 20 14:03:44 FaTiii-E61E027-C kernel Free swap  = 975396kB
Apr 20 14:03:44 FaTiii-E61E027-C kernel Total swap = 1048572kB
Apr 20 14:03:44 FaTiii-E61E027-C kernel 131072 pages of RAM
Apr 20 14:03:44 FaTiii-E61E027-C kernel 5619 free pages
Apr 20 14:03:44 FaTiii-E61E027-C kernel 2276 reserved pages
Apr 20 14:03:44 FaTiii-E61E027-C kernel 17055 slab pages
Apr 20 14:03:44 FaTiii-E61E027-C kernel 10353 pages shared
Apr 20 14:03:44 FaTiii-E61E027-C kernel 11466 pages swap cached
Apr 20 14:03:56 FaTiii-E61E027-C kernel httpds: page allocation failure. order:6, mode:0x40d0
Apr 20 14:03:56 FaTiii-E61E027-C kernel [<8005701c>] (unwind_backtrace+0x0/0xf8) from [<800b4b04>] (__alloc_pages_nodemask+0x3b8/0x58c)
Apr 20 14:03:56 FaTiii-E61E027-C kernel [<800b4b04>] (__alloc_pages_nodemask+0x3b8/0x58c) from [<800b4ce8>] (__get_free_pages+0x10/0xfc)
Apr 20 14:03:56 FaTiii-E61E027-C kernel [<800b4ce8>] (__get_free_pages+0x10/0xfc) from [<80061ff8>] (dev_nvram_read+0x150/0x180)
Apr 20 14:03:56 FaTiii-E61E027-C kernel [<80061ff8>] (dev_nvram_read+0x150/0x180) from [<800dfaec>] (vfs_read+0xb0/0x144)
Apr 20 14:03:56 FaTiii-E61E027-C kernel [<800dfaec>] (vfs_read+0xb0/0x144) from [<800dfbc0>] (sys_read+0x40/0x70)
Apr 20 14:03:56 FaTiii-E61E027-C kernel [<800dfbc0>] (sys_read+0x40/0x70) from [<80050ac0>] (ret_fast_syscall+0x0/0x30)
Apr 20 14:03:56 FaTiii-E61E027-C kernel Mem-info:
Apr 20 14:03:56 FaTiii-E61E027-C kernel DMA per-cpu:
Apr 20 14:03:56 FaTiii-E61E027-C kernel CPU    0: hi:  186, btch:  31 usd:   0
Apr 20 14:03:56 FaTiii-E61E027-C kernel CPU    1: hi:  186, btch:  31 usd:  30
Apr 20 14:03:56 FaTiii-E61E027-C kernel active_anon:11899 inactive_anon:20329 isolated_anon:0
Apr 20 14:03:56 FaTiii-E61E027-C kernel  active_file:16118 inactive_file:18780 isolated_file:0
Apr 20 14:03:56 FaTiii-E61E027-C kernel  unevictable:0 dirty:6 writeback:0 unstable:0
Apr 20 14:03:56 FaTiii-E61E027-C kernel  free:5095 slab_reclaimable:685 slab_unreclaimable:30195
Apr 20 14:03:56 FaTiii-E61E027-C kernel  mapped:2184 shmem:452 pagetables:482 bounce:0
Apr 20 14:03:56 FaTiii-E61E027-C kernel DMA free:20380kB min:20480kB low:25600kB high:30720kB active_anon:47596kB inactive_anon:81316kB active_file:64472kB inactive_file:75120kB unevictable:0kB isolated(anon):0kB isolated(file):0kB present:520192kB mlocked:0kB dirty:24kB writeback:0kB mapped:8736kB shmem:1808kB slab_reclaimable:2740kB slab_unreclaimable:120780kB kernel_stack:1216kB pagetables:1928kB unstable:0kB bounce:0kB writeback_tmp:0kB pages_scanned:0 all_unreclaimable? no
Apr 20 14:03:56 FaTiii-E61E027-C kernel lowmem_reserve[]: 0 0 0
Apr 20 14:03:56 FaTiii-E61E027-C kernel DMA: 733*4kB 919*8kB 344*16kB 21*32kB 10*64kB 4*128kB 0*256kB 0*512kB 1*1024kB 1*2048kB 0*4096kB = 20684kB
Apr 20 14:03:56 FaTiii-E61E027-C kernel 11431 pages in swap cache
Apr 20 14:03:56 FaTiii-E61E027-C kernel Free swap  = 975032kB
Apr 20 14:03:56 FaTiii-E61E027-C kernel Total swap = 1048572kB
Apr 20 14:03:56 FaTiii-E61E027-C kernel 131072 pages of RAM
Apr 20 14:03:56 FaTiii-E61E027-C kernel 5574 free pages
Apr 20 14:03:56 FaTiii-E61E027-C kernel 2276 reserved pages
Apr 20 14:03:56 FaTiii-E61E027-C kernel 17055 slab pages
Apr 20 14:03:56 FaTiii-E61E027-C kernel 10491 pages shared
Apr 20 14:03:56 FaTiii-E61E027-C kernel 11431 pages swap cached

Here the memory and swap usage.

 

[sanchez13]

Hi,

firmware 384.16 working fine on my routers...
Except one small problem/bug. Workgroup for samba with "dot" can't be set. (USB Application - Network Place (Samba) Share / Cloud Disk)

For example if I set workgroup name to sanchez.lan, then this error is displayed:

"Only alphanumeric characters, underscore, and dash symbol are accepted. The first character cannot be a dash - or a underscore _ ."

workgroup without "." is accepted...

S.

 

[JonEngland]

Any idea what does these logs mean? (High memory usage related maybe?)

Apr 20 14:03:44 FaTiii-E61E027-C kernel httpds: page allocation failure. order:6, mode:0x40d0

linux can reclaim memory from buffers and cache so adding up free+buffers+cache shows you the real 'free' memory the system has access to, so your stats show 156.58 free/reusable ram.

the issue shown in your logs is with httpds page allocation
httpds: page allocation failure. order:6, mode:0x40d0

here's some info on Linux kernel's page allocation failure messages:
"Memory fragmentation means that it's quite possible for high-order requests to fail even if there's plenty of pages free, while an order:0 failures mean that your machine is totally out of memory with not even a single page free."
and
"On a side note, you might wonder why the OOM killer didn't trigger here (it didn't). The short answer is that it's not triggered for higher order allocations, only for allocations of 32 Kb and smaller (order 3 or below). So this allocation request is just large enough to not trigger OOM processing. All things considered that's probably a good thing."
see https://utcc.utoronto.ca/~cks/space/blog/linux/DecodingPageAllocFailures

 

[Deleted member 51572]

Agree... […]
Seems like Asus is trying to fix this in the 385.x branch. It's still a work in progress so far, since it somehow autoadjust the scale if you go over the limit you have chosen, and the meters graphic disappear for sec.[…]

aha, a clunky slider switch is better than nothing i suppose, but the speedometer gauge could be programmed to scale itself automatically, by compressing the numbers leftwards on the dial as internet speeds peak above certain values. a logarithmic speedometer?

 

[Deleted member 51572]

aha, a clunky slider switch is better than nothing i suppose, but the speedometer gauge could be programmed to scale itself automatically, by compressing the numbers leftwards on the dial as internet speeds peak above certain values. a logarithmic speedometer?

ahh here it is, a logarithmic speedo:

much easier to see internet speed at a glance

 

[Catalinus]

Update since my post almost one week ago - there is certainly some problem with WiFi stability on AX88U and I am increasingly considering returning to .15 - does anybody else see the same issue? Any advice?

I can clearly confirm this now - everything worked perfectly since last week until this morning when suddenly 2-3 of the iOS devices disconnected and started to act very strange (as if the password was changed). A software-initiated router restart instantly fixed everything (I guess for at least a few days from now). Have never seen anything similar on .15 and I did have runs of more than a month without a single router reset. Will investigate further and come back with other details if relevant.

 

[MDM]

I can clearly confirm this now - everything worked perfectly since last week until this morning when suddenly 2-3 of the iOS devices disconnected and started to act very strange (as if the password was changed). A software-initiated router restart instantly fixed everything (I guess for at least a few days from now). Have never seen anything similar on .15 and I did have runs of more than a month without a single router reset. Will investigate further and come back with other details if relevant.

Did your iOS devices updated recently by any chance?

 

[Catalinus]

Hi, not here. My AX88U wifi has been rock solid during all the 384.16 development cycle, including alphas and betas. We have about 20+ wifi devices in both bands (no AX devices currently though, and 160 mhz band NOT enabled). So if you post your wifi settings (general and professional tabs) I can spot you the differences so you can at least verify if it is something specific of your hardware or to your configuration...

Thank you, I also do not have the 160MHz option but the reasons I am increasingly convinced that is not a configuration issue but instead a major bug in the closed-source part from ASUS are:

- there was NEVER, EVER such a problem on .15 with identical configuration

- the situation is instantly fixed after a software restart and remains OK like that for a long time (4+ days)

- from what I understand there are clearly some changes and a new daemon in regard to how WiFi disconnects are handled; the issue looks like some resource gets depleted in time, not so much as if something would be randomly happening to the radio (since it never happened at less than 5-6 days after last restart).

IMHO the definitive answer would be to go back to .15 (still with exactly the same configuration) and leave it like that for 7+ days or so - I will probably try to do that later today unless somebody has a much better idea.

 

[Catalinus]

Did your iOS devices updated recently by any chance?

Not in the last days, I believe the 11Pro has an uptime of 11 days or so since I updated to 13.4.1 (I always manually update, and never update in the first day unless there is an extraordinary reason for it). Also it connected instantly the moment the AX88 restarted, so IMHO it was not that much the iOS part (even if it could be something that those do in a more special way?)

 

[MDM]

even if it could be something that those do in a more special way?

Could be...
WPA3 or other FW changes that are not yet fully compatible...

 

[Catalinus]

Installed 384.16 the other day (upgrading from 384.15), on both my primary router (86U) and my AP (68U). The upgrade went fine on both devices. And for 2 days, all was fine. This morning, I noted that while in portion of house near the 86U, my phone (Galaxy S20) was not connected to WiFi. I tried connecting to my 5Ghz network - would not connect. Walked to back of house (near 68U), phone connected just fine. Tried same thing with my wife's phone (iPhone) and same basic results. Phone would attempt to connect, sometimes reported an authentication error (haven't changed password for a very long time) and sometimes not. I tried connecting on the 2.4Ghz network, and that worked fine with both phones. Rebooted the router, and problem went away. But this is something that hasn't happened before.

Yeah, I have seen something a little similar on AX88U - after the reset things work fine for 4-5-6 days - so maybe keep an eye on this if it happens again!

 

[visortgw]

Could be...
WPA3 or other FW changes that are not yet fully compatible...

I was seeing some device disconnect issues -- including my MacBook Air -- with WPA3 enabled. Going back to WPA2 resolved it completely.

 

[FTC]

ahh here it is, a logarithmic speedo:
View attachment 22865
much easier to see internet speed at a glance

Well, the speedometers for 'Upload' and 'Download' bandwith in adaptive QoS->Bandwith monitor tab are already logarithmic and do auto-adjust. It was already suggested during 384.16 development cycle to adopt this same idea for the 'Internet traffic' indicators in the main 'network map' GUI tab, however this idea did not really caught off, and after all.. it is not a very important detail and in the end it is who does the work (Merlin) who decides the criteria and what is his time invested in... Which I absolutely agree and respect.

 

[FTC]

Thank you, I also do not have the 160MHz option but the reasons I am increasingly convinced that is not a configuration issue but instead a major bug in the closed-source part from ASUS are:

- there was NEVER, EVER such a problem on .15 with identical configuration

- the situation is instantly fixed after a software restart and remains OK like that for a long time (4+ days)

- from what I understand there are clearly some changes and a new daemon in regard to how WiFi disconnects are handled; the issue looks like some resource gets depleted in time, not so much as if something would be randomly happening to the radio (since it never happened at less than 5-6 days after last restart).

IMHO the definitive answer would be to go back to .15 (still with exactly the same configuration) and leave it like that for 7+ days or so - I will probably try to do that later today unless somebody has a much better idea.

I understand you. My offering to compare my wifi settings with yours still holds as it could still help to confirm your suspicions or help you to get a stable system by adjusting your config to match mine, which is behaving rock solid in 384.15 and 16 Merlin builds.

 

[MarcoPolo]

2 bugs?
(Compared with an RT-AC68U fw:384.15, replaced by an RT-AX88U fw:384.16) :

1. An SSID that starts with a space is not kept after a router reboot. The space disappears at the beginning of the chain after rebooting. Main Wifi as well as Wifi guests.

2. An OpenVPN client that was connected but falls down is not restarted by itself (with Connection Retry attempts = -1). "cru l" is empty.

Is it a problem with my configuration inspired by my old RT-AC68U router or is it 2 anomalies on the RT-AX88U?

Thank you

 

[L&LD]

1. The use of a 'space' character is not part of a valid SSID. This will only be enforced more in the future, I believe.

 

[CaptainSTX]

Who is your VPN provider?

Have you tried setting retry settings to a number such as 15?

What are your custom settings?

 

[MarcoPolo]

1. The use of a 'space' character is not part of a valid SSID. This will only be enforced more in the future, I believe.

Maybe, but it used to work with asuswrt merlin.
It's been working for years.
All my peripherals supported it.
It also works with version 384.16 but only until the next reboot.
After a reboot, I just have to put the space back and it works.
So I consider it a bug since it worked in previous firmwares.

 

[MarcoPolo]

Who is your VPN provider?

Have you tried setting retry settings to a number such as 15?

What are your custom settings?

NordVPN.
I use the same settings that worked well for a very long time on my RT-AC68U (up to firmware 384.15) before I changed my router for the RT-AX88U.
I haven't tested any values other than -1.
But there used to be a command in the "CRU" scheduler that checked if the OpenVPN client was running properly, but this is no longer the case.

 

[Martineau]

But there used to be a command in the "CRU" scheduler that checked if the OpenVPN client was running properly, but this is no longer the case.

Removed

384.8 (2-Dec-2018)
  - CHANGED: Removed watchdog from OpenVPN clients, to avoid
             conflicting with more advanced configurations.

It's usefulness was limited as the Watchdog monitoring simply checked if there is an existing PID for the VPN Client, and usually the PID always exists, as it's the internal peer data connection between the Client and the Server that stalls.