[Beta 382] Asuswrt-Merlin 382.2 Beta is now available

[RMerlin]

If the 382.3 Frankenbuild works well, then it means I will be able to completely scrap the 382.2 release, issue a 382.3 release for the RT-AC56U,RT-AC68U and RT-AC3200, then move on to work on 384.4 for everything (but the AC56U and AC3200). That will be one less branch for me to worry about.

 

[charlie2alpha]

If the 382.3 Frankenbuild works well, then it means I will be able to completely scrap the 382.2 release, issue a 382.3 release for the RT-AC56U,RT-AC68U and RT-AC3200, then move on to work on 384.4 for everything (but the AC56U and AC3200). That will be one less branch for me to worry about.

Okies, I'll have some results for you after you wake up, it's already Saturday here

 

[charlie2alpha]

If the 382.3 Frankenbuild works well, then it means I will be able to completely scrap the 382.2 release, issue a 382.3 release for the RT-AC56U,RT-AC68U and RT-AC3200, then move on to work on 384.4 for everything (but the AC56U and AC3200). That will be one less branch for me to worry about.

Hmm, I am not sure, perhaps I am not looking at the right place but the Test Builds in Onedrive has no such build for the AC56U

 

[Zonkd]

Just a heads up: Network Services Filter Blacklist no longer works at all on my AC68U since upgrading from 380.69 to 382.2 Beta 2. I cannot resolve the problem. I tried many factory resets and reintializing and putting all settings in manually and tweaking them. Restoring to 380.69 is the only fix I’ve found to be able to blacklist certain IP addresses from reaching the internet again.

Thanks Eric for all your ongoing efforts for all these years.

 

[Martineau]

Just a heads up: Network Services Filter Blacklist no longer works at all on my AC68U since upgrading from 380.69 to 382.2 Beta 2. .

What does the following show on v380.69?

iptables -nvL --line -t filter | grep NSFW | grep -v Chain;iptables -nvL NSFW --line -t filter

 

[JGrana]

[Beta 382] See reply

Folks, if your interest in 384 is AiMesh, be prepared for many issues...I tried stock Asus 384 on my AC68U and AC88U and I would say it was a frustrating experience getting AiMesh to connect and stay stable.
I applaud Asus for adding this feature but needs more time in the oven ;-)
I am back to Merlins 382.1_2 for now, AC68U back in the closet for another day

 

[Vexira]

There are still models missing from Ai mesh support, I believe once that is sorted out then they will focus on stabilising it. I just hope they add the RP-AC68U to the supported units list.

 

[hifiwifi]

382.3_Alpha1 running fine on ASUS RT-AC1900P. 25 clients with several running through OpenVPN client. Adaptive QOS enabled with manual settings and fq_codel.

EDIT: I have a 1900P, not a 68. Was sleepy when I typed it.

 

[Darcy]

382.3_Alpha1 running fine on ASUS RT-AC68U. 25 clients with several running through OpenVPN client. Adaptive QOS enabled with manual settings and fq_codel.

Upgrading mine right now on my 1900p


Sent from my iPhone using Tapatalk

 

[Darcy]

Seems to be working fine for me


Sent from my iPhone using Tapatalk

 

[TheUntouchable]

Resolves fine for me. Make sure your upstream DNS servers do support DNSSEC, and double check your router's clock.

Thanks a lot for the hints RMerlin, sadly the clock is okay:

Michi@RT-AC88U-DDF0:/tmp/home/root# date
Sat Jan 13 17:22:04 MEZ 2018

Win10 machine:

C:\Users\Michael>time /T
17:22
C:\Users\Michael>date /T
13.01.2018
C:\Users\Michael>tzutil /g
W. Europe Standard Time

I am using the official public google dns servers, so DNSSEC should be supported:

Does Google Public DNS support the DNSSEC protocol?

Yes. Google Public DNS is a validating, security-aware resolver. All responses from DNSSEC signed zones are validated unless clients explicitly set the CD flag in DNS requests to disable the validation.

With dnssec enabled:

Michi@RT-AC88U-DDF0:/tmp/home/root# nslookup web.de
Server:    127.0.0.1
Address 1: 127.0.0.1 localhost.localdomain

nslookup: can't resolve 'web.de'

Without:

Michi@RT-AC88U-DDF0:/tmp/home/root# nslookup web.de
Server:    127.0.0.1
Address 1: 127.0.0.1 localhost.localdomain

Name:      web.de
Address 1: 82.165.230.17 bap.web.de
Address 2: 82.165.229.138 bs.web.de

Do you have any other hint? Already changed the dns server to quad9 (9.9.9.9) which supports dnssec too, but that didn't fix my problem. Which dns servers are you using? Thanks in advance!

EDIT: Found something strange too.. I am using PPPoP and "Respond ICMP Echo (ping) Request from WAN" is set to no. But I can ping my IP Adress.. Thats the reason I got the last past days over 16 massages from trendmicro engine that someone tried to attack my router..

 

[Sanna1967]

I just uploaded an RT-AC56U 382.3 alpha Frankenbuild to the Test Builds folder

There is no build for Ac56 in "Test Folder " on onedrive

Onedrive has no such build for the AC56U

You right

 

[Darcy]

Don’t see a setting on 382.3 so I can connect Alexa


Sent from my iPhone using Tapatalk

 

[RMerlin]

Hmm, I am not sure, perhaps I am not looking at the right place but the Test Builds in Onedrive has no such build for the AC56U

For some reason my NAS lost my Onedrive credentials, so the folder didn't get synced. It should be there in a few mins once it's done resyncing.

Don’t see a setting on 382.3 so I can connect Alexa

Not available for all models.

 

[RMerlin]

Folks, if your interest in 384 is AiMesh, be prepared for many issues...I tried stock Asus 384 on my AC68U and AC88U and I would say it was a frustrating experience getting AiMesh to connect and stay stable.
I applaud Asus for adding this feature but needs more time in the oven ;-)
I am back to Merlins 382.1_2 for now, AC68U back in the closet for another day

And AiMesh doing a lot of settings handling within closed source code, there's a high chance that it might not be fully compatible with all the changes I've done to settings. First thing that I can spot at a first glance at the code is the list of DHCP static leases. I store them in a different format to store hostnames - Asus doesn't. This can possibly break AiMesh support.

If AiMesh is your primary concern, stick with the stock firmware. At best, it will be part of my firmware but will receive ZERO support from me (similar to AP/Repeater/Media Bridge mode). At worst, there's still a chance it might not work correctly - impossible to tell for sure until the code has been actually merged and tested. And no, as I've been saying before, there's no ETA.

That's why I've been saying for months I DON'T have an answer on whether I will support AiMesh or not. I can't answer that until the code has been studied, merged in, AND tested.

 

[RMerlin]

Do you have any other hint?

I don't, sorry. Not really an expert on DNSSEC personally.

 

[skeal]

I don't give a rats behind about AIMesh!

 

[charlie2alpha]

For some reason my NAS lost my Onedrive credentials, so the folder didn't get synced. It should be there in a few mins once it's done resyncing.

Found it and flashed it. The device booted normally, nothing funny in the logs so far. Will keep an eye on it.

 

[charlie2alpha]

@RMerlin unfortunately it didn't take long for the bad news. Adaptive QoS appears non-functional with this build, a simple 'tc filter show dev eth0' command shows absolutely no tc filters or classes configured, totally blank, same goes for the br0 interface.

 

[RMerlin]

@RMerlin unfortunately it didn't take long for the bad news. Adaptive QoS appears non-functional with this build, a simple 'tc filter show dev eth0' command shows absolutely no tc filters or classes configured, totally blank, same goes for the br0 interface.

Could just be the known Adaptive QoS issue that Asus only fixed later on. Try restarting QoS, and give it a good two minutes (it's much slower than with 380.xx at parsing the rules), then check again.