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

[jerry6]

working well on my rt5300 , no problems that I can find
Thanks again

 

[RMerlin]

Here is the output. As can be seen it is the Plex.tv server producing the error

You seem to be using DNS over TLS, which may be what is causing the issue. A query to plex.tv only generates a 128 bytes long reply for me. So, it may be a limitation of your upstream DNS server, and dnsmasq is adjusting by reducing its max query size. What DoT servers are you using?

Also, they do seem to flag their domain as DNSSEC-enabled, but return unsigned replies to some domain queries, which would indicate a problem with the plex.tv domain itself. That means you might want to disable DNSSEC validation to avoid potential issues with Plex.

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.

There was absolutely no change to wifi between alpha and beta. Just more models updated, each with their own separate driver.

 

[ColinTaylor]

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.

You seem to be using DNS over TLS, which may be what is causing the issue. A query to plex.tv only generates a 128 bytes long reply for me. So, it may be a limitation of your upstream DNS server, and dnsmasq is adjusting by reducing its max query size. What DoT servers are you using?

This might be relevant if you're using Quad9:

DNSMASQ_WARN reducing DNS packet size

Because this is not a good solution for everyone. I recommended reducing the payload size only for this who discovered that a larger payload size does not work for them. Many can handle larger DNS buffers just fine. For instance, my local unbound handles 4096 bytes packets just fine. Because...

discourse.pi-hole.net

 

[banger]

You seem to be using DNS over TLS, which may be what is causing the issue. A query to plex.tv only generates a 128 bytes long reply for me. So, it may be a limitation of your upstream DNS server, and dnsmasq is adjusting by reducing its max query size. What DoT servers are you using?

Also, they do seem to flag their domain as DNSSEC-enabled, but return unsigned replies to some domain queries, which would indicate a problem with the plex.tv domain itself. That means you might want to disable DNSSEC validation to avoid potential issues with Plex.

Yes I am using DoT with Cloudflare and Cleanbrowsing two servers each enabled. I only use plex for local media serving on alexa devices and noticed that trying to play Plex videos doesn't work. I will experiment with DNSSEC setting.

Edit: After playing with DoT settings and it could clearly be reproduced by just opening the Plex webpage, removing cleanbrowsing (security) from DoT table has solved it for me. Quad9 was originally set as the Default DNS Server although that may not be relevant. All I have now in DoT table is cloudflare.

 

[RMerlin]

This might be relevant if you're using Quad9:

Seems to vary greatly between providers. I remember a few months ago I did change the max packet size to follow RFCs instead of using the different value picked by Asus. I'd have to revisit that change and see if maybe Asus' value was more reliable due to many DNS providers ignoring the RFC recommendation.

 

[RMerlin]

I see that I'm still using the same 1280 value as before (that value is what Asus has picked, I didn't change the value, I just changed the way it was implemented - my memory was wrong there). I suspect that dnsmasq might now be generating log entries when the packet size is reduced, while in the past it was doing it quietly.

I could reduce it further down to 1232, but seeing how various servers may support up to 4KB, I wonder if ultimately it might not be best performance-wise to allow for larger packets, but just silence that warning message (moving it to a DEBUG level perhaps). That will require more research to determine the impact of allowing larger packets. dnsmasq defaults to 4 KB BTW, and they will downgrade to 1232 if there is an issue - which is what is currently being logged.

 

[dave14305]

I suspect that dnsmasq might now be generating log entries when the packet size is reduced, while in the past it was doing it quietly.

Yes, Simon reduced “safe packet size“ from 1280 to 1232 in 2.87.

thekelleys.org.uk Git - dnsmasq.git/commitdiff

 

[Master3395]

I have been doing a full upgrade (not dirty) to 386.9_alpha1-gfb36317a30.
On that build, using my AC88U, it has been running on almost 100% on both cores a lot of the time, until I force turns the router off and on again.
This again hits badly on clients that are connected to 2.4 GHz wifi.
Ethernet is fine and so is 5Ghz.


I will now try a clean upgrade to RT-AC88U_386.9_beta1, to see if it is any more stable.
Referring to this also.
Intermittent loss of Wi-Fi since upgrading to 386.7 | Page 14 | SmallNetBuilder Forums (snbforums.com)

 

[RMerlin]

Yes, Simon reduced “safe packet size“ from 1280 to 1232 in 2.87.

thekelleys.org.uk Git - dnsmasq.git/commitdiff

EDNS_PKTSZ is the value that matters here. That's the value that I set to 1280 through dnsmasq.conf, and if that value proves to be too high, then dnsmasq will reduce it to SAFE_PKTSZ, and generate the reported log entry. So the current "issue" isn't related to SAFE_PKTSZ, it's related to EDNS_PKTSZ.

Since EDNS_PKTSZ wasn't changed in 386.9, then the logging must have.

 

[RMerlin]

On that build, using my AC88U, it has been running on almost 100% on both cores a lot of the time, until I force turns the router off and on again.

Run "top" over SSH and see what is using your CPU.

 

[RMerlin]

Buffer resize logging doesn't seem to have been changed recently (the log call itself is from 2017).

According to the dnsmasq source code, the buffer resize should only happen once, and the reported downsized value would become the new permanent value. @banger , does your router have anything that would cause dnsmasq to get restarted every hour, which would cause it to revert back to 1280?

If this warning is new, then the change might have happened in getdns/stubby rather than dnsmasq.

 

[SheikhSheikha]

You seem to be using DNS over TLS, which may be what is causing the issue. A query to plex.tv only generates a 128 bytes long reply for me. So, it may be a limitation of your upstream DNS server, and dnsmasq is adjusting by reducing its max query size. What DoT servers are you using?

Also, they do seem to flag their domain as DNSSEC-enabled, but return unsigned replies to some domain queries, which would indicate a problem with the plex.tv domain itself. That means you might want to disable DNSSEC validation to avoid potential issues with Plex.


There was absolutely no change to wifi between alpha and beta. Just more models updated, each with their own separate driver.

Good to know. Somehow the 2.4Ghz radio has gone "rogue". The main 2.4Ghz is giving a signal strength that on average is 4-5% higher than a Guest Signal. Planning a clean install to see what is cooking. If I go back to previous versions the 2.4Ghz is working fine and has an overall 5% higher signal strength compared to the beta version and there is no difference between main and guest. (I am aware that this is closed stuff Erik).

 

[RMerlin]

Good to know. Somehow the 2.4Ghz radio has gone "rogue". The main 2.4Ghz is giving a signal strength that on average is 4-5% higher than a Guest Signal. Planning a clean install to see what is cooking. If I go back to previous versions the 2.4Ghz is working fine and has an overall 5% higher signal strength compared to the beta version and there is no difference between main and guest. (I am aware that this is closed stuff Erik).

Try just doing an electrical reset of your router (i.e. unplug the power for 5-10 secs, then plug it back in).

 

[panther7]

RT-AC66U B1 ... try update from 386.7_2 to 386.9_beta1 ...after reboot, still on 386.7_2

 

[dave14305]

EDNS_PKTSZ is the value that matters here. That's the value that I set to 1280 through dnsmasq.conf, and if that value proves to be too high, then dnsmasq will reduce it to SAFE_PKTSZ, and generate the reported log entry. So the current "issue" isn't related to SAFE_PKTSZ, it's related to EDNS_PKTSZ.

Since EDNS_PKTSZ wasn't changed in 386.9, then the logging must have.

dnsmasq will compare the configured edns_pktsz to SAFE_PKTSZ and reduce accordingly. SAFE_PKTSZ did change from 1280 to 1232 in 386.9, so now you get more logs generated.

asuswrt-merlin.ng/release/src/router/dnsmasq/src/forward.c at 48b7c614c93cb251e3a9fddc1f7c10a0bb4be9c9 · RMerl/asuswrt-merlin.ng

Third party firmware for Asus routers (newer codebase) - RMerl/asuswrt-merlin.ng

github.com

FWIW, OpenWrt uses 1232 for edns-packet-max.

 

[bobhope]

Hi All,

Is there a chance this new beta will fix "Parental Controls, time scheduling".....every since latest alpha update time scheduling does not work properly....it often does not cut the intended device off from the net

 

[bennor]

RT-AC66U B1 ... try update from 386.7_2 to 386.9_beta1 ...after reboot, still on 386.7_2

Did you use the Beta version firmware for the RT-AC68U to update your RT-AC66U B1?
https://sourceforge.net/projects/as...66U_B1/Use the RT-AC68U firmware.txt/download

The RT-AC1900, RT-AC1900P and RT-AC66U_B1 use the same firmware as the RT-AC68U.

As a troubleshooting step try clearing the browser's cache.

 

[laracroftonline]

RT-AC66U B1 ... try update from 386.7_2 to 386.9_beta1 ...after reboot, still on 386.7_2

try uploading the firmware again!

 

[banger]

According to the dnsmasq source code, the buffer resize should only happen once, and the reported downsized value would become the new permanent value. @banger , does your router have anything that would cause dnsmasq to get restarted every hour, which would cause it to revert back to 1280?

Not that I know of nothing in the log although. Only thing in logs is wifi comings and goings on the AC68U.

 

[dave14305]

According to the dnsmasq source code, the buffer resize should only happen once, and the reported downsized value would become the new permanent value. @banger , does your router have anything that would cause dnsmasq to get restarted every hour, which would cause it to revert back to 1280?

Looks like dnsmasq will attempt to retry the original packet size after a wait of 60 (not sure if it’s measured in seconds or minutes, but minutes would explain the log timestamps).

asuswrt-merlin.ng/release/src/router/dnsmasq/src/forward.c at 48b7c614c93cb251e3a9fddc1f7c10a0bb4be9c9 · RMerl/asuswrt-merlin.ng

Third party firmware for Asus routers (newer codebase) - RMerl/asuswrt-merlin.ng

github.com