[Release] Asuswrt-Merlin 384.14 (and 384.13_2) are now available

[Sanna1967]

I noticed as well that "Enable IGMP Snooping" under the Professional tab, for both bands, is on by default with 384.14 but off by default in 384.13. Is there a reason for this?

+1

 

[Big Dave]

Have been following/install the 384.14 Betas and everything has 'worked'....upgraded to 384.14 non-beta and my network WiFi drops signal again and again (no changes to config). Have reverted back to 284.13_Beta3 and stable again.

Setup: RT-AC86U as the main router (with ASUSWrt-Merlin installed)....have two other RT-AC86Us with 3.0.0.4.384_81351-gcb63868 (from ASUS) as I believe this is recommended setup for running AiMesh Nodes. If I remember right, not important/relevant Log messages except for Channel Changes.

Thanks in advance for any help and all the good/hard work on ASUSWrt-Merlin!

=\dave

 

[Morac]

There’s something wrong with the traffic analyzer in 384.14. The real-time and monthly traffic seems okay, but the daily and last 24 is giving extremely wrong results. I’m talking traffic values of 17,000,000,000 GB. This started after I updated to 384.14 on my AC88U.

Edit:

Today’s value somehow fixed itself, but something is still wrong.

 

[Val D.]

I’m taking traffic values of 17,000,000,000 GB.

Did you try to download YouTube by chance? I'm more impressed by your storage capacity.

 

[SNBForums User]

Multi-year user of Merlin's builds, without significant issues prior to 384.14, but as has been reported multiple times with regard to this release and in this thread, for the first time ever, my RT-AC68U, although every function and system appears to be working properly, is also now reporting a status of Internet disconnection:

. Interestingly, if I refresh virtually any function, the Network Map also refreshes for a very brief moment before reverting to its indicated disconnected status.

 

[goRt]

AC86U 384.14 USB-modem Android phone (actually a Huawei E3372 in h.link mode) unable to connect to the internet, unable to connect to the modem's control page.
Reverting to 384.13.0 resolves the issue.

 

[ollimoe]

Restore config is (IMHO) only for a same hardware, same firmware scenario.
If either of those differs from when the config was saved, any ‘restore’ needs to be done from scratch, manually.

It was my understanding that one of the MERLIN befits is/was to be able to exchange config between different devices - I might have been wrong.
After a night of extensive testing I finally figured, that even restores on the same platform send the device in the woods. I tried this on my AC86U as well as on the AX88U. Both devices were nuked to a factory status, configured manually from scratch - no, additional tools, just LAN/WLAN router config, rest default. Config saved. Device reset to factory default - attempt to restore config, device no longer accessible.
And - the problem only occurs on verion 384.14 - 384.13 works without any issues, even cross-grading with config files did work without any problems.
Not sure if this is a regional thing - I am in EMEA - but there is a a significant change with version 14 - for now it looks like config restore is a No-Go with 384.14

 

[AndreiV]

It was my understanding that one of the MERLIN befits is/was to be able to exchange config between different devices - I might have been wrong.

You are totally wrong , you cannot use configs/backups on different devices on any make of router , if it were possible why would anyone spend time compiling different firmware for each model ?

If you have a problem on a device , factory restore and manually set up , adding a stored/previous config file is obviously a stupid thing to do, you are moving the problem to the fresh install.

 

[ollimoe]

Thanks for your "kind & friendly" response - as you may have read from my post I did what you just described - factory reset, manually config ... - except that the "stupid" thing is, that a clean restore of the config sends your device into nirvana on 384.14 ONLY - same thing on my AC86U as well as AX88U - and yes, I did NOT mix the config files - clear now?

 

[ech]

There’s something wrong with the traffic analyzer in 384.14. The real-time and monthly traffic seems okay, but the daily and last 24 is giving extremely wrong results. I’m talking traffic values of 17,000,000,000 GB. This started after I updated to 384.14.

Edit:

Today’s value somehow fixed itself, but something is still wrong.

Seeing the same thing here. .13 fine... .14 showing this problem.

This and the "Internet Status: disconnected" problem (status says that but connectivity is fine) are the two nasty problems I've seen and continue to see with .14 on my AC68U.

 

[miroco]

Does anyone have an idea what this is? I'm on an rt-ac86u and 384.14. I have a vanilla configuration and the usual suspects (T.M.) are deactivated. The router was reseted to factory default after the upgrade to 384.14 and manually configured.

A google search came up basically empty. BDMF - Broadcom Device Management Framework, other than that - zilch. The systemlog is in debug mode and this was an isolated event in time by more than 2h.

Dec 19 22:11:41 kernel: ERR: bdmf_attrelem_add_as_buf#4250: ucast: status:Entry already exists. attribute:flow  index:4294967295
Dec 19 22:11:41 kernel: ^[[0;33;41m[ERROR pktrunner] runnerUcast_activate,1971: Cannot rdpa_ucast_flow_add^[[0m
Dec 19 22:11:47 kernel: ERR: bdmf_attrelem_add_as_buf#4250: ucast: status:Entry already exists. attribute:flow  index:4294967295
Dec 19 22:11:47 kernel: ^[[0;33;41m[ERROR pktrunner] runnerUcast_activate,1971: Cannot rdpa_ucast_flow_add^[[0m
Dec 19 22:11:56 kernel: ERR: bdmf_attrelem_add_as_buf#4250: ucast: status:Entry already exists. attribute:flow  index:4294967295
Dec 19 22:11:56 kernel: ^[[0;33;41m[ERROR pktrunner] runnerUcast_activate,1971: Cannot rdpa_ucast_flow_add^[[0m

Uptime: 5 days, 22h, 17m and 20sec

 

[eclp]

With the new 384.14, the DNSSEC tests on this page no longer run correctly on my AX88U.

http://0skar.cz/dns/en/

 

[ollimoe]

With the new 384.14, the DNSSEC tests on this page no longer run correctly on my AX88U.

http://0skar.cz/dns/en/

Looks like to consider a downgrade to 384.13 - considering the same due to the above mentioed config problems

 

[predatorz]

Dirty upgrade to 384.14, everything seem fine on my end.

 

[JGrana]

Thanks for your "kind & friendly" response - as you may have read from my post I did what you just described - factory reset, manually config ... - except that the "stupid" thing is, that a clean restore of the config sends your device into nirvana on 384.14 ONLY - same thing on my AC86U as well as AX88U - and yes, I did NOT mix the config files - clear now?

As far as your earlier comment on exchanging configs between different routers - your were correct. At one time, @john9527 had created a great utility called "User NVRAM Save/Restore" that would intelligently save and restore nvram settings across different firmware releases and also had a "Migration mode" that would allow you to take settings from one model of Asus router to another.

Unfortunately, @john9527 stopped updating the utility around 1 1/2 years ago. I suspect with all the changes to both the firmware and expanding products, it became a support nightmare.

I have read that @Xentrk might be attempting to resurrect this utility. It would be most helpful!

As @AndreiV mentioned, the config file that the Asus firmware creates (stock or Merlins) only applies to that particular router and release of firmware. There are other elements in the file that are not normally user configurable.

For now, all of us have to re-configure manually...(ahh, I miss the good old days ;-)

 

[Huib]

Multi-year user of Merlin's builds, without significant issues prior to 384.14, but as has been reported multiple times with regard to this release and in this thread, for the first time ever, my RT-AC68U, although every function and system appears to be working properly, is also now reporting a status of Internet disconnection: View attachment 20386. Interestingly, if I refresh virtually any function, the Network Map also refreshes for a very brief moment before reverting to its indicated disconnected status.

I had the same issue, reported earlier in this thread, and a member PM'ed me this solution: check the value of link_internet.

nvram get link_internet

If it reports 0 then set it to 2:

nvram set link_internet=2

That fixed it for me. Haven't rebooted since so unsure about its stickiness.

 

[htismaqe]

@RMerlin / @dev_null

My previous posts have now been buried by new activity so I'm tagging you. I re-flashed 384.14 release last night and reset to factory defaults. I set everything up from scratch and this time left AI Protect off.

Last night was pretty decent as far as usage (peak download hit 77mbps out of 100 and we used 42GB in the 8 hours following the re-flash) and the web UI is responsive and even snappy.

For now AI Protect stays off, I will let you know if the issue comes back.

 

[fg64]

384.14 dirty upgrade from .13 up for 2 days with no issues. Thank you Merlin.

 

[ech]

I had the same issue, reported earlier in this thread, and a member PM'ed me this solution: check the value of link_internet.

nvram get link_internet

If it reports 0 then set it to 2:

nvram set link_internet=2

That fixed it for me. Haven't rebooted since so unsure about its stickiness.

I know about that.. but it's not a fix and it isn't sticky - reboot and the problem (in the GUI, not actual connectivity) is back.

 

[RMerlin]

Today’s value somehow fixed itself, but something is still wrong.

Closed source, outside of my control.