What's new

Beta Asuswrt-Merlin 386.4 beta is now available

  • SNBForums Code of Conduct

    SNBForums is a community for everyone, no matter what their level of experience.

    Please be tolerant and patient of others, especially newcomers. We are all here to share and learn!

    The rules are simple: Be patient, be nice, be helpful or be gone!

Status
Not open for further replies.
On beta 1 I worked to get my AC66U_B1 to be a mesh node. I tried many times with stock firmware current then back a couple of releases of stock. Finally connected the node, upgraded the stock then flashed the beta1.
Sometimes nodes are stubborn but once connected they work well. I suspect neighborhood WIFI does cause issues...
AiMesh is a hit and miss. I managed to connect AC86U to AX58U, but it was a fight. No luck with AC68U. This is not how it should work. Also getting Wi-Fi stutters on AC86U. Reversing the routers to stock Asuswrt and will test again the final release when I have the time.
Made it back to Merlinware beta2 :D ... by factory reset all under RT-AX86U stock firmware 386-45934 on main router and intended node.
Quick and easy AiMesh setup using that firmware - rebuilt all manually - noted again that IPv6 and DDNS worked fine without incident on stock.

Then BEFORE upgrade to beta2 - I disabled IPv6 - saved settings - then dirty flashed beta2 node first - waited - then flashed beta2 on main router. Been stable for a good while ... and will now begin rebuild of all addons - but will not enable IPv6 until work-around applied by the Maestro.

Hope that helps anyone else jumping in the beta pool with this specific router.
The water is warm and feedback - good or bad - should be welcomed :cool:.
 
Installed beta2 on my RT-AC68P a little over 18 hours ago.
All is working well for me and my approx 20 client devices (including Comcast IPv6, FlexQoS with some custom classifications)
 
Close to 2 days up time on Beta2, All good here :)
Huge thanks RMerlin !
Happy Christmas to all ;)
 
@RMerlin: dare we hope for a stable Release by New Year's day?
Screenshot_20211224-095356_Chrome~2.png


Maybe we will? just kidding, don't want to pressure RMerlin, especially on the holidays, I wish everyone happy holidays, stay safe.
 
At this point, the current plan is to simply disable IPv6 support in DDNS.
If you need it, I am happy to build a remote environment for you to debug IPv6 and DDNS. I have a public IPv6 address obtained through dynamic or PPPoE and an RT-AC68U (C1 with 1.4GHz) for testing.

I can create a remotely connected PC for you in my home and another independent network that ensures that you will not be disconnected when debugging the router at any time.


Anyway, thank you for your hard work on this feature, Merry Christmas.
 
Beta 2/ AX88: Might want to look at the NTP server, and/or NTP 'client intercept to Merlin NTP' code. Had a device that was rock solid take a nose dive yesterday with a 'no ethernet' connection message although it showed the ethernet being connected. Tracked it down to the clock that had decided it was May of 2020 even though it was set for auto NTP. Set the clock manually, reset to auto, and also disabled 'intercept NTP client requests,' and everything is working again. Router logs have the correct time stamp, so maybe it's unrelated. Anyway, was a head scratcher.
 
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.

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.

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.

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.
Yes, I am sorry that I did not notice that they did not introduce IPv6 DDNS support to any AC models, or even any HND AC models. But I believe that more models will be added.

I am very grateful for Rmerlin's efforts for all the models he supports. Even if this problem is apparently still present in beta 2, I believe that with continuous upstream support, we will eventually see this feature in the Merlin firmware.

In addition, I am considering using Raspberry Pi as an IPv6 OpenVPN server and DDNS server, but I don’t have any Raspberry Pi devices. I may need to consider their performance before purchasing. I like low-power devices.

Merry Christmas.
 
All my units updated to Beta are working great thanks.
I do have an issue with my Xbox still something is blocking it.
Direct connect to modem is fine plug in router no go.
Could it be the Router Firewall or Unbound Adblock / DNS Frewall.
Anyone have any idea I would really appreciate the help.
**I did try to disable adblock and dns firewall did not work.
 
All my units updated to Beta are working great thanks.
I do have an issue with my Xbox still something is blocking it.
Direct connect to modem is fine plug in router no go.
Could it be the Router Firewall or Unbound Adblock / DNS Frewall.
Anyone have any idea I would really appreciate the help.
**I did try to disable adblock and dns firewall did not work.

think it has something to do with ipv6/ddns, some other users reported this issue too:
asuswrt-386-rc3-3-public-beta-for-ipv6-ddns-and-ipv6-vpn-server.75829/
for me it seems its still a issue with ipv6 when trying to connect to my vpn over ipv6 (native).
connection over ipv6 only gets no connection to the vpn server.
speedcheck gives only 4-6 server to test (normaly 15-20 servers) and some sites wont even load.
 
Running past 48hrs well with the latest beta 386.4, its much faster performance then what I got with the 386.3_2 firmware with exact same settings and set up, this is with the latest openvpn 2.5+ settings with my MullvadVPN also, I actually managed to break to 260+ Mbps over 384.19 firmware which was my golden all working well version but that was max 200Mbps.

Thanks to Merlin and all the hard work put in, appreciate the VPN director and all the great features helping us keep safe and sound!
 
@RMerlin So far great work many many thanks.
One issue i have is that i lose my ipv6 connection when i activate the quest wifi.
When i set native as my ipv6 connection i get the LAN ipv6 prefix etc.
Then when i set the quest wifi and reboot the LAN ipv6 prefix etc is gone.
Deactivating the quest wifi and rebooting the ipv6 works again.
I have a AX86S as router and a AX68U as a meshpoint.
 
@RMerlin So far great work many many thanks.
One issue i have is that i lose my ipv6 connection when i activate the quest wifi.
When i set native as my ipv6 connection i get the LAN ipv6 prefix etc.
Then when i set the quest wifi and reboot the LAN ipv6 prefix etc is gone.
Deactivating the quest wifi and rebooting the ipv6 works again.
I have a AX86S as router and a AX68U as a meshpoint.
I have been experiencing the same issue since Alpha2 and I believe that the cause of the issue is an error in the auto-generated /tmp/filter_rules_ipv6 file on Ln 8 or Ln 21.

Code:
Ln 8->:PControls - [0:0]
Ln 21->-A FORWARD -i br1 -j WGNPControls

With guest network enabled, the rules fail to load due to an error at Ln 21 because the WGNPControls chain has not been defined. Because the rules fail to load, rules from /tmp/filter_ipv6.default remain in place which effectively disables IPV6 which I assume is the default configuration. If I update Ln 8 to :WGNPcontrols then load the rules using ip6tables-restore, the rules load just fine and IPV6 becomes fully functional. I've attached two versions of the filter_rules_ipv6 file, one with guest network on and one with guest network off. The only real difference between the two is that the -A FORWARD -i br1 -j WGNPControls line doesn't exist with guest network turned off which makes sense because the br1 interface doesn't exist.
 

Attachments

  • filter_rules_ipv6-GuestNetworkOff.txt
    2.6 KB · Views: 83
  • filter_rules_ipv6-GuestNetworkOn.txt
    2.6 KB · Views: 71
My BETA1 was broken for IPv6 on my AX88U - like I said in my report for BETA1, I have everything "vanilla", don't do any DDNS,or anything else "exotic"...

Even though the BETA2 changelog notes indicated no changes for IPv6 itself, I thought I would try - and, nope, IPv6 is still completely missing in action in BETA2 - the "IPv6" page under Advanced Settings is still empty of any values.

Also, like I said for BETA1, this isn't really a killer problem for me, I will keep reporting this kind of breakage on BETAs to provide what I hope is useful feedback - if I want IPv6 back, I just have to downgrade to 386.3_2... but I would be really surprised if this is ONLY happening to me. ;)

Finally, an odd observation: while BETA1 was being loaded, the AX88U looked "weird", in that all the lights stayed on - while loading BETA2, at least things looked normal again, in that all the lights except for 1 went out - like I am used to.
 
My BETA1 was broken for IPv6 on my AX88U - like I said in my report for BETA1, I have everything "vanilla", don't do any DDNS,or anything else "exotic"...
Even though the BETA2 changelog notes indicated no changes for IPv6 itself, I thought I would try - and, nope, IPv6 is still completely missing in action in BETA2 - the "IPv6" page under Advanced Settings is still empty of any values.

Also, like I said for BETA1, this isn't really a killer problem for me, I will keep reporting this kind of breakage on BETAs to provide what I hope is useful feedback - if I want IPv6 back, I just have to downgrade to 386.3_2... but I would be really surprised if this is ONLY happening to me. ;)

Finally, an odd observation: while BETA1 was being loaded, the AX88U looked "weird", in that all the lights stayed on - while loading BETA2, at least things looked normal again, in that all the lights except for 1 went out - like I am used to.
Ditto for my AX88/Beta2. Used to run in native from my isp - if I activate it now nothing populates and bad things appear to occur. Running ipv4 only for now.
 
Just reporting - AC86U short Wi-Fi disconnections stopped with Asuswrt 45956, but I don't know if the Wi-Fi driver is the same. My test router has one only 5GHz wireless client and nothing else is attached to it. AC68U Wi-Fi works well in both Asuswrt 45987 and beta2, with the same wireless client.
 
@Elmer & @RDaneel and other folks experiencing IPV6 Native issues. Just out of curiosity are you using the Guest Network feature? I have had the same issue since Alpha2 but only with Guest Network 1 enabled. My previous post goes into further detail, but I have managed to get IPV6 working and have Guest Network 1 enabled by updating the IPV6 firewall rules.

 
So is AiMesh 2.0 stable now on asuswrt-merlin? Also do you have to upgrade the clients also or will it work with the native AiMesh 2.0 on the clients? I am looking to upgrade to get rid of the bufferbloat problem with the standard firmware on my RT-AX86U.
 
Status
Not open for further replies.

Sign Up For SNBForums Daily Digest

Get an update of what's new every day delivered to your mailbox. Sign up here!
Top