Solved IPv6 Native with Prefix Delegation does not provide LAN side IP addresses in any 386 Build on RT-AX56U

[JWoo]

As part of testing why the 386 based builds are unstable in my configuration on my RT-AX56U, I noticed that on the 384.18 build that IPv6 works great and
1) I have 9 devices with LAN side IPv6 addresses and
2) the SYSTEM LOG -> WIRELESS matches the SYSTEM LOG -> IPv6, meaning that the LAN side IPv6 addresses in the WIRELESS log also appear in the IPv6 log and for that matter the routing table.

With earlier usage this month of 386.2-2, 386.3-2 and 386.4 alpha 1, I noticed that I would at most get 1 LAN side IPv6 address assigned and that address never appeared in the IPv6 log. So I decided to go back to 386.1 to see if IPv6 worked on the 1st 386 build using Native, Prefix Delegation, Stateless as my configuration and without use of Stubby.

What I found is that IPv6 using Native, Prefix Delegation, Stateless is broken on all the 386 builds going back to even 386.1. Running 386.1, the system correctly assigns both the LAN IPv6 Address, the Prefix Length and LAN IPv6 Prefix (as shown in IPv6 settings) so it should work on the LAN side even though it does not. If you are also using IPv6 using Native, Prefix Delegation, Stateless as your configuration please check to see if the router is assigning LAN side IPv6 addresses.

Here is the only IPv6 address in the WIRELESS LOG on the 386.1 build (and same result on 386.2-2, 386.3-2 and 386.4 alpha 1):

In the IPV6 log, no IPV6 addresses are reported:

So in short, IPv6 Native with Prefix Delegation & Stateless as in my configuration appears NOT to work correctly on any 386 based build as LAN side IPv6 addresses are not assigned. When I use the same function on 384.18 I get 9 devices with IPv6 addresses assigned on the LAN side and all the logs match (WIRELESS, IPv6, ROUTING TABLE). @RMerlin sharing this as there does appear to be a bug on the 386 builds with IPv6.

 

[dave14305]

What kind of output do you get with these commands?

ip -6 addr show scope global
grep "\bra\b" /etc/dnsmasq.conf
grep dhcp6_client /tmp/syslog.log*
ps | grep odhcp6c
nvran show 2>/dev/null | grep ^ipv6_prefix
cat /tmp/ipv6_*

I don’t think Merlin spends much time on IPv6 since he can’t test it himself. I wonder if anything is odd because of the eth4 wan ifname.

 

[heysoundude]

I don’t think Merlin spends much time on IPv6 since he can’t test it himself.

I'm sure one of these days, that will simply happen to change for him, and most of the other people who don't yet have access to Native v6 through their ISP/provider.

 

[JWoo]

What kind of output do you get with these commands?

ip -6 addr show dev br0
grep "\bra\b" /etc/dnsmasq.conf
grep dhcp6_client /tmp/syslog.log*
ps | grep odhcp6c

I don’t think Merlin spends much time on IPv6 since he can’t test it himself. I wonder if anything is odd because of the eth4 wan ifname.

I went back to the 384.18 build to get the users up and running but can test this later on late today or tomorrow.

 

[dave14305]

I went back to the 384.18 build to get the users up and running but can test this later on late today or tomorrow.

Capture the same output now to compare with the 386 output later.

 

[archiel]

FWIW this problem does not arise in the 386 firmware for the RT-AX88U (currently on 386.3_2). I am also using Native, Prefix Delegation, Stateless

1) I have 13 devices with LAN side IPv6 addresses and
2) the SYSTEM LOG -> WIRELESS matches the SYSTEM LOG -> IPv6, meaning that the LAN side IPv6 addresses in the WIRELESS log also appear in the IPv6 log.

 

[JWoo]

Capture the same output now to compare with the 386 output later.

Will do

 

[JWoo]

FWIW this problem does not arise in the 386 firmware for the RT-AX88U (currently on 386.3_2). I am also using Native, Prefix Delegation, Stateless

1) I have 13 devices with LAN side IPv6 addresses and
2) the SYSTEM LOG -> WIRELESS matches the SYSTEM LOG -> IPv6, meaning that the LAN side IPv6 addresses in the WIRELESS log also appear in the IPv6 log.

Well the mystery deepens! Glad it is working for you.

 

[dave14305]

Will do

I updated my original post with additional output to gather. You don’t have to share it, but look for the differences.

You can also watch live on the router what addresses are being used on the LAN devices

ip -6 monitor neigh dev br0

Ctrl-C to cancel.

 

[JWoo]

I updated my original post with additional output to gather. You don’t have to share it, but look for the differences.

You can also watch live on the router what addresses are being used on the LAN devices

ip -6 monitor neigh dev br0

Ctrl-C to cancel.

Much appreciated. This is very useful. Will circle back once I have the comparison done.

 

[JWoo]

Thanks @dave14305. Appreciate your troubleshooting expertise. I ran your commands on both builds and here are my findings:

- From your shell commands, the parameters for both the 384.18 and the 386.3-2 builds are identical on my router.
- The commands confirm what the GUI shows. The 384.18 build is connecting 9 devices on the LAN side using IPv6, while the 386.3-2 build is not.

My $0.02 is that there is a software fault in the 386 builds for at least the RT-AX56U. I have no way of knowing if this only affects the RT-AX56U or also other models.

UPDATED: As soon as I flashed the 384.18 build over the 386.3-2 build, I immediately had all my devices grabbing IPv6 addresses. There is clearly something wrong with the 386 builds in terms of IPv6 native w/prefix delegation.

 

[dave14305]

My $0.02 is that there is a software fault in the 386 builds for at least the RT-AX56U. I have no way of knowing if this only affects the RT-AX56U or also other models.

Based on what differences?

Your guest networks aren’t using slot #1 are they (br1 or br2)? That might affect the results.

 

[JWoo]

Based on what differences?

Your guest networks aren’t using slot #1 are they (br1 or br2)? That might affect the results.

The parameters are the same such as

mtu 1500
qlen 1000
ra-param=br0,10,600
enable-ra
quiet-ra
dhcp-range=lan,::,constructor:br0,ra-stateless,64,600

Yes I am using guest networks 1 and 2 because Asus designed the function to give these 2 network unique IP address ranges not shared with the main networks. This works fine on 384.18. I could test this by using another guest network on 386.3-2.

 

[dave14305]

The parameters are the same such as

mtu 1500
qlen 1000
ra-param=br0,10,600
enable-ra
quiet-ra
dhcp-range=lan,::,constructor:br0,ra-stateless,64,600

Yes I am using guest networks 1 and 2 because Asus designed the function to give these 2 network unique IP address ranges not shared with the main networks. This works fine on 384.18. I could test this by using another guest network on 386.3-2.

If there is no router advertisement on br1 or br2, Guest Network 1 clients have no chance to get an IPv6 address. And if your ISP only delegates a /64 prefix, you probably can’t customize this.

But this would expel the differences between 384 and 386 - the behavior of Guest Network 1. How many clients are not on guest networks?

 

[JWoo]

Thanks @dave14305 for your help & knowledge. The Asus guest networks on the 386 builds are really messed up as compared with the old 384 code base. So:

Guest Network 1: uses 192.168.101.x and 192.168.102.x IP range, optimized for AIMesh and does not support IPv6 (using Guest Network 1 is probably behind all my router crashes)
Guest Network 2: uses same IP range as main router, works with IPv6
Guest Network 3: uses same IP range as main router, works with IPv6, but has a lot of excess code due to Alex and IFTTT

So I went ahead and used Guest Network 2, which does work with IPv6 although a lot of the host names in the IPv6 log wind up being an asterisk *. I don't really like that it uses the same IP range and just uses rules but that is how it is.

 

[JWoo]

This is "solved". Here is a summary.

Asus provides 3 guest networks, which I believe is a closed source function from Asus.

Guest Network 1: uses 192.168.101.x and 192.168.102.x IP range, optimized for AIMesh and does not support IPv6 (although that is not documented by Asus as such)
Guest Network 2: uses same IP range as main router, works with IPv6
Guest Network 3: uses same IP range as main router, works with IPv6, but has a lot of excess code due to Alex and IFTTT

If you use Guest Network 1 and also are using the IPv6 function, your router will crash frequently (appears to be an interaction between the Asus closed source guest network function and the Broadcom mcast driver). The workaround is to use Guest Network 2 as this guest network does not have any added functions in the Asus code. I have been using this configuration for 3 days now and it is stable with no crashes so far.

As IPv6 is a very common function with 40% deployment across US, Mexico and Canada, it would seem this would be something Asus would want to fix. IPv6 deployment as measured by Google: https://www.google.com/intl/en/ipv6/statistics.html

@RMerlin this thread can be closed and marked as Solved with a workaround. Not sure how you report information back to Asus, but these problems with Guest Network 1 also causes crashes on the stock firmware when IPv6 is provisioned on the router.

 

[dave14305]

Not sure how you report information back to Asus, but these problems with Guest Network 1 also causes crashes on the stock firmware when IPv6 is provisioned on the router.

Load the stock firmware and use the Feedback tab to send a report to Asus.