>The fix is one character: endsWith("dlule") → contains("dlule"). YouTube returns "ezinsukwini ezingu-2 ezedlule." with a trailing period, which broke the exact-suffix check.
According to Sonnet, YT changed its date identifier string in the feed return. Broke the extractor.
Been tearing my hair out, since updating to the recent firmware, on why my DNS rewrites in AdGuardHome stopped working. After utterly failing to figure it out, I fired up qwen3-coder-next and pointed it at the router. If its correct, they introduced a bug in the recent firmware around how policy based routing works.
Just throwing this up here in case someone from GLi-net is around. I got around it by moving the rewrites to dnsmasq instead. This is obviously AI-generated, so take it with a grain of salt.
>The firmware update introduced a policy-based DNS routing system using packet marks. The key reasons: > >VPN Policy Support: The mark-based system (0x1000 for VPN DNS, 0x8000 for non-VPN DNS) allows different DNS servers for VPN vs regular traffic >Multi-WAN/Policy Routing: GL-iNet's "Route Policy" feature lets users specify which traffic goes through which interface >DNS Override Control: The override_vpn setting lets users choose whether VPN clients use VPN DNS or regular DNS >The Bug: The ROUTE_POLICY chain has a rule that causes DNS traffic (UDP port 53) to RETURN early before marks are set: > >RETURN udp -- 0.0.0.0/0 0.0.0.0/0 udp dpt:53 >This means DNS packets never get marked with 0x8000, so adg_redirect never matches, and DNS falls through to policy_redirect (which sends it to dnsmasq on port 2153).