Recent content by themiron

try to install dig from entware and check what does you dns server reply with: dig a us-la.torguard.com @dns.server.ip.address dig aaaa us-la.torguard.com @dns.server.ip.address old uclibc used in bcm arm models has limitation for max number of addresses in one reply, this can be why

seems you're asking right question but to the wrong person. version numbers and newer/older deps questions should be asked directly to asus, I believe, 'coz they are upstream of that gpls, not @RMerlin.

No problem, hope Fix ChaCha20 on 32-bit platforms patch will help.

how can I reproduce it? mips cpu/router model, steps...?

ouch, commits b21b8692eedcc3c217f894450de373623533565b and b21b8692eedcc3c217f894450de373623533565b were merged, right? new code affects not only the chacha-poly, but key exchange curve25519 and key algo ed25519 as well, can you confirm that disabling only the chacha-poly solves the issue?

running iperf3 on router itself involves router cpu to send/receive traffic by userpsace application. therefore it can be slower than just forwarding/routing the traffic from one host to another (with and without hw nat acceleration). 1G lan -> ac router -> intel 8265 will give ~670Mbps with...

rt-ax56u: 2.4Ghz 2x2:2 5Ghz 2x2:2 @80Mhz, no 160Mhz support rt-ax58u: 2.4Ghz 2x2:2 5Ghz 2x4 @80Mhz and @160Mhz rt-ax3000 is another name of rt-ax58u rt-ax88u: 2.5Ghz 4x4:4 5Ghz 4x4:4 @160Mhz

to be precise, aes/sha hw kernel (ipsec) & userspace (openvpn, https, ssh, ...) acceleration supported by every models with ARMv8 CPU, incl.: RT-AC86U, RT-AC2900, GT-AC2900, GT-AC5300, RT-AX88U, RT-AX5300, RT-AX11000

soon :)

try to keep asutomatic dns, should help I guess and doesn't break DoT

have you ipv6 dns servers automatic or static (empty)?

try to remove "dhcp-script=/sbin/dhcpc_lease" from dnsmasq.conf, will it help? syslog and /opt/var/log/dnsmasq.log will give some light on this.

FYI,

Regarding https://rootcanary.org/test.html test behavior. Browser tries to resolve secure.dNaNnN.rootcanary.net & bogus.dNaNnN.rootcanary.net domains. After that, following happen: 1. If bogus.* was resolved - test concludes resolver doesn't validate answers (yellow) 2. If bogus.* was not...

Oh, such a hot thread :) wsdd2 has poorly written binding code, that's why it errors out. Just fixed in entware, will be available on next update, or on urgent need you can build it by yourself from entware git.