Recent content by rhammond84

Yes, agree. Though have already conducted a factory reset - both methods, and had same issue with minimal config...... I recognise probably need to do more structured testing over long period of time. Either way, I tried to revert to stock firmware... But interestingly detects as incorrect one...

Stopped working again overnight with no changes/reboots. Really not sure if this is a router issue, a isp issue or a combination of both. Either way, giving up for now and turning ipv6 off until have a new firmware to test, or some other significant change driving the short term need!

Turned DoS protection back on alongside a number of reboots... And still seems to be working. Reluctant to trial more and break it!.... But more thinking this is some configuration hangover. Will see if it persists...

Ended up trying some other stuff (rebooting ONT) then all stopped working again even with Jumbo frames enabled.... Feels the firewall or router is filtering stuff erroneously/settings getting stuck. Latest: I turned off DOS protection in Wan settings. I know there was a historic bug where that...

Mtu: yes, by normal test methods (for ipv4 traffic) 1500 is fine. I understand ipv6 should implement pmtud and so mtu shouldn't really be a consideration. Haven't quite implemented one of the ways to test mtu formally for ipv6 traffic. However, back to original point, this was working...

Wan mtu tested by incrementally reducing until it worked... But as noted, the lower mtu breaks some other stuff on the network. The uPnP resolution suggests to me the router is doing something it shouldn't do when trying to resolve ipv4 addresses, or ipv6 (am assuming there's no fundamental...

Mtu was default/blank before (1500). 1412 was highest that would work in testing. Had completed all resets - software,hard reset with buttons. As noted, was all working previously for one year +. The alpha firmware load wasn't necessarily the point at which it started failing (don't have...

WAN connection is 'Automatic IP' - router connected to the ONT. UK FTTP alt net provider (Toob). IPv6 is 'Native'. My 'need' for IPv6 is not strong: I'm behind CGNAT and ideally would not pay for static ip and still be able to access my network remotely via IPv6. My interest for now is...

Have a strange problem that started playing out as images not loading on twitter on Android phone (n.b. Twitter does not use ipv6, but this must be related to some address resolution issues). Other laggs issues were observed. http://icmpcheckv6.popcount.org/ is not successful (packet...

Alpha on AX56u appears to fix the WiFi issues with older nest cam devices (and presumably IoT devices others experienced). This is the first build (Merlin or stock) that has had this resolved since prior to 384.

This issue is still present for the AX56U (in that, for some reason, Asus have not updated the firmware since November last year: https://www.asus.com/Networking-IoT-Servers/WiFi-6/All-series/RT-AX56U/HelpDesk_BIOS/).

Just for completeness, still have issues with regular disconnects on WiFi for AX56u with an original Nest Cam Indoor. A problem with the Asus original firmware that has not been updated for this device since November. Reverting to 386.3 resolves.

I'm continuing to get the same issues with an original Nest Indoor Cam, with an AX56u (also has not received an official Asus firmware on latest codebase). Issue is still present with latest Merlin beta (and the alphas before). Can only assume - due to no official release - there is still a...

Still obviously a stock firmware issue vs. Merlin though. The AX56u is still on the 45 release for stock... and has the same issue. Was hoping the 46 release that other routers were receiving would resolve.....

Still see same issues with original Nest cam indoor on AX56u on this alpha....i.e. Regular and repeated offline periods/disconnections.