What's new

Beta Asuswrt-Merlin 386.9 beta is now available for AC models

  • SNBForums Code of Conduct

    SNBForums is a community for everyone, no matter what their level of experience.

    Please be tolerant and patient of others, especially newcomers. We are all here to share and learn!

    The rules are simple: Be patient, be nice, be helpful or be gone!

Status
Not open for further replies.
Question: does OVPN in exclusive mode still bypass DNSmasq altogether?
Yes, nothing was changed in the Exclusive mode behaviour.
 
Asuswrt-Merlin 386.9 Beta is now available for all supported Wifi 5 (802.11ac) models. This release focuses on GPL merge and component updates.

Notable changes since the previous release:

  • Merged with GPL 386_50757.
  • Updated components: dnsmasq 2.88, zlib 1.2.12, openssl 1.1.1s, inadyn 2.10, nettle 3.8.1, openvpn 2.5.8 and dropbear 2022.83.
  • Rebranded DNSFilter as DNS Director, to avoid any confusion with the company of the same name. No changes in functionality.
  • Setting an OpenVPN client to redirect all traffic while in "Exclusive" DNS mode will now force redirect ALL DNS traffic just like in VPN Director mode.
  • Self-generated web certificates will now use EC instead of RSA

See the changelog for a more complete list of changes.

Things that will require particular testing is the updated dnsmasq, as all the recent attempts at upgrading it revealed major bugs that forced me to revert back to the previious release. Hopefully this one will prove more stable.

Please keep discussions in this thread on this specific beta release. Off topic posts may be ignored, moved or deleted.


Downloads are here.
Changelog is here.
Trying to understand the VPN DNS change.
Can someone explain in layman’s terms?
 
Trying to understand the VPN DNS change.
Can someone explain in layman’s terms?
If you set DNS mode to Exclusive and you set the VPN client to redirect all traffic, then all your LAN devices will be forced to use the DNS server provided by the VPN, preventing so-called DNS leaks, but also preventing you from doing local hostname resolution (because the router's DNS gets bypassed entirely).
 
If you set DNS mode to Exclusive and you set the VPN client to redirect all traffic, then all your LAN devices will be forced to use the DNS server provided by the VPN, preventing so-called DNS leaks, but also preventing you from doing local hostname resolution (because the router's DNS gets bypassed entirely).
Ok. What if you use VPN Director, set DNS to Exclusive and use DNSFilter/Director for your other LAN devices not pointing to the VPN?
 
Ok. What if you use VPN Director, set DNS to Exclusive and use DNSFilter/Director for your other LAN devices not pointing to the VPN?
There was no change in this beta.

If you need general support on VPN clients, I recommend you start a separate thread.
 
There was no change in this beta.

If you need general support on VPN clients, I recommend you start a separate thread.
No worries.
So does it now override DoT? I believe in previous iterations, using DoT and Exclusive meant DoT took precedence still.
 
Dirty upgrade through alphas to beta, and no anomalies encountered and running well!
Waiting for some personal downtime to exchange my AC88 with my former main AC86, since I don't require the additional ports and the AC86 has updated hw.
 
Dirty upgrade to beta. Running well for 24 hours.

Thanks Merlin. Great work!
 
Code:
Dec 30 06:05:16 dnsmasq[3077]: reducing DNS packet size for nameserver 127.0.1.1 to 1232
Dec 30 07:05:16 dnsmasq[3077]: reducing DNS packet size for nameserver 127.0.1.1 to 1232
Dec 30 08:05:16 dnsmasq[3077]: reducing DNS packet size for nameserver 127.0.1.1 to 1232
Dec 30 09:05:16 dnsmasq[3077]: reducing DNS packet size for nameserver 127.0.1.1 to 1232
Dec 30 10:05:16 dnsmasq[3077]: reducing DNS packet size for nameserver 127.0.1.1 to 1232
Dec 30 11:05:16 dnsmasq[3077]: reducing DNS packet size for nameserver 127.0.1.1 to 1232
Dec 30 12:05:16 dnsmasq[3077]: reducing DNS packet size for nameserver 127.0.1.1 to 1232
Dec 30 13:05:15 dnsmasq[3077]: reducing DNS packet size for nameserver 127.0.1.1 to 1232
Dec 30 14:05:15 dnsmasq[3077]: reducing DNS packet size for nameserver 127.0.1.1 to 1232
Dec 30 15:05:15 dnsmasq[3077]: reducing DNS packet size for nameserver 127.0.1.1 to 1232
Dec 30 16:05:15 dnsmasq[3077]: reducing DNS packet size for nameserver 127.0.1.1 to 1232
Dec 30 17:05:15 dnsmasq[3077]: reducing DNS packet size for nameserver 127.0.1.1 to 1232

Seeing this in the log after dirty upgrade from 386.7_2 to beta. Anything to be worried about?
 
Seeing new entries in my log. Not sure what this means...

Dec 30 09:09:31 bsd: bsd: Sending act Frame to aa:67:bb:97:7d:d5 with transition target eth6 ssid 3c:7c:3f:63:17:04
Dec 30 09:09:31 bsd: bsd: BSS Transit Response: ifname=eth5, event=156, token=96, status=6, mac=34:0d:3c:7c:3f:63
Dec 30 09:09:31 bsd: bsd: BSS Transit Response: not for token 97
Dec 30 09:09:52 bsd: bsd: Sending act Frame to aa:67:bb:97:7d:d5 with transition target eth5 ssid 3c:7c:3f:63:17:00
Dec 30 09:09:52 bsd: bsd: BSS Transit Response: ifname=eth6, event=156, token=5, status=1, mac=00:00:00:00:00:00
Dec 30 09:09:52 bsd: bsd: BSS Transit Response: not for token 98
Dec 30 09:09:52 bsd: bsd: Sending act Frame to aa:67:bb:97:7d:d5 with transition target eth5 ssid 3c:7c:3f:63:17:00
Dec 30 09:09:52 bsd: bsd: BSS Transit Response: ifname=eth6, event=156, token=98, status=0, mac=3c:7c:3f:63:17:00
Dec 30 09:09:52 bsd: bsd: BSS Transit Response: not for token 99
Dec 30 09:13:51 bsd: bsd: Sending act Frame to 9e:a4:9e:28:2c:41 with transition target eth5 ssid 3c:7c:3f:63:17:00
Dec 30 09:13:51 bsd: bsd: BSS Transit Response: ifname=eth5, event=156, token=3, status=1, mac=00:00:00:00:00:00
Dec 30 09:13:51 bsd: bsd: BSS Transit Response: not for interface eth6
Dec 30 09:13:51 bsd: bsd: Sending act Frame to 9e:a4:9e:28:2c:41 with transition target eth5 ssid 3c:7c:3f:63:17:00
Dec 30 09:13:52 bsd: bsd: STA:9e:a4:9e:28:2c:41 no response
Dec 30 09:18:50 kernel: eth4 (Ext switch port: 3) (Logical Port: 11) Link DOWN.
Dec 30 09:18:52 kernel: eth4 (Ext switch port: 3) (Logical Port: 11) Link UP 10 mbps full duplex
Dec 30 09:19:19 kernel: eth4 (Ext switch port: 3) (Logical Port: 11) Link DOWN.
Dec 30 09:19:23 kernel: eth4 (Ext switch port: 3) (Logical Port: 11) Link UP 1000 mbps full duplex
Dec 30 09:33:53 bsd: bsd: Sending act Frame to aa:67:bb:97:7d:d5 with transition target eth6 ssid 3c:7c:3f:63:17:04
Dec 30 09:33:53 bsd: bsd: BSS Transit Response: ifname=eth5, event=156, token=9c, status=6, mac=34:0d:3c:7c:3f:63
Dec 30 09:33:53 bsd: bsd: BSS Transit Response: STA reject
Dec 30 09:33:53 bsd: bsd: Skip STA:aa:67:bb:97:7d:d5 reject BSSID
Dec 30 09:37:47 bsd: bsd: Sending act Frame to aa:67:bb:97:7d:d5 with transition target eth6 ssid 3c:7c:3f:63:17:04
Dec 30 09:37:47 bsd: bsd: BSS Transit Response: ifname=eth5, event=156, token=9d, status=0, mac=3c:7c:3f:63:17:04
Dec 30 09:37:47 bsd: bsd: BSS Transit Response: STA accept
Dec 30 09:42:53 bsd: bsd: Sending act Frame to 9e:a4:9e:28:2c:41 with transition target eth5 ssid 3c:7c:3f:63:17:00
Dec 30 09:42:54 bsd: bsd: STA:9e:a4:9e:28:2c:41 no response
Dec 30 09:42:54 bsd: bsd: Sending act Frame to 9e:a4:9e:28:2c:41 with transition target eth5 ssid 3c:7c:3f:63:17:00
Dec 30 09:42:54 bsd: bsd: BSS Transit Response: ifname=eth6, event=156, token=9f, status=0, mac=3c:7c:3f:63:17:00
Dec 30 09:42:54 bsd: bsd: BSS Transit Response: STA accept
 
Code:
Dec 30 06:05:16 dnsmasq[3077]: reducing DNS packet size for nameserver 127.0.1.1 to 1232

Seeing this in the log after dirty upgrade from 386.7_2 to beta. Anything to be worried about?
Can you find which DNS query is causing this? They would typically be DNSSEC queries as these can potentially return fairly large answers.

It`s not critical since DNS resolves would typically switch to TCP queries when that happens, but it might not be optimal, unless it's just a specific query that's bugging out.
 
Can you find which DNS query is causing this? They would typically be DNSSEC queries as these can potentially return fairly large answers.
How can I do that as far as I was aware my PC's were not querying anything. I can turn DNSSEC off.

Seems to happen at 05 past the hour on a regular basis.
 
Last edited:
What about this one?

Code:
Dec 29 20:37:33 kernel: nf_conntrack: automatic helper assignment is deprecated and it will be removed soon. Use the iptables CT target to attach helpers instead.
Oddly I get this message from an app that I use to scan for open ports and see connected devices (iNet Pro) on iOS Appstore.
 
How can I do that as far as I was aware my PC's were not querying anything. I can turn DNSSEC off.
You can manually launch dnsmasq in query logging mode. Over SSH:

Code:
killall dnsmasq && dnsmasq --log-async --log-queries -d

Then try to spot the moment it will output the same error message, and see which query generated it.

Once done, kill the process by hitting Ctrl-C, then restart dnsmasq normally:

Code:
service restart_dnsmasq
 
Oddly I get this message from an app that I use to scan for open ports and see connected devices (iNet Pro) on iOS Appstore.
This is just a kernel warning that conntrack helpers (such as ct_sip or ct_ftp) will be removed in a future kernel version. This is irrelevant in the router's case since it won't get any kernel upgrade, unlike a server where you might be upgrading to a newer distro.

CT helpers can be disabled on the WAN -> NAT Passthrough page (in fact most of these should already be disabled by default, unless you possibly came from stock firmware and didn`t do a factory default reset, in which case you might be using the stock Asuswrt defaults).
 
You can manually launch dnsmasq in query logging mode. Over SSH:

Code:
killall dnsmasq && dnsmasq --log-async --log-queries -d

Then try to spot the moment it will output the same error message, and see which query generated it.

Once done, kill the process by hitting Ctrl-C, then restart dnsmasq normally:

Code:
service restart_dnsmasq
Code:
dnsmasq: reply settings-prod-neu-2.northeurope.cloudapp.azure.com is 51.104.136.2
dnsmasq: query[A] plex.tv from 192.168.1.119
dnsmasq: forwarded plex.tv to 127.0.1.1
dnsmasq: dnssec-query[DS] tv to 127.0.1.1
dnsmasq: reply tv is DS keytag 2107, algo 8, digest 2
dnsmasq: reply tv is DS keytag 44904, algo 8, digest 2
dnsmasq: dnssec-query[DS] plex.tv to 127.0.1.1
dnsmasq: query[A] plex.tv from 192.168.1.119
dnsmasq: dnssec-retry[DS] plex.tv to 127.0.1.1
dnsmasq: dnssec-query[DNSKEY] tv to 127.0.1.1
dnsmasq: reducing DNS packet size for nameserver 127.0.1.1 to 1232
dnsmasq: reply plex.tv is 34.243.47.112
dnsmasq: reply plex.tv is 52.48.60.59
dnsmasq: reply plex.tv is 52.49.138.125
dnsmasq: reply plex.tv is 18.200.51.241
dnsmasq: query[A] plex.tv from 192.168.1.119
dnsmasq: forwarded plex.tv to 127.0.1.1
dnsmasq: dnssec-query[DS] plex.tv to 127.0.1.1
dnsmasq: validation plex.tv is BOGUS
dnsmasq: reply plex.tv is 34.243.47.112
dnsmasq: reply plex.tv is 52.49.138.125
dnsmasq: reply plex.tv is 18.200.51.241
dnsmasq: reply plex.tv is 52.48.60.59
dnsmasq: query[A] vod.provider.plex.tv from 192.168.1.119
dnsmasq: forwarded vod.provider.plex.tv to 127.0.1.1
dnsmasq: query[A] metadata.provider.plex.tv from 192.168.1.119
dnsmasq: forwarded metadata.provider.plex.tv to 127.0.1.1
dnsmasq: query[A] music.provider.plex.tv from 192.168.1.119
dnsmasq: forwarded music.provider.plex.tv to 127.0.1.1
dnsmasq: dnssec-query[DS] plex.tv to 127.0.1.1
dnsmasq: query[A] vod.provider.plex.tv from 192.168.1.119
dnsmasq: dnssec-retry[DS] plex.tv to 127.0.1.1
dnsmasq: query[A] music.provider.plex.tv from 192.168.1.119
dnsmasq: dnssec-retry[DS] plex.tv to 127.0.1.1
dnsmasq: query[A] metadata.provider.plex.tv from 192.168.1.119
dnsmasq: dnssec-retry[DS] plex.tv to 127.0.1.1
dnsmasq: dnssec-query[DNSKEY] tv to 127.0.1.1
dnsmasq: query[A] analytics.plex.tv from 192.168.1.119
dnsmasq: forwarded analytics.plex.tv to 127.0.1.1
dnsmasq: dnssec-retry[DNSKEY] tv to 127.0.1.1
dnsmasq: reply analytics.plex.tv is 104.18.19.96
dnsmasq: reply analytics.plex.tv is 104.18.18.96
dnsmasq: reply vod.provider.plex.tv is 104.18.18.96
dnsmasq: reply vod.provider.plex.tv is 104.18.19.96
dnsmasq: reply music.provider.plex.tv is 104.18.18.96
dnsmasq: reply music.provider.plex.tv is 104.18.19.96
dnsmasq: reply metadata.provider.plex.tv is 104.18.19.96
dnsmasq: reply metadata.provider.plex.tv is 104.18.18.96
dnsmasq: query[A] analytics.plex.tv from 192.168.1.119
dnsmasq: forwarded analytics.plex.tv to 127.0.1.1
dnsmasq: dnssec-query[DS] plex.tv to 127.0.1.1
dnsmasq: validation analytics.plex.tv is BOGUS
dnsmasq: reply analytics.plex.tv is 104.18.18.96
dnsmasq: reply analytics.plex.tv is 104.18.19.96
dnsmasq: query[A] vod.provider.plex.tv from 192.168.1.119
dnsmasq: forwarded vod.provider.plex.tv to 127.0.1.1
dnsmasq: dnssec-query[DS] plex.tv to 127.0.1.1
dnsmasq: dnssec-query[DS] tv to 127.0.1.1
dnsmasq: reply tv is DNSKEY keytag 53769, algo 8
dnsmasq: reply tv is DNSKEY keytag 35950, algo 8
dnsmasq: reply tv is DNSKEY keytag 44904, algo 8
dnsmasq: reply tv is DNSKEY keytag 2107, algo 8
dnsmasq: reply plex.tv is no DS
dnsmasq: validation result is INSECURE
dnsmasq: reply vod.provider.plex.tv is 104.18.18.96
dnsmasq: reply vod.provider.plex.tv is 104.18.19.96
dnsmasq: query[A] metadata.provider.plex.tv from 192.168.1.119
dnsmasq: forwarded metadata.provider.plex.tv to 127.0.1.1
dnsmasq: validation metadata.provider.plex.tv is BOGUS
dnsmasq: reply error is SERVFAIL
dnsmasq: query[A] resources-cdn.plexapp.com from 192.168.1.119
dnsmasq: forwarded resources-cdn.plexapp.com to 127.0.1.1
dnsmasq: query[A] music.provider.plex.tv from 192.168.1.119
dnsmasq: forwarded music.provider.plex.tv to 127.0.1.1
dnsmasq: validation result is INSECURE
dnsmasq: reply music.provider.plex.tv is 104.18.18.96
dnsmasq: reply music.provider.plex.tv is 104.18.19.96
dnsmasq: query[A] resources-cdn.plexapp.com from 192.168.1.119
dnsmasq: forwarded resources-cdn.plexapp.com to 127.0.1.1
dnsmasq: dnssec-query[DS] plexapp.com to 127.0.1.1
dnsmasq: query[A] resources-cdn.plexapp.com from 192.168.1.119
dnsmasq: dnssec-retry[DS] plexapp.com to 127.0.1.1
dnsmasq: reply plexapp.com is no DS
dnsmasq: dnssec-query[DS] cloudflare.net to 127.0.1.1
dnsmasq: reply cloudflare.net is DS keytag 2371, algo 13, digest 2
dnsmasq: dnssec-query[DNSKEY] cloudflare.net to 127.0.1.1
dnsmasq: reply cloudflare.net is DNSKEY keytag 34505, algo 13
dnsmasq: reply cloudflare.net is DNSKEY keytag 2371, algo 13
dnsmasq: validation result is INSECURE
dnsmasq: reply resources-cdn.plexapp.com is <CNAME>
dnsmasq: reply resources-cdn.plexapp.com.cdn.cloudflare.net is 104.18.27.226
dnsmasq: reply resources-cdn.plexapp.com.cdn.cloudflare.net is 104.18.26.226
dnsmasq: query[A] meta.plex.tv from 192.168.1.119
dnsmasq: forwarded meta.plex.tv to 127.0.1.1
dnsmasq: query[A] meta.plex.tv from 192.168.1.119
dnsmasq: forwarded meta.plex.tv to 127.0.1.1
dnsmasq: validation result is INSECURE
dnsmasq: reply meta.plex.tv is 104.18.19.96
dnsmasq: reply meta.plex.tv is 104.18.18.96
dnsmasq: query[A] api.amazonalexa.com from 192.168.1.111
dnsmasq: cached api.amazonalexa.com is <CNAME>
dnsmasq: forwarded api.amazonalexa.com to 127.0.1.1
dnsmasq: dnssec-query[DS] amazonalexa.com to 127.0.1.1
dnsmasq: reply amazonalexa.com is no DS
dnsmasq: validation result is INSECURE
dnsmasq: reply api.amazonalexa.com is <CNAME>
dnsmasq: reply tp.b16066390-frontier.amazonalexa.com is <CNAME>
dnsmasq: reply d1gsg05rq1vjdw.cloudfront.net is 99.84.10.115
dnsmasq: query[A] graph.facebook.com from 192.168.1.119
dnsmasq: cached graph.facebook.com is <CNAME>
dnsmasq: forwarded graph.facebook.com to 127.0.1.1
dnsmasq: query[A] graph.facebook.com from 192.168.1.119
dnsmasq: forwarded graph.facebook.com to 127.0.1.1
dnsmasq: validation result is INSECURE
dnsmasq: reply graph.facebook.com is <CNAME>
dnsmasq: reply star.c10r.facebook.com is 157.240.221.18
dnsmasq: query[A] connectivitycheck.gstatic.com from 192.168.1.175
dnsmasq: cached connectivitycheck.gstatic.com is 142.250.179.227

Here is the output. As can be seen it is the Plex.tv server producing the error I shall search for server updates to see if that cures it. Watchdog restarted dnsmasq.

Edit: Updated Plex TV server and still appearing in log. At least I know how to stop it.
 
Last edited:
Dirty flash from Alpha to Beta. Encountered problems with my smart plugs. Reverted back to Alpha and the plugs worked again. Reflashed to Beta. Smart Plugs not working. In the end I choose to reset the smart plugs and now it all works on the Beta. Did this make me happy? Hmmm not really.
 
Moving forward is usually an uphill climb. Whether it's a small hill or a big mountain. It's up.

It's the struggle itself that makes me happy (no work - no joy).

With the 'connected' world in constant review and amendments from what was previously best practices, and the fact that change logs rarely offer the full list of things changed under the hood, I'm even more interested in running the latest firmware, for the betterment of my networks. For all those known and unknown reasons.
 
Status
Not open for further replies.

Sign Up For SNBForums Daily Digest

Get an update of what's new every day delivered to your mailbox. Sign up here!
Top