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

[Centrifuge]

I uploaded a few 384.14_1 test builds:

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

Changes since 384.14:

Smooth transition from 384.14 to 384.14_1, thanks.

 

[alk630]

I would check the wifi settings. For instance, Asus recently enabled DFS channels in the US for the RT-AC86U, which might be problematic for some devices. Either disable automatic DFS channel selection, or manually configure a fixed, non-DFS channel (like 36) and see if it helps.

Both pieces of equipment are connected wirelessly on 2.4 GHz only and we are UK based. This channel is fixed on 11 on both routers and we have a relatively clear neighbourhood of surrounding wifi around us, so interference does not seem to figure in the problem. Thank you for your reply though... It's a strange one.

 

[XIII]

FIXED: stubby was linked with OpenSSL 1.0 instead of 1.1

Awesome!

Unfortunately I don’t have time to test this fix this year (=today).

Anyone else who can check whether NextDNS now works correctly?

 

[Xentrk]

I uploaded a few 384.14_1 test builds:

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

Changes since 384.14:

  - 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)

Only affected models were uploaded, as none of these issues affected the RT-AC3200, RT-AC87U or RT-AX88U.

Thank you @RMerlin !! The 384.14 test build works on my AC88U. The update resolved the DNS and Internet Connectivity issues I was experiencing.

 

[BeHappy]

I saw a Stubby fix and that triggered me. I have de-installed Stubby because I use the DNS privacy protocol (dns-over-tls) with the profile set to 'strict'.
Does this replace Stubby or is it better to use Stubby also?

 

[dave14305]

I saw a Stubby fix and that triggered me. I have de-installed Stubby because I use the DNS privacy protocol (dns-over-tls) with the profile set to 'strict'.
Does this replace Stubby or is it better to use Stubby also?

The DNS Privacy feature of the firmware includes Stubby built-in with the firmware. No need to install Stubby separately from Entware.

 

[ech]

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

I can confirm that the traffic spikes are fixed on my AC68U.

 

[kernol]

I uploaded a few 384.14_1 test builds:

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

Changes since 384.14:

  - 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)

Only affected models were uploaded, as none of these issues affected the RT-AC3200, RT-AC87U or RT-AX88U.

Confirmed - all fixed on AC86U Aimesh Router as well as AC5300 Aimesh node - both dirty flashed from 384.14.0 - many thanks {Thumbs Up}

 

[TonyK132]

I just updated from 384.13 to 14_1, and all seems to be working fine. Thanks Merlin!!

 

[Gar]

Are these fixes present in the .15 Alpha? Is an "update" to .14_1 over .15 a good idea?

 

[podkaracz]

What does it mean to flash customized bootloader , and how do i check if my bootlader is in default state?

 

[Asad Ali]

What does it mean to flash customized bootloader , and how do i check if my bootlader is in default state?

In pretty sure your Bootloader is in default state since you don't even know what does it mean to flash a customised Bootloader.

 

[Grisu]

ssh to router and answer to this command should be =0
nvram get ATEMODE

 

[bluzfanmr1]

I uploaded a few 384.14_1 test builds:

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

Changes since 384.14:

  - 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)

Only affected models were uploaded, as none of these issues affected the RT-AC3200, RT-AC87U or RT-AX88U.

Should the Traffic Monitor fix things going forward only or is it supposed to fix the past spikes as well? I have an RT-AC66U_B1 and I still have the past spikes after trying this test build.

 

[Val D.]

Should the Traffic Monitor fix things going forward only or is it supposed to fix the past spikes as well? I have an RT-AC66U_B1 and I still have the past spikes after trying this test build.

Start with a new file. Traffic Monitor just reads the file and adds data to it. It can't fix what was written wrong in the past.

 

[Kingp1n]

I uploaded a few 384.14_1 test builds:

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

Changes since 384.14:

  - 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)

Only affected models were uploaded, as none of these issues affected the RT-AC3200, RT-AC87U or RT-AX88U.

Running new 384_14_1 on RT-AC86U without any issues.

 

[Master3395]

I downgraded from 384.15 alpha1
To see if this would help.

And it seems to have been helping me when i disable ipv6.
When i had ipv6 enabled, it stipped my internet down from over 500 v 500, down to 100 v 100 :/

Could be Cloudflare, that i am using.
Not 100% sure.

Putting my syslog here also: (Link goes to OneDrive) https://1drv.ms/t/s!ApsRMYeICEdk-9Q7AoitXNYs33AKiQ?e=zcpVNZ

When ipv6 is disabled:

When ipv6 is enabled:

I uploaded a few 384.14_1 test builds:

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

Changes since 384.14:

  - 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)

Only affected models were uploaded, as none of these issues affected the RT-AC3200, RT-AC87U or RT-AX88U.

 

[Davidncali001]

Although I had no problems except dnssec wasn't properly validating on the test site i used, the previous version ran great using 384.14 on RT-AC86U.

However with the new test version 384_14_1 on RT-AC86U it worked for a few hours then all my wireless devices including iPhone, PC, etc. had stoped working.

In Windows 10 it said I was connected to the internet and iPhone looks like it didn't have a problem but still no loading of webpages.

On the PC when I tried to connect it kept trying TLS handshake but would ultimately fail and I'd get an error screen.

I tried rebooting the router, unplugging the router and modem for 20 minutes then starting back up, but my devices all would not connect to anything on the internet.

So I re-downloaded 384.14 and reflashed that firmware on my router and now everything is working properly again.

I never experienced this before where the internet would work after flashing the firmware for a few hours then suddenly just stop working.

 

[RMerlin]

However with the new test version 384_14_1 on RT-AC86U it worked for a few hours then all my wireless devices including iPhone, PC, etc. had stoped working.

Zero change to wireless in that build.

$ git log --oneline 384.14-mainline..HEAD
35d1fd1184 (HEAD -> 384.14_x, origin/384.14_x) Updated documentation
9132036d7d rc: log if router is in manufacturing mode at wanduck launch
6c4196a268 rstats: revert some of the 384_81044 changes in an attempt to resolve the traffic spikes
73c8e86ace rc: fail wanduck (and possibly other services) failing to start due to ate_mode check
8d832c2cbb getdns: provide explicit path to OpenSSL 1.1.1 (fixes regression fom GPL 81044 merge)
2b0654c7d9 Bumped revision to 384.14_1

 

[Davidncali001]

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.