[Thread-1] [ 386.1_Alpha Build(s) ] Testing available build(s)

[juched]

This makes sense, STP=Enable : https://en.wikipedia.org/wiki/Spanning_Tree_Protocol
If it wasn't the default, every switch would have to be managed, and AiMesh would need a LOT more config/oversight

Spanning Tree Protocol is an algorithm to detect and mitigate loops in the network. This is typically pretty rare as you would need to hook up a cable to create a loop, which doesn't normally happen. Now with AiMesh it create a second wireless connection between nodes so STP can be helpful. However with "Ethernet Backhaul" enabled and cables which are laid out in my house STP will not find a loop. I was surprised that STP being disabled would cause a problem. It is just more network traffic which shoulnd't accomplish anything.

But, I guess the AIMesh needs it. Turning it on isn't a big deal, I agree. It is on by default.

 

[kgorilla]

Thanks Merlin. Long time user, first time poster.

Using the alpha 2 on my ax56u and working fairly good after hard power cycle following factory reset after loading firmware. Oddly enough some custom device names in the client list have persisted. I got aimesh to work with a ac66u b1 after adding via WiFi then switching to ethernet.

Do want to report a problem that it appears dns filter works to assign a client to a server but it does not work to override client specified dns. I tried multiple variations of Router, etc and it doesn't work. Is this a change in using stubby on 386 and not using it in 384? Easy to replicate this issue.

Thanks so much!

 

[dave14305]

Do want to report a problem that it appears dns filter works to assign a client to a server but it does not work to override client specified dns. I tried multiple variations of Router, etc and it doesn't work. Is this a change in using stubby on 386 and not using it in 384? Easy to replicate this issue.

DNSFilter client rules are based on MAC address. Has the MAC address changed, or is the device connecting through another AP that would hide the real MAC address? Maybe a side-effect of AiMesh? I only have one router so I’m guessing there.

 

[kgorilla]

DNSFilter client rules are based on MAC address. Has the MAC address changed, or is the device connecting through another AP that would hide the real MAC address? Maybe a side-effect of AiMesh? I only have one router so I’m guessing there.

Interesting thought, but I doubt it, since I can assign a service (manually, Clean browsing, ad guard) whatever via the DNSFilter UI and it works as expected, but does not override I don't think it is mac address related. I have a AC68U on 384.19 working on a different WAN and the big difference I see is stubby config on 386.

Expected behavior: A client on the LAN hardcoded DNS server will be forced to the Router DNS by configuring DNSFilter to use a specific Global filter.
Actual behavior: A client on the LAN can specify a DNS server and global filter is bypassed.

 

[dave14305]

Interesting thought, but I doubt it, since I can assign a service (manually, Clean browsing, ad guard) whatever via the DNSFilter UI and it works as expected, but does not override I don't think it is mac address related. I have a AC68U on 384.19 working on a different WAN and the big difference I see is stubby config on 386.

Expected behavior: A client on the LAN hardcoded DNS server will be forced to the Router DNS by configuring DNSFilter to use a specific Global filter.
Actual behavior: A client on the LAN can specify a DNS server and global filter is bypassed.

What is your test you’re running from the client? Stubby doesn’t really come into play in DNSFilter, but I’m not sure what you see that makes you mention it twice.

Also check your underlying iptables rules:

iptables -t nat -nvL DNSFILTER

 

[L&LD]

You need to set DNSFiler to Router.

Abs the DNS it will use is specified on the WAN DNS settings page.

 

[kgorilla]

I appreciate all the help, and correct, stubby is because of the dnssec, my mistake there bad observation.
Regarding the actual problem though, this is easy to reproduce, is it just me?

AX56U:
Set WAN DNS to something like Ad Guard Family: 94.140.14.15
Configure client to use DNS of Router IP (I'm using DHCP, but it shouldn't matter, this works as expected)
DNSFilter Set to Router
Browse to adult site: Ad Guard Page Displayed (Working as expected)
** Now make a change
On Client only, specify a DNS like Google or Quad9 (8.8.8.8 or 9.9.9.9).
Browse to adult site: Reaches Adult Site


I have another router AC68U at a different location on 384.19 and my settings pages are exactly the same.

 

[L&LD]

This may be an issue with the AX router then?

 

[dave14305]

I appreciate all the help, and correct, stubby is because of the dnssec, my mistake there bad observation.
Regarding the actual problem though, this is easy to reproduce, is it just me?

AX56U:
Set WAN DNS to something like Ad Guard Family: 94.140.14.15
Configure client to use DNS of Router IP (I'm using DHCP, but it shouldn't matter, this works as expected)
DNSFilter Set to Router
Browse to adult site: Ad Guard Page Displayed (Working as expected)
** Now make a change
On Client only, specify a DNS like Google or Quad9 (8.8.8.8 or 9.9.9.9).
Browse to adult site: Reaches Adult Site


I have another router AC68U at a different location on 384.19 and my settings pages are exactly the same.

Run the iptables command in my previous post to see if the rules are even being created. If it’s a bug, you need to provide some debugging info.

 

[kgorilla]

Just powered off my AiMesh node to rule it out, same issue. Oddly enough, client is getting DHCP hard wired doesn't seem to exhibit the same behavior, it seems to work... Maybe WiFi only problem somehow?

 

[kgorilla]

Here's the iptables command, actually looks fine to me:

admin@RT-AX56U-BA78:/tmp/home/root# iptables -t nat -nvL DNSFILTER
Chain DNSFILTER (2 references)
pkts bytes target prot opt in out source destination
0 0 DNAT all -- * * 0.0.0.0/0 0.0.0.0/0 MAC 3C:F0:11:4A:B6:A9 to:9.9.9.9
2506 164K DNAT all -- * * 0.0.0.0/0 0.0.0.0/0 to:192.168.1.2

 

[dave14305]

Here's the iptables command, actually looks fine to me:

admin@RT-AX56U-BA78:/tmp/home/root# iptables -t nat -nvL DNSFILTER
Chain DNSFILTER (2 references)
pkts bytes target prot opt in out source destination
0 0 DNAT all -- * * 0.0.0.0/0 0.0.0.0/0 MAC 3C:F0:11:4A:B6:A9 to:9.9.9.9
2506 164K DNAT all -- * * 0.0.0.0/0 0.0.0.0/0 to:192.168.1.2

What is 192.168.1.2 on your network? Is something populated in LAN DHCP DNS 1?

 

[kgorilla]

192.168.1.2 is my router's LAN IP.

My LAN DHCP DNS1 is 192.168.1.2 on the client side. On the config I have both fields blank and Advertise router's IP in addition to user-specified DNS set to Yes.

 

[Smokey613]

Maybe it's almost time to upgrade from my much loved AC86U

Nah......

 

[dave14305]

On Client only, specify a DNS like Google or Quad9 (8.8.8.8 or 9.9.9.9).
Browse to adult site: Reaches Adult Site

What browser? One that will "auto-upgrade" you to DNS-over-HTTPS if the OS's DNS resolver supports it (i.e. Chrome)? I don't have much more to say since I'm not running 386.1 alpha, but these days there are a lot of circumventions for DNS blocking methods, all in the name of freedom.

 

[kgorilla]

Primarily tested using ms edge for android.

 

[RMerlin]

Yes, I noticed that too on my AX88U after resetting to factory default the MTU value is blank.

That's how Asus implemented it. If the field is empty (or equal to 0), then the default MTU will be used.

 

[kgorilla]

What browser? One that will "auto-upgrade" you to DNS-over-HTTPS if the OS's DNS resolver supports it (i.e. Chrome)? I don't have much more to say since I'm not running 386.1 alpha, but these days there are a lot of circumventions for DNS blocking methods, all in the name of freedom.

Problem is, when it works as expected using clean browsing or ad guard it does resolve to a pretty access denied page. That is behavior I'm trying to get. I appreciate all the help and I wish I could identify some root cause. All the iptables and Nat rules appear in order.

 

[bluepoint]

That's how Asus implemented it. If the field is empty (or equal to 0), then the default MTU will be used.

So I get it that a PPOE connection should defaults to 1492 MTU and DHCP to 1500, interesting.

 

[bluepoint]

https://onedrive.live.com/?authkey=!AGY2taGX02nVmWA&id=CCE5625ED3599CE0!1427&cid=CCE5625ED3599CE0

NEW ALPHA BUILDS date (2020-11-03)

Available build(s)
RT-AC3100
RT-AC5300
RT-AC68U
RT-AC86U
RT-AC88U
RT-AX56U
RT-AX88U

386.1 (xx-xx-xxxx)
Switched to the new 386 codebase. Models are going to
gradually be re-added to this new code base.
386 introduces AiMesh 2.0, finalizes the move to
OpenSSL 1.1.1 firmware-wide, adds a new speedtest
(powered by Ookla). For more details, please refer
to Asus's own release notes.

- NOTE: For developers, note that firmware code is
once again back on the master branch, with
both mainline and ax being reunified again.

- NEW: Added stub and stub-v2 compression options to OpenVPN
clients. Not added to server, since compression is
considered deprecated, and will be removed most likely
in OpenVPN 2.6, for security reasons.
- NEW: Added tls-crypt-v2 support to OpenVPN clients.
- UPDATED: Merged GPL 386_40577 (beta GPL from Asus).
- UPDATED: Openssl to 1.1.1h.
- UPDATED: Updated to OpenVPN 2.5.0. Note that OpenVPN
2.4.0 or newer is now required by the exported
client config file.
- UPDATED: nano to 5.2.
- UPDATED: curl to 7.72.0.
- UPDATED: zlib to 1.2.11.
- UPDATED: lz4 to 1.9.2.
- UPDATED: e2fsprogs to 1.45.6.
- CHANGED: firmware update checks are no longer using the
server address stored in nvram, for security
purposes. Devs who were using that nvram
should instead edit the webs_scripts/* to
use their own URL.
- CHANGED: The old legacy cipher setting is now only available
when running with static key authentication.
- CHANGED: Tweaks to the OpenVPN webui layout
- CHANGED: OpenVPN clients will now NAT all outbound traffic,
regardless of the source subnet.
- CHANGED: Reworked the display of DNSPrivacy presets
- CHANGED: Added AdGuard (ad blocking) and CIRA Canadian Shield
(non US-based service) to the DNSPrivacy presets.
- CHANGED: At boot time, OpenVPN killswitch will only be
applied for clients set to auto-start with WAN.
- CHANGED: Increased number of available mount points for addon
webpages to 20.
- FIXED: DHCP could fail to renew its lease with some ISPs when
Trend Micro engine was enabled (workaround provided
by Asus)
- REMOVED: Option to disable NCP. The NCP cipher list is
now used both for NCP and non-NCP endpoints.
- REMOVED: fq_codel support for Adaptive QoS. Due to a change
in how Trend Micro configures QoS, it is no longer
possible to intercept these to inject fq_codel.

You can add RT-AX86U as a supported model. I see an alpha 3 build for ax86u now.