Beta Asuswrt-Merlin 386.4 beta is now available

[RMerlin]

May 5 07:05:10 dnsmasq-script[1313]: json_object_from_file: error opening file /jffs/nmp_vc_json.js: No such file or directory

Ignore that. Part of the closed source AiMesh component, probably the component looks for the file too early on during boot (notice the May 5th date) before the file was created by networkmap.

 

[RMerlin]

What I'm struggling to understand is why the Network Monitoring > DNS Query check box even exists if un-checking it doesn't actually stop it (because its function is now mandatory). Maybe the checkbox should be removed and the Resolve Hostname/IP Addresses fields left permanently enabled (similar to the NTP Server field), and those fields cannot be null. Just a thought.

All I know is that Asus has been making many changes to the monitoring code these past months. Initially these were used specifically for Dual WAN failover mode.

That portion of the code is a complete mess, I have stopped years ago even trying to understand it.

 

[octopus]

Ignore that. Part of the closed source AiMesh component, probably the component looks for the file too early on during boot (notice the May 5th date) before the file was created by networkmap.

Okay, thanks. Good to know it's Aimesh related

 

[RMerlin]

Okay, thanks. Good to know it's Aimesh related

Actually my bad, it's not related to AiMesh but something else - unsure what, still closed source tho.

 

[unsynaps]

Known issue as indicated earlier, you will need to retest that after I apply the latest DDNS patches from Asus.

Contacting Asus about this won't do anything. It's currently a technical issue, and both Asus and Broadcom are involved. Until they resolve this, nothing that can be done.

The only change is how this is stored in nvram. Functionality is 100% identical to 386.3.

Knew I should have returned my GT-AXE11000 when I had the chance and gotten the non-E version.

 

[Kabouter Plop]

Did all of those things:
View attachment 37914

Try different dns server, if had some odd problems my self even with asus firmware no idea why wan is configured sometimes to shutoff simply by having no contact with dns

 

[Kabouter Plop]

All I know is that Asus has been making many changes to the monitoring code these past months. Initially these were used specifically for Dual WAN failover mode.

That portion of the code is a complete mess, I have stopped years ago even trying to understand it.

Wan dns is so buggy it will say it has no internet and keep wan up you have different dns configured by another dhcp server for example from nas, internet keeps working then router will act like a child and block wan randomly only cos it cannot reach dns even tho its online, as if some kind of mining malware is installed on router and sending data to asus that must somehow stay connection

 

[learning_curve]

I think Asus is now starting to support IPv6 [1]. [1] https://www.snbforums.com/threads/a...beta-for-ipv6-ddns-and-ipv6-vpn-server.75829/

IPv6 has been included within the Asus firmware code for a little while now, but has not yet officially been invoked, hence the current 'status' is still 'not supported' There's other thread's on here that cover this in more detail. That link shows more progress, but your / my router isn't on the supported model list anyway.

Of course, we may need to wait for beta 2 to know, because I can confirm that 386.3_2 and previous firmware does not support it. 386.4 beta 1 cannot use this feature due to some problems. nslookup www.asuscomm.com, this is Asus's own url, and you can see that their server has IPv6.

Yes and as you'll have seen in this thread @RMerlin has already covered the current Asus IPv6 bug / patches etc so Beta 2 should, in theory, resolve this issue for you.

Because the OpenVPN server of 386.3_2 does not support IPv6, I have never enabled IPv6 for my home network, so I have never enabled DDNS since my ISP no longer provides public IPv4.

I don't use OpenVPN on the router itself.
I use VPN directly on clients / devices on the LAN if / when needed, so your requirements are different.

I think DDNS should register all IP addresses anyway, even local addresses. Just like I can resolve my domain to any IP address, how to respond to that IP address is a matter of the client. However, the OpenVPN client does not allow you to choose to only accept IPv6. In fact, they do have an option "Only IPv4 tunnel/Combined IPv4/IPv6 tunnel/no preference". So I must only provide IPv6 when registering for DDNS. Maybe I can implement it with a custom script, but I would prefer to see an option appear in the router GUI.

Again, my own current / future requirements are different than yours. I'm quite happy with the way it works already (including IPv6 and IPv6 DDNS but not from Asus). IPv6 DDNS if/when it arrives from Asus is just an extra (if needed) for me. I don't use OpenVPN itself, anywhere (unless it's customised & then provided as an option by a VPN provider), so those limitations, I'm not aware of / have no exposure to (so far) to be fair.

 

[STRUZZIN]

RT-AX58U Updated and running good so far.
Mesh units still on Asus everything seems fine.

 

[Tech9]

All I know is that Asus has been making many changes to the monitoring code these past months. Initially these were used specifically for Dual WAN failover mode.

This is good news. If they manage to fix Dual WAN - great!

 

[RDaneel]

Not to be annoying, just trying to add another data point... I do no DDNS, no OpenVPN, really just a vanilla system.

But my IPv6 - which has been working perfectly with my Comcast connection for the last 2+ years - is completely gone after installing 386.4 BETA1 from the previous 386.3_2 release.

This is both immediately after the update and then after a forced reboot...

Put another way, https://test-ipv6.com/index.html.en_US has given me "10/10" since the day I hooked up my RT-AX88U - but now, the exact same (untouched) "Native" and the rest of the defaulted settings result in the test site reporting "0/10", and no IPv6 addresses or components are shown on the device's IPv6 page.

So, I tried to read the posts in this "BETA1" thread that mentioned IPv6, and they seem to all (?) mention DDNS or OpenVPN - but since I have neither of those in use, there could be something more fundamental with the new code and IPv6 going on?

EDIT: So, I recalled that in the spring of 2019 (and then it became superflouous that summer), we got to add a "wan-start" script to /jffs/scripts, which did the following to enable IPv6:

echo "1" > /proc/sys/net/ipv6/conf/all/accept_ra
echo "1" > /proc/sys/net/ipv6/conf/all/forwarding
echo "1" > /proc/sys/net/ipv6/conf/eth0/accept_ra
echo "0" > /proc/sys/net/ipv6/conf/eth0/forwarding

... and then make it executable, reboot, etc.

Perhaps needless to say (but I thought I should add this in the spirit of "data point"), this appears to have no effect on the current dearth of IPv6.

 

[GWater]

Thanks for the response, yes I have "Client will use VPN to access" radio button set to "Both". No changes to ciphers and all config is manual page by page. I export the ovpn file directly from the server page and import into the Android client. Okay, now that I know this config "should work" I'll keep playing....very strange. As I said, this use to work without issue for me so not sure why it doesn't anymore

The plot thickens...I can SSH and traceroute from my android when it's connected as a client to the asus OpenVPN Server (remotely) but anything http or https related (Chrome and Samsung Internet app) fails to load. No access to router web ui or NAS. Can SSH to both though.

 

[jsbeddow]

The plot thickens...I can SSH and traceroute from my android when it's connected as a client to the asus OpenVPN Server (remotely) but anything http or https related (Chrome and Samsung Internet app) fails to load. No access to router web ui or NAS. Can SSH to both though.

Hmm...this is starting to sound more like a client issue, perhaps the Android "Private DNS" setting should be checked: it may be set to Auto, I would suggest turning it off completely, even if theoretically it shouldn't matter inside of an OpenVPN tunnel. Worth trying in any case.

 

[learning_curve]

Not to be annoying, just trying to add another data point... I do no DDNS, no OpenVPN, really just a vanilla system. But my IPv6 - which has been working perfectly with my Comcast connection for the last 2+ years - is completely gone after installing 386.4 BETA1 from the previous 386.3_2 release. This is both immediately after the update and then after a forced reboot...Put another way, https://test-ipv6.com/index.html.en_US has given me "10/10" since the day I hooked up my RT-AX88U - but now, the exact same (untouched) "Native" and the rest of the defaulted settings result in the test site reporting "0/10", and no IPv6 addresses or components are shown on the device's IPv6 page.

So, I tried to read the posts in this "BETA1" thread that mentioned IPv6, and they seem to all (?) mention DDNS or OpenVPN - but since I have neither of those in use, there could be something more fundamental with the new code and IPv6 going on?

You presumably have the same result on: https://ipv6-test.com which is a better quick test (in some ways).
AFAIK... all the IPv6 issues so far on this in Beta 1 thread, do indeed only relate to IPv6 DDNS (and Open VPN etc ), not, just their IPv6 'native' connection, which seems to work okay for everybody else who has that setup. Maybe revert back to 386.3_2 and wait for Beta 2 to be released and see if that resolves your issue?

 

[RDaneel]

Maybe revert back to 386.3_2 and wait for Beta 2 to be released and see if that resolves your issue?

Sane and sensible advice for sure, but... I will wait and see - my network is not exactly crippled by this, and I really think there are already or will be others popping up with the same mystery.

And yes, I do assume that reverting would bring all that IPv6 goodness back.

EDIT: all right, I couldn't resist... reverting to 386.3_2 does restore IPv6, including "10/10" @ https://ipv6-test.com (which does seem faster than the "expanded version" I had been using for some reason - why is this?).

Which leaves the question of why did BETA1 seem to break IPv6, but [possibly] for only for a small # of us?

Being hopeful, I am looking forward to BETA2.

 

[Grievous Angel]

Just randomly checked: 60 days of flawless uptime on my AX86u running Merlin. No need to reboot without releases! Glad to hear things are flowing again.

 

[Shira]

My router won't connect to WAN with this beta.

RT-AC68U
Vodafone fiber through pppoe

May 5 07:21:34 services: apply rules error(17667)
May 5 07:21:34 pppd[3433]: Timeout waiting for PADO packets

 

[RMerlin]

My router won't connect to WAN with this beta.

RT-AC68U
Vodafone fiber through pppoe

If it needs VLAN, then you will have to wait for beta 2, there are issues with the RT-AC68U and switch configurations in beta 1.

 

[Tech9]

I'm getting this in RT-AC86U logs. Connection cuts off and comes back again.

Dec 20 23:09:06 kernel: br0: received packet on eth6 with own address as source address
Dec 20 23:09:08 dnsmasq-dhcp[28022]: DHCPREQUEST(br0) 192.168.172.18 40:e2:30:xx:xx:xx
Dec 20 23:09:08 dnsmasq-dhcp[28022]: DHCPACK(br0) 192.168.172.18 40:e2:30:xx:xx:xx hp1243-pc

Not observed on stock Asuswrt 386.45956 firmware. I'm using the same test client.

 

[Deleted member 77025]

I'm getting this in RT-AC86U logs. Connection cuts off and comes back again.

Dec 20 23:09:06 kernel: br0: received packet on eth6 with own address as source address
Dec 20 23:09:08 dnsmasq-dhcp[28022]: DHCPREQUEST(br0) 192.168.172.18 40:e2:30:xx:xx:xx
Dec 20 23:09:08 dnsmasq-dhcp[28022]: DHCPACK(br0) 192.168.172.18 40:e2:30:xx:xx:xx hp1243-pc

Not observed on stock Asuswrt 386.45956 firmware. I'm using the same test client.

too sometimes on my wifi, dont know if it also has something todo with later intel wifi drivers (AX) but on the earlier ones its a better connection