Beta Asuswrt-Merlin 388.2 Beta is now available for Wifi 6 models

[Anubis]

Apr  8 00:53:45 acsd: eth7: selected channel spec: 0xec32 (52/160)
Apr  8 00:53:45 acsd: acs_csa_handle_request(359): eth7: err from dcs_handle_request:-22
Apr  8 00:53:45 acsd: acs_set_chspec: 0xec32 (52/160) for reason ACS_INIT
Apr  8 00:53:45 kernel: In wl_dfs_cac_notify_status chanspec 0xec32 DFS state 1
Apr  8 00:54:14 wlceventd: wlceventd_proc_event(511): eth7: Disassoc A8:93:4A:65:F1:EF, status: 0, reason: Disassociated because sending station is leaving (or has left) BSS (8), rssi:0
Apr  8 00:54:18 wlceventd: wlceventd_proc_event(511): eth7: Disassoc 5C:E9:1E:97:CB:14, status: 0, reason: Disassociated because sending station is leaving (or has left) BSS (8), rssi:0
Apr  8 00:54:23 wlceventd: wlceventd_proc_event(511): eth7: Disassoc 60:8B:0E:06:13:C1, status: 0, reason: Disassociated because sending station is leaving (or has left) BSS (8), rssi:0
Apr  8 00:54:45 kernel: In wl_dfs_cac_notify_status chanspec 0xec32 DFS state 2
Apr  8 00:54:49 wlceventd: wlceventd_proc_event(530): eth7: Auth A8:93:4A:65:F1:EF, status: Successful (0), rssi:0
Apr  8 00:54:49 wlceventd: wlceventd_proc_event(559): eth7: Assoc A8:93:4A:65:F1:EF, status: Successful (0), rssi:-54
Apr  8 00:56:06 wlceventd: wlceventd_proc_event(540): eth7: ReAssoc A8:93:4A:65:F1:EF, status: Successful (0), rssi:-56
Apr  8 00:56:18 wlceventd: wlceventd_proc_event(559): eth7: Assoc 5C:E9:1E:97:CB:14, status: Successful (0), rssi:-44
Apr  8 00:56:23 wlceventd: wlceventd_proc_event(530): eth7: Auth 60:8B:0E:06:13:C1, status: Successful (0), rssi:0
Apr  8 00:56:23 wlceventd: wlceventd_proc_event(559): eth7: Assoc 60:8B:0E:06:13:C1, status: Successful (0), rssi:-38
Apr  8 01:06:22 wlceventd: wlceventd_proc_event(494): eth7: Deauth_ind 6E:C7:72:9F:18:D6, status: 0, reason: Unspecified reason (1), rssi:-57
Apr  8 01:06:22 wlceventd: wlceventd_proc_event(530): eth7: Auth 6E:C7:72:9F:18:D6, status: Successful (0), rssi:-57
Apr  8 01:06:22 wlceventd: wlceventd_proc_event(559): eth7: Assoc 6E:C7:72:9F:18:D6, status: Successful (0), rssi:-57
Apr  8 01:24:59 cfg_server: cm_updateChanspec call wl_chanspec_changed_action
Apr  8 01:24:59 cfg_server:  event: wl_chanspec_changed_action_a101 of eid(6) of cfgs(2942)
Apr  8 01:24:59 cfg_server: current chansp(unit0) is 1008
Apr  8 01:24:59 cfg_server: current chansp(unit1) is ec32
Apr  8 01:24:59 cfg_server: dump exclchans:
Apr  8 01:24:59 cfg_server: old wl0_acs_excl_chans:0x100c,0x190a,0x100d,0x190b,0x100e,0x190c
Apr  8 01:24:59 cfg_server: new wl0_acs_excl_chans:0x100c,0x190a,0x100d,0x190b,0x100e,0x190c
Apr  8 01:24:59 cfg_server: old wl1_acs_excl_chans:0xd078,0xd07c,0xd080,0xd084,0xd0a5,0xd976,0xd87e,0xd97e,0xd886,0xe17a,0xe27a,0xe37a,0xe08a,0xed72,0xee72,0xef72
Apr  8 01:24:59 cfg_server: new wl1_acs_excl_chans:0xd0a5
Apr  8 01:24:59 cfg_server:  wl_chanspec_changed_action: Need to restart acsd for AVBL update
Apr  8 01:24:59 rc_service: cfg_server 2942:notify_rc restart_acsd
Apr  8 01:24:59 acsd: eth6: Selecting 2g band ACS policy
Apr  8 01:25:02 acsd: eth6: selected channel spec: 0x1008 (8)
Apr  8 01:25:02 acsd: eth6: Adjusted channel spec: 0x1008 (8)
Apr  8 01:25:02 acsd: eth6: selected channel spec: 0x1008 (8)
Apr  8 01:25:02 acsd: acs_csa_handle_request(359): eth6: err from dcs_handle_request:-22
Apr  8 01:25:02 acsd: acs_set_chspec: 0x1008 (8) for reason ACS_INIT
Apr  8 01:25:02 acsd: eth7: Selecting 5g band ACS policy
Apr  8 01:25:03 kernel: In wl_dfs_cac_notify_status chanspec 0xd028 DFS state 0
Apr  8 01:25:11 acsd: eth7: selected channel spec: 0xec72 (116/160)
Apr  8 01:25:11 acsd: eth7: Adjusted channel spec: 0xec72 (116/160)
Apr  8 01:25:11 acsd: eth7: selected channel spec: 0xec72 (116/160)
Apr  8 01:25:12 kernel: In wl_dfs_cac_notify_status chanspec 0xec72 DFS state 1
Apr  8 01:25:24 wlceventd: wlceventd_proc_event(511): eth7: Disassoc A8:93:4A:65:F1:EF, status: 0, reason: Disassociated because sending station is leaving (or has left) BSS (8), rssi:0
Apr  8 01:25:27 wlceventd: wlceventd_proc_event(511): eth7: Disassoc 5C:E9:1E:97:CB:14, status: 0, reason: Disassociated because sending station is leaving (or has left) BSS (8), rssi:0
Apr  8 01:25:35 wlceventd: wlceventd_proc_event(511): eth7: Disassoc 60:8B:0E:06:13:C1, status: 0, reason: Disassociated because sending station is leaving (or has left) BSS (8), rssi:0
Apr  8 01:25:42 wlceventd: wlceventd_proc_event(511): eth7: Disassoc 6E:C7:72:9F:18:D6, status: 0, reason: Disassociated because sending station is leaving (or has left) BSS (8), rssi:0
Apr  8 01:26:12 kernel: In wl_dfs_cac_notify_status chanspec 0xec72 DFS state 2
Apr  8 01:26:14 wlceventd: wlceventd_proc_event(530): eth7: Auth A8:93:4A:65:F1:EF, status: Successful (0), rssi:0
Apr  8 01:26:14 wlceventd: wlceventd_proc_event(559): eth7: Assoc A8:93:4A:65:F1:EF, status: Successful (0), rssi:-45
Apr  8 01:26:19 wlceventd: wlceventd_proc_event(559): eth7: Assoc 5C:E9:1E:97:CB:14, status: Successful (0), rssi:-44
Apr  8 01:27:30 wlceventd: wlceventd_proc_event(540): eth7: ReAssoc A8:93:4A:65:F1:EF, status: Successful (0), rssi:-54
Apr  8 01:27:47 wlceventd: wlceventd_proc_event(559): eth7: Assoc 60:8B:0E:06:13:C1, status: Successful (0), rssi:-44
Apr  8 01:39:57 wlceventd: wlceventd_proc_event(530): eth7: Auth 6E:C7:72:9F:18:D6, status: Successful (0), rssi:0
Apr  8 01:39:57 wlceventd: wlceventd_proc_event(559): eth7: Assoc 6E:C7:72:9F:18:D6, status: Successful (0), rssi:-53
Apr  8 01:40:07 wlceventd: wlceventd_proc_event(559): eth7: Assoc 16:09:35:44:D6:EA, status: Successful (0), rssi:-53
Apr  8 01:41:13 wlceventd: wlceventd_proc_event(657): eth7: Radar detected
Apr  8 01:41:13 kernel: In wl_dfs_cac_notify_status chanspec 0xec72 DFS state 3
Apr  8 01:41:13 cfg_server: cm_updateChanspec call wl_chanspec_changed_action
Apr  8 01:41:13 cfg_server:  event: wl_chanspec_changed_action_a101 of eid(7) of cfgs(2942)
Apr  8 01:41:13 cfg_server: current chansp(unit0) is 1008
Apr  8 01:41:13 cfg_server: current chansp(unit1) is ec72
Apr  8 01:41:13 cfg_server: dump exclchans:
Apr  8 01:41:13 cfg_server: old wl0_acs_excl_chans:0x100c,0x190a,0x100d,0x190b,0x100e,0x190c
Apr  8 01:41:13 cfg_server: new wl0_acs_excl_chans:0x100c,0x190a,0x100d,0x190b,0x100e,0x190c
Apr  8 01:41:13 cfg_server: old wl1_acs_excl_chans:0xd0a5
Apr  8 01:41:13 cfg_server: new wl1_acs_excl_chans:0xd078,0xd07c,0xd080,0xd084,0xd0a5,0xd976,0xd87e,0xd97e,0xd886,0xe17a,0xe27a,0xe37a,0xe08a,0xed72,0xee72,0xef72
Apr  8 01:41:13 cfg_server:  wl_chanspec_changed_action: Need to restart acsd for AVBL update
Apr  8 01:41:13 rc_service: cfg_server 2942:notify_rc restart_acsd
Apr  8 01:41:14 acsd: eth6: Selecting 2g band ACS policy
Apr  8 01:41:14 kernel: In wl_dfs_cac_notify_status chanspec 0xe39b DFS state 0
Apr  8 01:41:17 acsd: eth6: selected channel spec: 0x1009 (9)
Apr  8 01:41:17 acsd: eth6: Adjusted channel spec: 0x1009 (9)
Apr  8 01:41:17 acsd: eth6: selected channel spec: 0x1009 (9)
Apr  8 01:41:17 acsd: eth7: Selecting 5g band ACS policy
Apr  8 01:41:19 wlceventd: wlceventd_proc_event(494): eth7: Deauth_ind 16:09:35:44:D6:EA, status: 0, reason: Station requesting (re)association is not authenticated with responding station (9), rssi:-50
Apr  8 01:41:19 wlceventd: wlceventd_proc_event(511): eth7: Disassoc 16:09:35:44:D6:EA, status: 0, reason: Disassociated because sending station is leaving (or has left) BSS (8), rssi:-50
Apr  8 01:41:24 acsd: eth7: selected channel spec: 0xec32 (52/160)
Apr  8 01:41:24 acsd: eth7: Adjusted channel spec: 0xec32 (52/160)
Apr  8 01:41:24 acsd: eth7: selected channel spec: 0xec32 (52/160)
Apr  8 01:41:24 acsd: acs_csa_handle_request(359): eth7: err from dcs_handle_request:-22
Apr  8 01:41:24 acsd: acs_set_chspec: 0xec32 (52/160) for reason ACS_INIT
Apr  8 01:41:24 kernel: In wl_dfs_cac_notify_status chanspec 0xec32 DFS state 1
Apr  8 01:41:29 wlceventd: wlceventd_proc_event(494): eth6: Deauth_ind 38:B8:00:40:87:5C, status: 0, reason: Unspecified reason (1), rssi:-42
Apr  8 01:41:29 wlceventd: wlceventd_proc_event(530): eth6: Auth 38:B8:00:40:87:5C, status: Successful (0), rssi:-42
Apr  8 01:41:29 wlceventd: wlceventd_proc_event(559): eth6: Assoc 38:B8:00:40:87:5C, status: Successful (0), rssi:-42
Apr  8 01:41:42 wlceventd: wlceventd_proc_event(511): eth7: Disassoc A8:93:4A:65:F1:EF, status: 0, reason: Disassociated because sending station is leaving (or has left) BSS (8), rssi:0
Apr  8 01:41:49 wlceventd: wlceventd_proc_event(511): eth7: Disassoc 6E:C7:72:9F:18:D6, status: 0, reason: Disassociated because sending station is leaving (or has left) BSS (8), rssi:0
Apr  8 01:41:49 wlceventd: wlceventd_proc_event(511): eth7: Disassoc 60:8B:0E:06:13:C1, status: 0, reason: Disassociated because sending station is leaving (or has left) BSS (8), rssi:0
Apr  8 01:42:24 kernel: In wl_dfs_cac_notify_status chanspec 0xec32 DFS state 2
Apr  8 01:42:26 wlceventd: wlceventd_proc_event(530): eth7: Auth A8:93:4A:65:F1:EF, status: Successful (0), rssi:0
Apr  8 01:42:26 wlceventd: wlceventd_proc_event(559): eth7: Assoc A8:93:4A:65:F1:EF, status: Successful (0), rssi:-52
Apr  8 01:42:32 wlceventd: wlceventd_proc_event(494): eth7: Deauth_ind 5C:E9:1E:97:CB:14, status: 0, reason: Disassociated due to inactivity (4), rssi:-37
Apr  8 01:43:45 wlceventd: wlceventd_proc_event(540): eth7: ReAssoc A8:93:4A:65:F1:EF, status: Successful (0), rssi:-56
Apr  8 01:43:58 wlceventd: wlceventd_proc_event(530): eth7: Auth 60:8B:0E:06:13:C1, status: Successful (0), rssi:-40
Apr  8 01:43:58 wlceventd: wlceventd_proc_event(559): eth7: Assoc 60:8B:0E:06:13:C1, status: Successful (0), rssi:-40
Apr  8 01:49:12 wlceventd: wlceventd_proc_event(559): eth7: Assoc 5C:E9:1E:97:CB:14, status: Successful (0), rssi:-41

While Plex client streamed from me, 5g dropped this whole time. I did a full reset before and after installation of Beta2. Will return to 388.1 stable and monitor.

 

[RMerlin]

This fix was in effect reverted with this change:

I will have to review the code, but from what I remember, the fix that I implemented at the time should have been present in the following GPL merge, unless there was a separate regression.

 

[learning_curve]

Can you show more logs in the bottom of the last line? Wow you're approximately 12 hours ahead of me.

There's nothing further in the logs, (since that extract that I posted) that specifically relates to DDNS / asuscomm.com. Nothing.
Yet, I can still check & confirm that all is well, in all of the same ways that I previously posted HERE
Yes, I'm in Vietnam, which is in the Indochina Time Zone. It's a long walk to (I'm guessing?) North America from here

To answer your questions
a. ISP service - FTTH Dynamic DHCP WAN conneection
b. GT-AX6000 reset to factory default after B2 update.
-DDNS service page defaults to off-- I can't make the change cause there is a javascript error.
c. I've seen the inability of inadyn to update the DDNS server with my IPv6 IP from an RT-AX88U 388.2 alpha1 before it was replaced with the RT-AX6000

Good to know. Thanks.
I didn't have the problem you have outlined in c) so there is probably a subtle setup difference somewhere in amongst all of these possible locations, but see below too

And finally, you probably have not seen error in that page if you updated on top. Try to change ipv6 update to no then apply, see if it takes.

Understood. I'm not going to make that change (for now) as AFAIK that would put me in the same situation that you're in at present wouldn't it? (stuck 'cos of the javascript error). I may have been pretty fortunate here, in that I've always had DDNS set to "Active" c/w IPv6 Update set to "Yes" and all recent firmware upgrades have been "dirty" and so not involved a full reset to factory default.

 

[learning_curve]

@RMerlin Sorry to bring this up again but I stumbled upon an old post that mentioned this change:

386.2_2 (13-Apr-2021)
  - FIXED: IPv6 pings were blocked if sent below the rate limit
           instead of above (issue introduced in 42095)

This references this:

rc: fix incorrect ICMPv6 rate control rule · RMerl/asuswrt-merlin.ng@6ee9136

Third party firmware for Asus routers (newer codebase) - rc: fix incorrect ICMPv6 rate control rule · RMerl/asuswrt-merlin.ng@6ee9136

github.com

This fix was in effect reverted with this change:

https://github.com/RMerl/asuswrt-merlin.ng/commit/c990d2c05b118ac415601fb9a4eb8c2fb429b7c7

Merge with 388_20566 (from RT-AX88U) + 5.02axhnd SDK update …
Notes:
  - rc/firewall.c was repatched from the ground up, dropping some
    of our previous changes for the time being, as the 388 changes to
    the firewall will need to be reviewed first

FWIW @ColinTaylor I've rechecked, as I'm on a later firmware release than last time, but my results are the same as I posted HERE previously

 

[archiel]

Indeed. There are quite a lot of config variables (not only the IPv6 DDNS), just on one router model, within one firmware release.
I've posted in this thread, because (in my case) the thread related Merlin 388.2_beta2 firmware release, doesn't produce any IPv6 DDNS issues for me (with my setup)

We do have different ISP's and different router models, but ignoring those two factors for a moment;
FWIW I also use Native IPv6 (PPP Interface), DHCP-PD, Stateless and Cloudfare DNS servers (I have 2 x IPv6 & 2 x IPv4 entries within the DNS-over-TLS server list)
It might be, that the DNS config I use (pics below) is different than your own, so that's why, I don't need any additional scripts for IPv6 DDNS, as you do?

Looking at your configs, the differences between these and mine are

WAN (Advanced_WAN_Content.asp)
I am using Automatic IP + Client-identifier (Option61) not PPPoE
Using Quad 9 rather than ISP DNS servers
Enable DNS Rebind protection + Enable DNSSEC support are both set to No. Setting the latter to "Yes" is incompatible with Unbound

IPv6 (Advanced_IPv6_Content.asp)
I am using the Cloudflare IPv6 DNS servers rather than LAN IPv6 Link-Local Address in IPv6 DNS Settings
Interface and Accept Default Route not options, as these are PPPoE linked options

I did not follow the reason for choosing LAN IPV6 Link-Local Address (shown on /Main_IPv6Status_content.asp) as I understood that using an fe80:: (link-local address) would prevent any DNS lookup traversing the WAN interface. I did try it (just in case) and immediately lost IPv6 connectivity.

DNSDirector (/DNSDirector.asp)
Same settings

Advanced Tweaks (/Tools_OtherSettings.asp)
The same other than Wan: Use local caching DNS server as system resolver = No. "Yes" is also incompatible with Unbound.

I tried changing my settings to the same as yours, other than switching WAN Connection type (for obvious reasons) and still (1) always needed my script and (2) needed global IPv6 DNS server in IPv6 DNS Settings.
It suggests that the reason I need the script are either router specific (AX88U vs AX86U) or WAN Connection type (Automatic IP vs PPPoE).

 

[learning_curve]

Looking at your configs, the differences between these and mine are

WAN (Advanced_WAN_Content.asp)
I am using Automatic IP + Client-identifier (Option61) not PPPoE

With my ISP, PPPoE is the only option, but it works perfectly for me, so can't complain!

Using Quad 9 rather than ISP DNS servers
Enable DNS Rebind protection + Enable DNSSEC support are both set to No. Setting the latter to "Yes" is incompatible with Unbound

All of mine are Cloudfare DNS servers (not the ISP's DNS servers) but they're not visible (out of shot) in those images that I posted previously.
They are common for IPv4 and IPv6 (servers of both protocols are specified) and utilised via DoT which is visible in those images.

IPv6 (Advanced_IPv6_Content.asp)
I am using the Cloudflare IPv6 DNS servers rather than LAN IPv6 Link-Local Address in IPv6 DNS Settings
Interface and Accept Default Route not options, as these are PPPoE linked options

I did not follow the reason for choosing LAN IPV6 Link-Local Address (shown on /Main_IPv6Status_content.asp) as I understood that using an fe80:: (link-local address) would prevent any DNS lookup traversing the WAN interface. I did try it (just in case) and immediately lost IPv6 connectivity.

DNSDirector (/DNSDirector.asp)
Same settings

Advanced Tweaks (/Tools_OtherSettings.asp)
The same other than Wan: Use local caching DNS server as system resolver = No. "Yes" is also incompatible with Unbound.

Using Quad 9 for IPv4 DNS and Cloudfare for IPv6 is quite different that my own config. My use of LAN IPv6 Link-Local Address in IPv6 DNS Settings together with Wan: Use local caching DNS server as system resolver = "Yes" together with my use of IPv4 / IPv6 DNS servers via DoT (see above ^^), all came about after lots of reading / self-tests, which started, after reading & following THIS Tutorial. Needless to say, I do have a very different experience than you have had, specifically when using the LAN IPv6 Link-Local Address in IPv6 DNS Settings. After reading your reply, It's clear to me now, that replicating my chosen config and using Unbound at the same time, is impossible anyway. Despite us both currently using Merlin 388.2_beta2 firmware, Unbound (which I don't use) is perhaps our biggest consequential, config difference, besides the previous caveats.

I tried changing my settings to the same as yours, other than switching WAN Connection type (for obvious reasons) and still (1) always needed my script and (2) needed global IPv6 DNS server in IPv6 DNS Settings.
It suggests that the reason I need the script are either router specific (AX88U vs AX86U) or WAN Connection type (Automatic IP vs PPPoE).

Yes, I agree, although perhaps the use of Unbound too? It's a lot of work / not worth the time & effort involved, to test, when you're not using Unbound, so let's leave it as a 'maybe'.

 

[archiel]

With my ISP, PPPoE is the only option, but it works perfectly for me, so can't complain!

All of mine are Cloudfare DNS servers (not the ISP's DNS servers) but they're not visible (out of shot) in those images that I posted previously.
They are common for IPv4 and IPv6 (servers of both protocols are specified) and utilised via DoT which is visible in those images.

Using Quad 9 for IPv4 DNS and Cloudfare for IPv6 is quite different that my own config. My use of LAN IPv6 Link-Local Address in IPv6 DNS Settings together with Wan: Use local caching DNS server as system resolver = "Yes" together with my use of IPv4 / IPv6 DNS servers via DoT (see above ^^), all came about after lots of reading / self-tests, which started, after reading & following THIS Tutorial. Needless to say, I do have a very different experience than you have had, specifically when using the LAN IPv6 Link-Local Address in IPv6 DNS Settings. After reading your reply, It's clear to me now, that replicating my chosen config and using Unbound at the same time, is impossible anyway. Despite us both currently using Merlin 388.2_beta2 firmware, Unbound (which I don't use) is perhaps our biggest consequential, config difference, besides the previous caveats.

Yes, I agree, although perhaps the use of Unbound too? It's a lot of work / not worth the time & effort involved, to test, when you're not using Unbound, so let's leave it as a 'maybe'.

I should clarify that I only use Quad 9 for the default (start-up) DNS servers, I have the 4 Cloudflare DNS servers in the DOT section and these take over once the boot process is done. I will test without Unbound and with LAN IPv6 Link-Local Address in IPv6 DNS Settings and Wan: Use local caching DNS server as system resolver = "Yes" just to see if that helps.

UPDATE: Removing Unbound and changing the settings to match yours did not help. The script is still needed for DDNS and using the Router link-local address in the IPv6 DNS Settings box still results in the loss of IPv6 connectivity, so at least we can remove Unbound from being a factor.

 

[learning_curve]

It suggests that the reason I need the script are either router specific (AX88U vs AX86U) or WAN Connection type (Automatic IP vs PPPoE).

After your update (below) it does now look like, that in your case, your earlier suggestion ^^ is indeed, the most likely possible cause of the issue you have, that requires a script (if we also exclude the possibility of the IPv6 config that's provided by your ISP). If we had to place a bet (based on what we currently know), I'd go for WAN Connection type (my best guess!)

UPDATE: Removing Unbound and changing the settings to match yours did not help. The script is still needed for DDNS and using the Router link-local address in the IPv6 DNS Settings box still results in the loss of IPv6 connectivity, so at least we can remove Unbound from being a factor.

 

[archiel]

After your update (below) it does now look like, that in your case, your earlier suggestion ^^ is indeed, the most likely possible cause of the issue you have, that requires a script (if we also exclude the possibility of the IPv6 config that's provided by your ISP). If we had to place a bet (based on what we currently know), I'd go for WAN Connection type (my best guess!)

Also my guess - it would seem that Automatic IP + Option 61 + IPv6 doesn't attach the WAN IPv6 address to the WAN interface.

 

[ryosuke]

hmmm.. still no news of 388.2 for XT12?

 

[Ranger802004]

It may be that whether IPV6 Asus DDNS works as intended is related to how IPv6 is configured and/or the router model. For instance on my RT-AX88U, I am using Native IPv6, DHCP-PD, Stateless and Cloudflare DNS servers. IPv6 works fine, but (out of the box) DDNS fails with

ddns: eth0 has not yet obtained an WAN IPv6 address

as with this setup eth0 only has a link local (fe80:...:1) address and where the WAN IPv6 is attached to br0

I resolve this by creating ipv6add.sh in /jffs/addons/ddnsipv6

#!/bin/sh
sleep 20s
ip -6 address add dev eth0 $(nvram get ipv6_rtr_addr)/128
nvram set ddns_ipv6_update=1
service restart_ddns

effectively attaching the br0 IPv6 address to eth0 and calling the script from post-mount by adding

sh /jffs/addons/ddnsipv6/ipv6add.sh

The sleep variable may need to be changed depending on what else is running at boot, as it needs to be long enough for the ISP IPv6 addresses to be setup (these are much slower than the IPv4 ones)

I have IPv6 DDNS working as well as OpenVPN IPv6 routing utilizing ULAs on a site to site tunnel.

 

[RMerlin]

hmmm.. still no news of 388.2 for XT12?

I got its GPL this morning. Bad news is, it's based on a different GPL version due to bugfixes that were required for Zen Wifi devices, and that GPL code isn't compatible with the binary blobs of the other models. I haven't decided yet what to do with this.

 

[RMerlin]

This references this:

rc: fix incorrect ICMPv6 rate control rule · RMerl/asuswrt-merlin.ng@6ee9136

Third party firmware for Asus routers (newer codebase) - rc: fix incorrect ICMPv6 rate control rule · RMerl/asuswrt-merlin.ng@6ee9136

github.com

That specific fix is still there (logaccept instead of logdrop):

                fprintf(fp_ipv6, "-A ICMP_V6 -p ipv6-icmp --icmpv6-type 128 %s -j %s\n",
                                (nvram_get_int("fw_dos_x") ? "-m limit --limit 1/s" : ""),
                                (nvram_get_int("fw_dos_x") ? "RETURN" : logaccept));

This is a regression that was caused by a different code change (using RETURN instead of ACCEPT makes it hit the final DROP rule of the INPUT chain).

 

[RMerlin]

Globally on WAN.

I just created a lab setup with two routers, setting up a site-to-site OpenVPN tunnels between the two. Regardless on whether I have IPv6 enabled or disabled on their WAN interface (each with their own /64), after two hours of fiddling with this, I'm unable to reproduce your issue. Two laptops connected on each side of the tunnel are able to ping one another, regardless of if IPv6 is enabled or disabled.

I recommend you make sure that when pinging, your clients aren't trying to resolve the remote end using an IPv6, which would not get routed through the tunnels. Make sure you test using IPv4, and that the firewalls on both clients are set to accept the traffic that will come from a different subnet. Also make sure that you are pushing routes on both sides (typically, by setting the server settings to "LAN only", and setting up a custom client config on that server to add the route to the client side's network). Also make sure you don't have any subnet conflicts.

I can't think of any technical reason why enabling or disabling IPv6 would have any impact on the configuration, since the client doesn't support IPv6 anyway, so everything firewall-wise is configured on the IPv4 iptable tables.

 

[PR3MIUM]

Dirty Update, Uptime 1 Day 20 hours:

No Errors so far, just MIC messages maybe because of AES/WPA3 ?

Apr  6 05:30:09 hostapd: eth6: STA xx:xx:xx:xx:xx WPA: received EAPOL-Key with invalid MIC

Push ?

 

[Treadler]

Push ?

WPA3 here. Log levels ‘notice’ & ‘info’.
No ‘mic’ references seen in log.

 

[Olivier]

I got its GPL this morning. Bad news is, it's based on a different GPL version due to bugfixes that were required for Zen Wifi devices, and that GPL code isn't compatible with the binary blobs of the other models. I haven't decided yet what to do with this.

Will be a pity But anyway thanks a lot for the job.

 

[Pocah]

I am not a frequent or experienced user here, so forgive me if this post is out of place or just silly, but I have noticed that when I any of the 5GHz channels, the LEDS on my AX11000 Pro remain on. Does this mean the channels are still on, or just there is a bug in the LED software?

 

[Anubis]

388.1 Stable does not appear to even attempt 160mhz where as the beta does, but drops wifi without rolling back to 80mhz. Will we be able to have the speed of the beta and the stability of the current stable? I posted my logs if they help at all.

 

[Indi]

Just my observations.......may just be my unit but........

Previously had to use Asus beta FW for a stable router.
Lately the Official release 388.22525 has been the most stable release to date for me.
Every other release lost wan/lan even Merlins.

Just tried 388.2 beta2 and it crashes wan/lan like all previous problem FW's for me and also had a problem giving out IP's.
The wifi5ghz seemed weak as my TV couldn't see it,reverted back to 22525 and it connects np.
22237 was a crasher for me but 22525 is stable

syslogs attached are from stable to 388.2beta2 back to stable