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

[matthew_eli]

Updated on alpha2 2 days ago on my RT-AC86U and, I don't want to say too loudly, but it seems the Wireless Scheduler has been fixed after several versions it was broken...

Ok, I was tasting victory too early: today, after I upgraded the FW to the latest Alpha2 during the WE, the Wireless Scheduler didn't woked as expected and the WiFi stayed on all the night. Mi WiFi scheduler has the following settings:

Monday-Friday: OFF from 1.00 AM to 6.00 AM
All other hours: ON

@RMerlin : just for curiosity, is that issue related to the closed source WiFi components?

 

[KnightRider]

Ok, I was tasting victory too early: today, after I upgraded the FW to the latest Alpha2 during the WE, the Wireless Scheduler didn't woked as expected and the WiFi stayed on all the night. Mi WiFi scheduler has the following settings:

Monday-Friday: OFF from 1.00 AM to 6.00 AM
All other hours: ON

@RMerlin : just for curiosity, is that issue related to the closed source WiFi components?

Factory reset if not done so and confirm functionality again.

 

[matthew_eli]

Factory reset if not done so and confirm functionality again.

I've already done a factory reset when I updated to 384.5 and I manually re-inserted all the settings. I don't want to do it again each version.

 

[skeal]

I've already done a factory reset when I updated to 384.5 and I manually re-inserted all the settings. I don't want to do it again each version.

This is a little note to everyone. If you are not prepared to reset your router to factory defaults and manually reconfigure then do not flash alpha or beta firmware. Specifically not resetting and reporting problems in this thread. It is just nonsensical.
Edit: Spelling.

 

[scjr]

This is a little note to everyone. If you are not prepared to reset your router to factory defaults and manually reconfigure then do not flash alpha or beta firmware. Specifically not resetting and reporting problems in this thread.

This is sound advice.

If having a problem, factory reset is best way to rule out a possible upgrade issue. I can understand folks who have plenty of settings not wanting to reset. It’s a pain, but sometimes it’s the only way to handle odd issues that crop up.

 

[RMerlin]

@RMerlin, does AI protection two way-ips actually provide any security in up-to-date firmware

Yes. For instance it can protect against brute force attacks (I had it blocking repeated connection attempts to a RDesktop forward I had in place for a while).

It doesn't just protect the router, it also protects your LAN devices.

 

[RMerlin]

@RMerlin : just for curiosity, is that issue related to the closed source WiFi components?

No idea. I've never been able to reproduce any issue with the scheduler, and its code is so complicated that I don't even want to waste time trying to make head or tails out of it.

 

[NoSync]

I think the apple devices are designed with apple routers in mind and people fail to realize that.

Those routers aren’t even produced anymore. No, it’s just buggy WiFi.

 

[Broken Hope]

I currently have 6 Apple devices connected to my AC86U and no problems with any of them..

 

[oso2276]

also seeing this with the two apple devices we have on wifi on the alpha build (AC86U). Apps report that there is no net access and yet the devices report being connected to the AP with strong signal. No issue with the previous 384.5 stable. Yes have turned off the usual wifi beamforming etc suspects

cheers

What IOS version. I have 3 devices and different versions. One of them with the latest beta. And an older device with legacy software.
Ensure you have G/N/AC enabled. For 2.4 band use up to 20 wide channel

Have you tried to forget your WiFi network in your Apple devices and reconnect them? If you haven’t, that might be worth a try.

Yup, that it what I usually do.

Enviado desde mi Moto G (5) Plus mediante Tapatalk

 

[barkmann]

sheepishly; I had posted before I performed an initialisation - which resolved the fruity issue. Thanks for everyone's input.

 

[LiFePO4]

AC-86U updated to A2 and running fine for over a week. Comcast on the other hand not so much.

 

[RMerlin]

I loaded new alpha 2 revision (g5b076fc87) over previous version. RT-AC1900P. Smooth upgrade and no issues.

Just an observation under Tools/Sys Info and this has nothing to do with Merlin. I noticed the driver version date changed from the previous alpha.

Previous alpha 2 build: wl0: May 31 2018 13:48:59 version 6.37.14.126 (r561982)

New alpha 2 build: wl0: May 27 2018 15:12:06 version 6.37.14.126 (r561982)

This is just the date Asus compiled it for inclusion in the GPL archive. That May 27th build is what's in 21045 GPL drop from them.

 

[LostFreq]

@RMerlin Since you enabled netstat -p support, it would be very useful to be able to use that option on the Network Tools - Netstat page. Maybe use it by default with all other options, or you could add an 'Extended option' dropdown for it, similar to what you have with the Netstat-nat method?

384.6_alpha2-g5b076fc87 is running fine on my RT-AC86U.

 

[scjr]

This is just the date Asus compiled it for inclusion in the GPL archive. That May 27th build is what's in 21045 GPL drop from them.

Thanks for the explanation.

3 days uptime on g5b076fc87 and everything running smoothly. Thanks for all your hard work. Much appreciated.

 

[penguin22]

@RMerlin I'm not sure if this is new to 384.6, however I did a full reset last night without restoring configuration due to my SmartThings hub refusing to connect to it's servers. I went step by step loading things manually, confirming config each part of the way.

1. LAN DHCP Manual Assignments
2. VPN Client (with Policy Routes forcing some clients to WAN) (DNS config set to Strict for AB-Solution & dnscrypt functionality)
3. amtm (install in this order: AB-Solution; pixelserv-tls *installs entware; dnscrypt [Auto select, support DNSSEC]; Skynet)

At this point the SmartThings hub was still connected and functioning through each step; No DNS leaks with dnscrypt running, but one setting that I changed last was enabling support for DNSSEC in LAN under DHCP. This has been enabled without loss of connectivity in 384.5 and earlier, but with this being the last change, I started seeing the following in log frequently:

Jul  3 08:04:39 admin1: Warning: dnscrypt-proxy is not responding
Jul  3 08:04:39 dnscrypt-proxy[17914]: Stopped.
Jul  3 08:04:39 admin1: Start dnscrypt-proxy

Within an hour of the config (at 1:44 AM), SmartThings lost connection, but all other clients appear to function fine; this morning (at 8:05 AM) I disabled DNSSEC in LAN and no longer see the service stopping for the past ~30 minutes and SmartThings connected right away.

I have AIProtection off for now as I am looking for ~12 hours stability between major function configurations, however wanted to pass along this finding and see if you were aware of a change in DNSSEC behavior.

 

[Zastoff]

@RMerlin I'm not sure if this is new to 384.6, however I did a full reset last night without restoring configuration due to my SmartThings hub refusing to connect to it's servers. I went step by step loading things manually, confirming config each part of the way.

1. LAN DHCP Manual Assignments
2. VPN Client (with Policy Routes forcing some clients to WAN) (DNS config set to Strict for AB-Solution & dnscrypt functionality)
3. amtm (install in this order: AB-Solution; pixelserv-tls *installs entware; dnscrypt [Auto select, support DNSSEC]; Skynet)

At this point the SmartThings hub was still connected and functioning through each step; No DNS leaks with dnscrypt running, but one setting that I changed last was enabling support for DNSSEC in LAN under DHCP. This has been enabled without loss of connectivity in 384.5 and earlier, but with this being the last change, I started seeing the following in log frequently:

Jul  3 08:04:39 admin1: Warning: dnscrypt-proxy is not responding
Jul  3 08:04:39 dnscrypt-proxy[17914]: Stopped.
Jul  3 08:04:39 admin1: Start dnscrypt-proxy

Within an hour of the config (at 1:44 AM), SmartThings lost connection, but all other clients appear to function fine; this morning (at 8:05 AM) I disabled DNSSEC in LAN and no longer see the service stopping for the past ~30 minutes and SmartThings connected right away.

I have AIProtection off for now as I am looking for ~12 hours stability between major function configurations, however wanted to pass along this finding and see if you were aware of a change in DNSSEC behavior.

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

 

[Lee MacMillan]

This is just the date Asus compiled it for inclusion in the GPL archive. That May 27th build is what's in 21045 GPL drop from them.

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.

 

[penguin22]

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

This was a very valuable find that I somehow missed along the way. I'm curious if enabling DNSSEC will become possible at some point as most clients do support it, however it appears that the SmartThings hub does not. Also interesting is that it causes the dnscrypt service failure as well. Amazing what one little change can do, however it would be advisable to make sure it is noted in the release notes before the official release as the impact could be significant if ignored.

 

[kfp]

This was a very valuable find that I somehow missed along the way. I'm curious if enabling DNSSEC will become possible at some point as most clients do support it, however it appears that the SmartThings hub does not. Also interesting is that it causes the dnscrypt service failure as well. Amazing what one little change can do, however it would be advisable to make sure it is noted in the release notes before the official release as the impact could be significant if ignored.

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