[Beta] Asuswrt-Merlin 384.7 Beta is now available

[cristobal07]

bug fix confirmed. thumbs up, thank you Merlin.

Oct  1 13:05:20 start_ddns: update WWW.TUNNELBROKER.NET default@tunnelbroker.net, wan_unit 0
Oct  1 13:05:21 inadyn[726]: In-a-dyn version 2.5 -- Dynamic DNS update client.
Oct  1 13:05:21 inadyn[726]: Update forced for alias xxxxxx (tunnel id), new IP# xx.xx.xx.xx

 

[GaselK]

@RMerlin i purchased an Asus RT-AC86U (in Europe) and they send me an Asus RT-AC2900 (official Europe model).
From Asus confirmation letter here https://www.smallnetbuilder.com/wir...86u-dual-band-ac2900-wireless-router-reviewed RT-AC86U and RT-AC2900 are virtually the same. I also tried Asus Official Fw for RT-AC86U and it flashed with no problem in my RT-AC2900. The webui still shows RT-AC2900 though.
So, can i flash RT-AC86U version of you firmware in my RT-AC2900 ? (even if RT-AC2900 not specifically mentioned, or there is a brick danger ?)
Thank you !

 

[Grisu]

@RMerlin i purchased an Asus RT-AC86U (in Europe) and they send me an Asus RT-AC2900 (official Europe model).
From Asus confirmation letter here https://www.smallnetbuilder.com/wir...86u-dual-band-ac2900-wireless-router-reviewed RT-AC86U and RT-AC2900 are virtually the same. I also tried Asus Official Fw for RT-AC86U and it flashed with no problem in my RT-AC2900. The webui still shows RT-AC2900 though.
So, can i flash RT-AC86U version of you firmware in my RT-AC2900 ? (even if RT-AC2900 not specifically mentioned, or there is a brick danger ?)
Thank you !

Its the same, compare firmware for 2900 and 86U, no differences except name of the file. Name in GUI will be taken from CFE (encrypted bootloader).

 

[RMerlin]

A comment on the WebUi here... using double NAT the DDNS page still mentions "The wireless router currently uses a private WAN IP address. This router may be in the multiple-NAT environment and DDNS service cannot work in this environment." which isn't strictly true anymore.

I need to come up with something better, yes. However a warning is still in order, since things might not still work as expected in a double NAT scenario, as you have to manually forward things on the upstream router, or your ISP might not be allowing port forwards to work, etc...

Additionally if the Lets Encrypt generate cert can only be used by ASUS DDNS service, then shouldn't the radio button for it be removed from other services?

Let's Encrypt does work with other DDNS providers, however it might be unreliable since if your DDNS provider's domain is highly used, Let's Encrypt might throttle your certificate acquisition, possibly indefinitely. This will get logged by the Let's Encrypt client in your system log.

So, can i flash RT-AC86U version of you firmware in my RT-AC2900 ? (even if RT-AC2900 not specifically mentioned, or there is a brick danger ?)

If the RT-AC86U firmware from Asus works, then mine will work as well. The model number shown is encoded in your bootloader, so it won't be affected. Same reason why the RT-AC68U, RT-AC68P, RT-AC1900 or RT-AC1900P will always report the correct model, despite all of them using the exact same firmware image.

 

[tomsk]

Let's Encrypt does work with other DDNS providers, however it might be unreliable since if your DDNS provider's domain is highly used, Let's Encrypt might throttle your certificate acquisition, possibly indefinitely. This will get logged by the Let's Encrypt client in your system log

Im not sure my case is one of the connection being throttled... i tried using the lets encrypt service again after the beta3 update but got a similar message to last time... timeout during connect (likely firewall problem)

Oct  1 10:45:23 RT-AC68U-4690 rc_service: httpd 330:notify_rc restart_ddns_le
Oct  1 10:45:23 RT-AC68U-4690 start_ddns: update WWW.NO-IP.COM default@no-ip.com, wan_unit 0
Oct  1 10:45:24 RT-AC68U-4690 inadyn[2313]: In-a-dyn version 2.5 -- Dynamic DNS update client.
Oct  1 10:45:25 RT-AC68U-4690 inadyn[2313]: Update forced for alias xxxxxxx.hopto.org, new IP# xxx.xxx.xxx.xxx
Oct  1 10:45:28 RT-AC68U-4690 inadyn[2313]: Updating cache for xxxxxxx.hopto.org
Oct  1 10:45:52 RT-AC68U-4690 kernel: /usr/sbin/acme-client: https://acme-v01.api.letsencrypt.org/acme/challenge/-3eLv1MJxMovUrj-FPfOtLG_gEoGwYEVMCW4FWpwfdM/7844510609: bad response
Oct  1 10:45:52 RT-AC68U-4690 kernel: /usr/sbin/acme-client: transfer buffer: [{ "type": "http-01", "status": "invalid", "error": { "type": "urn:acme:error:connection", "detail": "Fetching http://xxxxxxx.hopto.org/.well-known/acme-challenge/5ZjUSXTkBVgYxu2Bk0x6qpbgmvqJMJuse4zqUaETfYQ: Timeout during connect (likely firewall problem)", "status": 400 }, "uri": "https://acme-v01.api.letsencrypt.org/acme/challenge/-3eLv1MJxMovUrj-FPfOtLG_gEoGwYEVMCW4FWpwfdM/7844510609", "token": "5ZjUSXTkBVgYxu2Bk0x6qpbgmvqJMJuse4zqUaETfYQ", "validationRecord": [ { "url": "http://xxxxxxx.hopto.org/.well-known/acme-challenge/5ZjUSXTkBVgYxu2Bk0x6qpbgmvqJMJuse4zqUaETfYQ", "hostname": "xxxxxxx.hopto.org", "port": "80", "addressesResolved": [ "xxx.xxx.xxx.xxx" ], "addressUsed": "xxx.xxx.xxx.xxx" } ] }] (783 bytes

Is there an issue trying to use lets encrypt behind double NAT?.... i don't have any weird firewall rules applied.

 

[Alfsu]

AC86U upgraded from beta2... The previous custom ddns set up worked, no error messages.
However, on reboot these messages appeared in the log, and I don't recall ever seeing them before:

May 5 08:05:19 lldpd[987]: could not open either /etc/os-release or /usr/lib/os-release
May 5 08:05:19 lldpd[987]: lsb_release information not available
May 5 08:05:19 lldpd[990]: created chroot directory /var/run/lldpd
May 5 08:05:19 lldpd[990]: /etc/localtime copied to chroot
May 5 08:05:19 lldpd[990]: protocol LLDP enabled
May 5 08:05:19 lldpd[990]: protocol CDPv1 disabled
May 5 08:05:19 lldpd[990]: protocol CDPv2 disabled
May 5 08:05:19 lldpd[990]: protocol SONMP disabled
May 5 08:05:19 lldpd[990]: protocol EDP disabled
May 5 08:05:19 lldpd[990]: protocol FDP disabled
May 5 08:05:19 lldpd[990]: libevent 2.0.21-stable initialized with epoll method
May 5 08:05:20 lldpd[990]: cannot get ethtool link information with GLINKSETTINGS (requires 4.9+): Operation not permitted
May 5 08:05:20 lldpcli[988]: lldpd should resume operations
May 5 08:05:20 lldpd[990]: custom TLV op replace oui f8:32:e4 subtype 3
May 5 08:05:20 lldpd[990]: custom TLV op replace oui f8:32:e4 subtype 3
May 5 08:05:20 lldpd[990]: custom TLV op replace oui f8:32:e4 subtype 3
May 5 08:05:20 lldpd[990]: custom TLV op replace oui f8:32:e4 subtype 3
May 5 08:05:20 lldpd[990]: custom TLV op replace oui f8:32:e4 subtype 3
May 5 08:05:20 lldpd[990]: custom TLV op replace oui f8:32:e4 subtype 3
May 5 08:05:20 lldpd[990]: custom TLV op replace oui f8:32:e4 subtype 3
May 5 08:05:20 lldpd[990]: custom TLV op replace oui f8:32:e4 subtype 3
May 5 08:05:20 lldpd[990]: custom TLV op replace oui f8:32:e4 subtype 3
May 5 08:05:20 lldpd[990]: custom TLV op replace oui f8:32:e4 subtype 2
May 5 08:05:20 lldpd[990]: custom TLV op replace oui f8:32:e4 subtype 2
May 5 08:05:20 lldpd[990]: custom TLV op replace oui f8:32:e4 subtype 2
May 5 08:05:20 lldpd[990]: custom TLV op replace oui f8:32:e4 subtype 2
May 5 08:05:20 lldpd[990]: custom TLV op replace oui f8:32:e4 subtype 2
May 5 08:05:20 lldpd[990]: custom TLV op replace oui f8:32:e4 subtype 2
May 5 08:05:20 lldpd[990]: custom TLV op replace oui f8:32:e4 subtype 2
May 5 08:05:20 lldpd[990]: custom TLV op replace oui f8:32:e4 subtype 2
May 5 08:05:20 lldpd[990]: custom TLV op replace oui f8:32:e4 subtype 2
May 5 08:05:21 lldpd[990]: custom TLV op replace oui f8:32:e4 subtype 3
May 5 08:05:21 lldpd[990]: custom TLV op replace oui f8:32:e4 subtype 3
May 5 08:05:21 lldpd[990]: custom TLV op replace oui f8:32:e4 subtype 3
May 5 08:05:21 lldpd[990]: custom TLV op replace oui f8:32:e4 subtype 3
May 5 08:05:21 lldpd[990]: custom TLV op replace oui f8:32:e4 subtype 3
May 5 08:05:21 lldpd[990]: custom TLV op replace oui f8:32:e4 subtype 3
May 5 08:05:21 lldpd[990]: custom TLV op replace oui f8:32:e4 subtype 3
May 5 08:05:21 lldpd[990]: custom TLV op replace oui f8:32:e4 subtype 3
May 5 08:05:21 lldpd[990]: custom TLV op replace oui f8:32:e4 subtype 3
May 5 08:05:21 lldpd[990]: custom TLV op replace oui f8:32:e4 subtype 2
May 5 08:05:21 lldpd[990]: custom TLV op replace oui f8:32:e4 subtype 2
May 5 08:05:21 lldpd[990]: custom TLV op replace oui f8:32:e4 subtype 2
May 5 08:05:21 lldpd[990]: custom TLV op replace oui f8:32:e4 subtype 2
May 5 08:05:21 lldpd[990]: custom TLV op replace oui f8:32:e4 subtype 2
May 5 08:05:21 lldpd[990]: custom TLV op replace oui f8:32:e4 subtype 2
May 5 08:05:21 lldpd[990]: custom TLV op replace oui f8:32:e4 subtype 2
May 5 08:05:21 lldpd[990]: custom TLV op replace oui f8:32:e4 subtype 2
May 5 08:05:21 lldpd[990]: custom TLV op replace oui f8:32:e4 subtype 2

Messages no longer appeared after time was synchronized.
Any thing to be worried about?

 

[JacquesR]

Beta 3 running fine on my AC86U - DNSomatic in use, with a custom host name. Have successfully tested the IPsec VPN server and a VPN client too.

 

[telUK]

You guy's that have been running the alpha and betas of 384.7 how has wifi been.

I still get the odd random drop out on wifi, its rare, but tonight for example I had about 3 dropouts in the space of 20 minutes.
This was on the 5ghz band.

 

[ankhazam]

no-ip.com reg works good

 

[GoNz0]

dnsomatic working fine here

 

[skeal]

You guy's that have been running the alpha and betas of 384.7 how has wifi been.

I still get the odd random drop out on wifi, its rare, but tonight for example I had about 3 dropouts in the space of 20 minutes.
This was on the 5ghz band.

I have never had any issues with wifi with my router and any RMerlin f/w. Just remember to accurately compare to another release, one must factory reset and manually config back to normal. No importing of saved settings.

Edit: Grammar

 

[RMerlin]

Timeout during connect (likely firewall problem)

Probably caused by Double NAT indeed, Let's Encrypt seem unable to validate your identity.

 

[Nimloth]

Can compress lz4-v2 be added for final version in OpenVPN ?
Yes, I can use Custom Configuration and it works ... but since there is Compression option so would be nice to utilize it in 100%

And yes current build support it:
Mon Oct 1 20:10:09 2018 us=871773 LZ4v2 compression initializing

 

[RMerlin]

However, on reboot these messages appeared in the log, and I don't recall ever seeing them before:

lldpd is used for AiMesh, so just ignore these messages. No idea personally what they even mean...

 

[RMerlin]

Can compress lz4-v2 be added for final version in OpenVPN ?
Yes, I can use Custom Configuration and it works ... but since there is Compression option so would be nice to utilize it in 100%

And yes current build support it:
Mon Oct 1 20:10:09 2018 us=871773 LZ4v2 compression initializing

Is it standard? I never saw any reference to it in the OpenVPN man page.

 

[Nimloth]

Is it standard? I never saw any reference to it in the OpenVPN man page.

Yes, it is ... just documentation not updated

https://community.openvpn.net/openvpn/ticket/820

Output from AsusWRT as client (supported settings):

peer info: IV_VER=2.4.6
peer info: IV_PLAT=linux
peer info: IV_PROTO=2
peer info: IV_LZ4=1
peer info: IV_LZ4v2=1
peer info: IV_LZO=1
peer info: IV_COMP_STUB=1
peer info: IV_COMP_STUBv2=1
peer info: IV_TCPNL=1

 

[RMerlin]

Yes, it is ... just documentation not updated

https://community.openvpn.net/openvpn/ticket/820

Output from AsusWRT as client (supported settings):

I find it odd that after so many months it's still not documented yet, maybe because it's still considered experimental by the OpenVPN devs.

In any case, that kind of changes would require proper testing - it is too late to add that in 384.7 since the focus is currently on validating there are no major issues left around the new DDNS implementation before a final release. I will re-evaluate this with 384.8.

 

[Freddi]

You guy's that have been running the alpha and betas of 384.7 how has wifi been.

I still get the odd random drop out on wifi, its rare, but tonight for example I had about 3 dropouts in the space of 20 minutes.
This was on the 5ghz band.

I've had really good luck on this version, alpha's and beta's. I was having problems with limited slots for 2.4Ghz before, but both 2.4G and 5G have been flawless for me. BUT, I also started from a fresh NVRAM, and followed the recommendations from others for settings on those bands at the same time. (Disabling airtime fairness, and beam forming, etc) Because I didn't do those separately, I can't tell you which helped, or if it was a combination of firmware and settings. (I just wanted it fixed!)

 

[Treadler]

You guy's that have been running the alpha and betas of 384.7 how has wifi been.

I still get the odd random drop out on wifi, its rare, but tonight for example I had about 3 dropouts in the space of 20 minutes.
This was on the 5ghz band.

Totally fine here......

 

[tomsk]

Probably caused by Double NAT indeed, Let's Encrypt seem unable to validate your identity.

If being in a double NAT situation is indeed the culprit, is it possible to build a workaround into the firmware so that it works for the supported ddns providers?. Its such a shame that, having introduced the external method of retrieving the WAN IP, that https can't be used without importing your own cert.
If not, then perhaps the Lets Encrypt radio button should be removed for double NAT conditions, saving you a lot of time with support questions from those in double NAT/CGNAT conditions when they try to generate a cert.
Not trying to be picky here, and i think you have done a fantastic job on updating the ddns functionality, but that would really be the icing on the cake.