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

[SomeWhereOverTheRainBow]

Now I feel dumb. I initially checked Cloudflares status on their web site and it said they were having problems but overseas from me. So I figured it wasn't cloudflare.

Then I decided a few minutes ago to check Cloudflares status with the website called downdetector and sure enough my part of the states where I live had reports of Cloudflare being down.

So all is good, no problems but Cloudflare.

yea cloudflare has been having some connectivity issues lately in some areas, ( i've experienced some issues lately too).

 

[TheChez]

Is anyone else having propagation issues? I wasn't having these before 384.14 and then all hell broke loose.

Dec 31 23:15:12 kernel: br0: topology change detected, propagating
Dec 31 23:15:33 kernel: br0: port 1(vlan1) neighbor 8000.00:08:9b:e8:25:46 lost
Dec 31 23:15:33 kernel: br0: topology change detected, propagating
Dec 31 23:15:54 kernel: br0: port 1(vlan1) neighbor 8000.00:08:9b:e8:25:46 lost
Dec 31 23:15:54 kernel: br0: topology change detected, propagating

 

[Smokey613]

I tried 384.14 but it broke my NextDNS service. I understand that has been corrected but to be honest, 384.13 is so rock solid for my setup, I don’t see me messing with anything else right now.

 

[SomeWhereOverTheRainBow]

I tried 384.14 but it broke my NextDNS service. I understand that has been corrected but to be honest, 384.13 is so rock solid for my setup, I don’t see me messing with anything else right now.

There is a fix it is called 384.14_1 under the beta section for downloads then you will still be rock solid

 

[Smokey613]

There is a fix it is called 384.14_1 under the beta section for downloads then you will still be rock solid

Thanks, I did mention that in my post but I will just let the updates mature a little more. I had thought about getting a newer router but my old 68U just chugs along on 384.13 and watching all the “issues” with the newer ones I am hesitant to mess with it. I don’t have memory issues, wireless issues, etc. I will keep up to date on the progress on the firmware and I am sure eventually I will update, but not right now. Thanks to RMerlin for his efforts.

 

[Gerald Boutin]

I uploaded a few 384.14_1 test builds:

https://www.asuswrt-merlin.net/test-builds

Changes since 384.14:

  - FIXED: Random traffic spikes logged in Traffic Monitor (regression
           from 384_81351)

My Traffic Analysis reporting app seems to have had a major Y2020 problem. It has somehow decided that all traffic since the beginning of time happened simultaneously at my local time: 2 AM January 1, 2020.

At first I thought this was a bug, and it still may be, but it seems now that it is really just the biggest random 'spike' ever to be recorded. The previous Daily and Monthly data are still intact as far as tabular data is concerned. Since I don't see a lot of other reports, I assume I am just seeing a mega-spike and not a Y2020 bug.

This affects the Last 24 Hours, Daily and Monthly graphical displays rendering them useless. Going back to version 384.13.0 does not change anything. The reason that the graph displays are now useless is because of the auto-scaling. Anything new isn't large enough to even show up above the zero baseline.

Does anyone have ideas on how to edit this bad record out of the stored data? I have the data on a USB stick, but I only know enough to be dangerous.

In the mean time, I am going to move up to 384.14.1 as that should hopefully reduce chances of further spikes.

> Gerald Boutin

 

[pattiri]

My Traffic Analysis reporting app seems to have had a major Y2020 problem. It has somehow decided that all traffic since the beginning of time happened simultaneously at my local time: 2 AM January 1, 2020.

At first I thought this was a bug, and it still may be, but it seems now that it is really just the biggest random 'spike' ever to be recorded. The previous Daily and Monthly data are still intact as far as tabular data is concerned. Since I don't see a lot of other reports, I assume I am just seeing a mega-spike and not a Y2020 bug.

This affects the Last 24 Hours, Daily and Monthly graphical displays rendering them useless. Going back to version 384.13.0 does not change anything. The reason that the graph displays are now useless is because of the auto-scaling. Anything new isn't large enough to even show up above the zero baseline.

Does anyone have ideas on how to edit this bad record out of the stored data? I have the data on a USB stick, but I only know enough to be dangerous.

In the mean time, I am going to move up to 384.14.1 as that should hopefully reduce chances of further spikes.

> Gerald Boutin


View attachment 20611 View attachment 20612

I think this wasn't new. I've checked mine and here what I found;

 

[Grisu]

same here: https://www.snbforums.com/threads/traffic-monitor-daily-graph-issue.60685/

 

[Gerald Boutin]

I think this wasn't new. I've checked mine and here what I found;

View attachment 20613

Wow, and I thought I had it bad. I've had lots of "random spikes" in the past, but they were much, much smaller numbers. This is the first mega one I have seen.

Looking at the numbers, I do not think this mega-spike is a random number. 2^34 = 17,179,869,184

> Gerald Boutin

 

[RMerlin]

384.14_2 is available for the RT-AC68U, RTAC88U/3100/5300 and RT-AC86U, addressing a few issues specific to these models. Changes since 384.14:

  - FIXED: Missing cifs kernel module
  - FIXED: stubby was linked with OpenSSL 1.0 instead of 1.1
  - FIXED: some routers were reporting the Internet connection being
           disconnected.  If you were affected and you had flashed
           a customized bootloader, then please reflash your original
           bootloader, as your modded bootloader is invalid, and other
           potential issues may appear over time.
  - FIXED: Random traffic spikes logged in Traffic Monitor (regression
           from 384_81351)

 

[omiez]

In the Changelog Merlin mentioned that if we have changed our bootloader we had to go back to the original bootloader to avoid problems.

I never used other then Merlin Firmware. In this case can i ignore the advice and simply flash this new version?

Sorry for the noob question.

 

[Butterfly Bones]

In the Changelog Merlin mentioned that if we have changed our bootloader we had to go back to the original bootloader to avoid problems.

I never used other then Merlin Firmware. In this case can i ignore the advice and simply flash this new version?

Sorry for the noob question.

Yes. Just flash the new version, you are good.

 

[neil0311]

384.14_2 is available for the RT-AC68U, RTAC88U/3100/5300 and RT-AC86U, addressing a few issues specific to these models. Changes since 384.14:

  - FIXED: Missing cifs kernel module
  - FIXED: stubby was linked with OpenSSL 1.0 instead of 1.1
  - FIXED: some routers were reporting the Internet connection being
           disconnected.  If you were affected and you had flashed
           a customized bootloader, then please reflash your original
           bootloader, as your modded bootloader is invalid, and other
           potential issues may appear over time.
  - FIXED: Random traffic spikes logged in Traffic Monitor (regression
           from 384_81351)

Any need to do a factory reset coming from 384.14_0 on a RT-AC86U or can I just flash to 384.14_2?

 

[Centrifuge]

Any need to do a factory reset coming from 384.14_0 on a RT-AC86U or can I just flash to 384.14_2?

Went smooth with no reset for me on 384.14 to 384.14_1 to 384.14_2, manual reboot, thanks a lot Merlin.

 

[Lurkmaster]

Checksum in the distro for 384.14_2 didn't match (?) Maybe I'm doing something wrong in the check. This is on macOS 10.15.2.

tranquility: ~/Routers/Asus/RT-AC86U MERLIN/RT-AC86U_384.14_2
% ls -l
total 154000
-rwxrwxrwx@ 1 ddurfee  staff     51237 Dec 31 19:21 Changelog-NG.txt
-rwxrwxrwx@ 1 ddurfee  staff     10382 Dec 31 19:21 README-merlin.txt
-rw-rw-r--@ 1 ddurfee  staff  78774292 Dec 31 20:20 RT-AC86U_384.14_2_cferom_ubi.w
-rw-rw-r--@ 1 ddurfee  staff        97 Dec 31 20:20 sha256sum.sha256

tranquility: ~/Routers/Asus/RT-AC86U MERLIN/RT-AC86U_384.14_2
% shasum -c -a 512256 sha256sum.sha256             
RT-AC86U_384.14_2_cferom_ubi.w: FAILED
shasum: WARNING: 1 computed checksum did NOT match

 

[Davidncali001]

Checksum in the distro for 384.14_2 didn't match (?) Maybe I'm doing something wrong in the check. This is on macOS 10.15.2.

tranquility: ~/Routers/Asus/RT-AC86U MERLIN/RT-AC86U_384.14_2
% ls -l
total 154000
-rwxrwxrwx@ 1 ddurfee  staff     51237 Dec 31 19:21 Changelog-NG.txt
-rwxrwxrwx@ 1 ddurfee  staff     10382 Dec 31 19:21 README-merlin.txt
-rw-rw-r--@ 1 ddurfee  staff  78774292 Dec 31 20:20 RT-AC86U_384.14_2_cferom_ubi.w
-rw-rw-r--@ 1 ddurfee  staff        97 Dec 31 20:20 sha256sum.sha256

tranquility: ~/Routers/Asus/RT-AC86U MERLIN/RT-AC86U_384.14_2
% shasum -c -a 512256 sha256sum.sha256            
RT-AC86U_384.14_2_cferom_ubi.w: FAILED
shasum: WARNING: 1 computed checksum did NOT match

Are you checking the checksum for the file RT-AC86U_384.14_2_cferom_ubi.w only?

 

[XIII]

DNS over TLS was not working properly for me on 384.14 today. I'm using Cloudflare and apparently they have/had issues today.

What I don't understand is that looking up names of devices on the local network ("nslookup pi") also failed until I switched to another DNS over TLS provider.

Why?

 

[miroco]

Checksum in the distro for 384.14_2 didn't match (?) Maybe I'm doing something wrong in the check. This is on macOS 10.15.2.

tranquility: ~/Routers/Asus/RT-AC86U MERLIN/RT-AC86U_384.14_2
% ls -l
total 154000
-rwxrwxrwx@ 1 ddurfee  staff     51237 Dec 31 19:21 Changelog-NG.txt
-rwxrwxrwx@ 1 ddurfee  staff     10382 Dec 31 19:21 README-merlin.txt
-rw-rw-r--@ 1 ddurfee  staff  78774292 Dec 31 20:20 RT-AC86U_384.14_2_cferom_ubi.w
-rw-rw-r--@ 1 ddurfee  staff        97 Dec 31 20:20 sha256sum.sha256

tranquility: ~/Routers/Asus/RT-AC86U MERLIN/RT-AC86U_384.14_2
% shasum -c -a 512256 sha256sum.sha256           
RT-AC86U_384.14_2_cferom_ubi.w: FAILED
shasum: WARNING: 1 computed checksum did NOT match

I'm also on macOS Catalina 10.15.2

The checksum do match.

6f52ca04a3537bd95994802f57d2f0f53443e10a21426b6c4b7e40e76192957a

 

[Lurkmaster]

Are you checking the checksum for the file RT-AC86U_384.14_2_cferom_ubi.w only?

Yes. Maybe Mac's shasum utility is hosed but that would be odd...

 

[Lurkmaster]

I'm also on macOS Catalina 10.15.2

The checksum do match.

6f52ca04a3537bd95994802f57d2f0f53443e10a21426b6c4b7e40e76192957a

ok. I must be doing it wrong...