Recent content by Ache

UI is completely broken for RT-N66U, with any browser (for just http). I was very lucky that main page link with version number still works (after re-auth), so I am able to flash 380.62_1 which works nice.

This is not abnormal, it is nearly equal (with the future gap) to the blocked IPs in Russia, and antizapret whole reason is to ublock them, leaving the rest of the traffic as is, bypassing VPN. In the latest antizapret.ovpn it is even increased: max-routes 30000 And --route-nopull kills the...

OpenVPN bug with antizapret.ovpn still exists: http://www.snbforums.com/threads/problems-with-openvpn-client-openvpn-linux-ifconfig-failed-could-not-execute-external-program.28392/#post-249284

The same trouble with 380.58: Mar 31 16:23:02 openvpn[652]: do_ifconfig, tt->ipv6=0, tt->did_ifconfig_ipv6_setup=0 Mar 31 16:23:02 openvpn[652]: /usr/sbin/ip link set dev tun11 up mtu 1500 Mar 31 16:23:02 openvpn[652]: Linux ip link set failed: could not execute external program Mar 31 16:23:02...

Simple: it was never fixed previously, it was just reported previously (on this forum too) http://www.snbforums.com/threads/ipv6-tunnel-instability-with-378-51-on-rt-n66u.23553/ and too long ago counting ASUS forum post from 2014. Just turn off CTF if you prefer IPv6 over lots of torrents...

About IPv6 problem, I have tunnel 6in4 and it dies after a while (from minutes to several hours) if CTF is on. Simple workaround: turn off CTF. This is old ASUS bug: http://vip.asus.com/forum/view.aspx?id=20141109102834965&board_id=11&model=RT-AC66U&page=1&SLanguage=en-us

"Memory Management: Regularly flush caches (ARM only) (default: Yes)" setting on my N66U is not Yes and not No (both cleared). Attempting to set it to Yes and pressing Apply don't change Yes indicatior, with reboot too.

It seems it is fixed in the 380.58_beta1

In this version SIP Passthrough=OFF is non-functional (works nice before). Your Passthrough=ON success results are off topic (topic starter have it OFF initially as me too) and very depends on your provider, some of them ignores headers damage.

SIP Passthrough = off becomes broken in this version (and SIP Passthrough = on always was broken by design, wrong digest for auth). See discussion started from here http://www.snbforums.com/threads/asuswrt-merlin-380-57-is-now-available.29308/page-19#post-228182 up to reply #367 SIP ALG also...

I just install previous version (because I need working SIP) without nvram reset.

SIP clients (hardware and software ones) always have a wide set of their own ways to get external IP: STUN servers, UPnP, etc., then telling it via HTTP-like headers , "rport", ICE, etc. along with internal one, so this is not the case. On directly connected device, at least, SIP can work...

380.57 unlike previous version have bad habit regarding to SIP: it receive UDP answer from the SIP server only if "SIP Passthrough" in the NAT Passthrough is turned ON (default). I don't need any passthrough since my machine is connected directly to the router and its NAT and I don't use any...

It is not MTU problem since I have it when downloading many torrents too even with MTU 1280. I found that it is software acceleration problem, namely Cut Through Forwarding. When I disable CTF in NAT Acceleration, 6in4 tunnel works with any MTU unlimited time. See also another user report at...

I notice the same thing each time even with recent v53 FW. The tunnel works from 15min to 12hours then dies, for ping and traceroute from the router too. Die time very depends on the tunnel/v6in4 MTU, it is ~15min with 1460 and up to 12hours with 1380. Pressing Apply button on IPv6 tab without...