[Preview] Early Asuswrt-Merlin 384.6 test builds are available

[penguin22]

I don’t think that’s the correct conclusion to draw although I think both symptoms you’re observing are both due to the recently enabled strict checking of dnssec.

Your SmartThings hub is not working simply because the DNs lookups failed (because it’s querying a custom DNS server instead of using the router supplied one?) You can look further into this.

As for dnscrypt-proxy, it probably fails to start because it is using doing some initial checks and perhaps the change in dnsmasq broke it, but that’s the direction I’d go for further troubleshooting.

I’m not sure what you mean by “noted in the release notes”, these are alpha versions of the firmware exactly for the purpose of working out kinks like this. Ideally it should be resolved before release and noted only if there’s is some limitation stopping it from being fixed.

It’ll be cool if you can look further into your SmartHub and also figure out why dnscrypt-proxy is failing to start (more verbose logging maybe)?

From the logging I was seeing SmartThings performing queries, but never getting a response. These were going to the router, which is advertised as the DNS server, so it's not clear why the response was not being received unless it was ignored. My client could lookup the same entry and resolve.

I'm aware that the alpha version is for finding these kinks. If the DNSSEC changes will persist, it is at that time that it would be noted, otherwise reverting to non-enforced (or opportunistic) DNSSEC would be the recommended approach.

 

[kfp]

From the logging I was seeing SmartThings performing queries, but never getting a response. These were going to the router, which is advertised as the DNS server, so it's not clear why the response was not being received unless it was ignored. My client could lookup the same entry and resolve.

From the logging where? On the SmartThings or the router? Is this the dnsmasq logs or dnscrypt-proxy logs?

 

[RMerlin]

Two questions: I'm running the 21045 Asus firmware on my AC66U B1. So the May 27th build is based on the latest Asus firmware? And I should use the AC68U build? Thanks.

That's the date Asus compiled the driver, not the date of the firmware release.

If you don't know yet which build to flash for your model, then I strongly advise against jumping in on an early alpha build. These builds are not for first-time users.

 

[Lee MacMillan]

That's the date Asus compiled the driver, not the date of the firmware release.

If you don't know yet which build to flash for your model, then I strongly advise against jumping in on an early alpha build. These builds are not for first-time users.

I will take your advice!

 

[JohnSmith]

As per https://www.snbforums.com/threads/r...4-5-is-now-available.46575/page-5#post-405043 , I have upgrade my AC3100 to 384.6_alpha2-g5b076fc87 and it seems to have fixed the following problems:

- the Traffic Monitor WAN Tab shows these spikes, on a regular basis. (FIXED)

- Small cosmetic issue, but still noticing that the "Client Status" or the "View List" is showing all of my Wireless clients as being Wired again. When you export the client list to CSV, all of my Wireless clients show values in "TX" and "RX" columns but the "Interface" Column all shows "Wired" (FIXED)


(To Be Determined - will report back in a couple of days)
- The "Traffic Analyzer" Tab, under "Traffic Monitor", if you choose "Daily", it seems the "Reception" and "Transmission" graphs are both reversed, and the calculations are not correct.

 

[penguin22]

@RMerlin I am happy to report that I am not seeing the frequent network loss that I was on 384.5 with the latest Alpha after a reset. As noted earlier, I did need to disable DNSSEC, however clients were frequently losing network connectivity on the prior version, especially when my son's iOS devices arrived home from school. This was made worse when school ended and he was home more frequently making it occur all the time, seemingly sporadically across devices.

There is a separate thread related to the AC3200 and >10 devices on 2.4 GHz being problematic and possibly also fixed in 384.6 Alpha2 and I am willing to throw my agreement in the hat with using the AC86U (router), AC68P (MB), and AC3200 (AP) all running your latest build with no issue and >30 devices connected. Great job!

 

[darekd]

I'm unable to load alpha version on my AC68U. I've tried both releases of alpha and I'm still showing 384.5.

 

[RMerlin]

I'm unable to load alpha version on my AC68U. I've tried both releases of alpha and I'm still showing 384.5.

Either you downloaded the wrong firmware, or you don't have a real RT-AC68U.

 

[darekd]

Either you downloaded the wrong firmware, or you don't have a real RT-AC68U.

You are right. This is Tmobile AC68U. I also have actual AC68U and the alpha loaded without any problems. Does this mean that alpha and maybe beta can only run on original Asus versions?

 

[kfp]

You are right. This is Tmobile AC68U. I also have actual AC68U and the alpha loaded without any problems. Does this mean that alpha and maybe beta can only run on original Asus versions?

https://www.snbforums.com/threads/faq-read-me-first-before-posting-a-question.47153/

It’s not supported anymore, including future alphas betas and stable releases.

 

[Temchenko]

Hello. Found the bug. If you'll generate profile of OVPN on both alpha versions at AC86U, you'll get profile with port 0. While on 384.5 everything is ok. Only way to have working OVPN is to generate profile at 384.5 and then update to 384.6 alpha.

 

[darekd]

Hello. Found the bug. If you'll generate profile of OVPN on both alpha versions at AC86U, you'll get profile with port 0. While on 384.5 everything is ok. Only way to have working OVPN is to generate profile at 384.5 and then update to 384.6 alpha.

Or you can edit the profile and add the port.

 

[Temchenko]

Or you can edit the profile and add the port.

But it won't change much. Even if I'll edit profile with notepad, ovpn gui can't establish connection. But once I'll create profile on older firmware and flash new alpha - no issues.

 

[PolarBear]

Hello. Found the bug. If you'll generate profile of OVPN on both alpha versions at AC86U, you'll get profile with port 0. While on 384.5 everything is ok. Only way to have working OVPN is to generate profile at 384.5 and then update to 384.6 alpha.

Same here with 384.alpha2-g5b076fc installed on RT-AC86U. Tried to define a non-standard port number in the GUI but this was written to the .opvn file as port 0.

It seems however that the .opvn file can be edited manually to correct the port number, which is much faster than installing 384.5 and then re-installing 386.6-alpha2-g5b076fc.

 

[darekd]

But it won't change much. Even if I'll edit profile with notepad, ovpn gui can't establish connection. But once I'll create profile on older firmware and flash new alpha - no issues.

I just exported a profile from alpha to my iphone (after I modified port) and it works fine.

 

[agilani]

AC88 3 days 19 hours uptime and not a glitch. Not using auto channel selection for 2.4ghz. At this point, without auto channel selection, the new code has been as stable as the old 380.69 code. Even the new franken build

Still having the dhcp issues in the logs over and over, but it doesn't seem to impact functionality. It's happening to a windows machine right now. This is the one that i even replaced the nic card on. I'll be troubleshooting this later today to see if I can get to the bottom of it.

 

[RMerlin]

I just exported a profile from alpha to my iphone (after I modified port) and it works fine.

It depends on your DDNS service. There as a bug introduced by the 21045 GPL merge which is already corrected on my end.

Just manually editing the ovpn file will work as a workaround.

 

[PolarBear]

384.alpha2-g5b076fc on RT-AC86U - running for 4 days with no problems at all. Channels selected manually for both radios.

A few unexplained log entries but apart from that, everything seems to be working fine.

Jul 3 19:54:13 kernel: br0: received packet on eth5 with own address as source address
Jul 3 20:26:05 kernel: br0: received packet on eth5 with own address as source address
Jul 3 20:52:26 kernel: br0: received packet on eth6 with own address as source address
Jul 3 20:52:32 kernel: br0: received packet on eth5 with own address as source address
Jul 3 21:57:30 kernel: br0: received packet on eth5 with own address as source address
Jul 3 22:38:05 kernel: br0: received packet on eth5 with own address as source address
Jul 4 02:56:08 kernel: br0: received packet on eth5 with own address as source address
Jul 4 09:07:27 kernel: br0: received packet on eth5 with own address as source address
Jul 4 10:27:56 kernel: br0: received packet on eth5 with own address as source address
Jul 4 10:48:58 kernel: br0: received packet on eth5 with own address as source address
Jul 4 14:27:42 kernel: br0: received packet on eth5 with own address as source address
Jul 4 14:28:44 kernel: br0: received packet on eth6 with own address as source address
Jul 4 14:29:06 kernel: br0: received packet on eth6 with own address as source address

 

[kfp]

A few unexplained log entries but apart from that, everything seems to be working fine.

Do you torrent and have port forwarding set up?

 

[PolarBear]

Do you torrent and have port forwarding set up?

No, neither. The setup is fairly vanilla, except OVPN server is running.

I have 2 Apple Time Capsules connected by Ethernet, set up as APs. Not sure if that is relevant.