Why not Zoidberg? (new IPv6 test alpha builds)

[RMerlin]

Howdy folks,

I just uploaded test builds of Asuswrt-Merlin. While these are based on 376_3626, the main goal of this test build is to try out the new IPv6 code, which has been enabled in these builds.

EDIT (14-Dec): I got a Frankenbuild working for the RT-AC87U. It's a mixture of RT-N14's 3677 GPL, RT-AC68's 2769 GPL, and 378_3123 Asus beta FW. No wifi update, because I have no GPL with an updated driver.

Test builds have been uploaded to this folder:

https://www.mediafire.com/folder/ftf9kjixr1a5f//Misc

This build replaces the current IPv6 code based on radvd + rdnssd in favor of a new architecture based around dnsmasq and odhcp6c. These new userspace services are generally more modern, and probably also cleaner. Asus wrote that code in the past couple of months, but they haven't enabled it yet in their official releases (the current beta RT-AC87U is the first time I've seen them enable it).

So, I am mostly interested in seeing user feedback regarding IPv6 support. Make sure to mention the following info with your feedback:

• Your ISP
• The type of IPv6 connection (Native, 6rd, 6in4 tunnel, etc...)
• If you had any issue with previous firmware versions
• How this one is working out for you

(for those of you who are new around - yes, the thread title is silly. It's an old tradition when I release such test builds to go with a rather original build name / motto. )

SHA256 checksums:

9bd2eadd099db42b094d4db94c9fc144692b33029aa333f9f2f844fc1d6cf754  RT-AC56U_3.0.0.4_376.49_alpha2.trx
fd6ee895c5749d04e85b5708f8577356032f892a49ce40b72c1468540096447e  RT-AC66U_3.0.0.4_376.49_alpha2.trx
64c516f2dc9490854a5637ad9eafc5d891f9a362a87260511dedf0c25ce9f1ab  RT-AC68U_3.0.0.4_376.49_alpha2.trx
9fca63121c8d9e483cc3e9c6cf762e728f1278edfe995c55eccabbe259524dbb  RT-N16_3.0.0.4_376.49_alpha2.trx
0c2ab960427f234b88b49e08f0ed6321c41b0776b64249a6edefbb68822e97b7  RT-N66U_3.0.0.4_376.49_alpha2.trx
0965c3792ed22fc3a9e709fe556a861a60135d8cac7758e132bfe6b42adf0de0  RT-AC87U_3.0.0.4_376.49_alpha4.trx

 

[RMerlin]

For those interested, Asus also did a lot of changes to the USB modem support in 3626, so if you were previously having issues with your USB 3G/4G modem, it might be worth trying out this build.

 

[charlie2alpha]

Nice, I will tinker with this later today as I am on work atm. Will attempt a dirty flash on my AC56U and see how it goes. I did not really had issues with radvd itself, but dhcp6c (or rather the external script it was calling, and that is ASUS' fault) on the 378 firmware was screwing up the LAN address of br0 often. Let's see if they fixed that.

 

[saintdev]

For those of you interested in testing this, I have been running personal test builds for a couple months, ever since Asus added it. I had actually started work on integrating odhcp6c, but Asus beat me to it.

If you are on Comcast or another ISP that provides native IPv6 with DHCP-PD, this should vastly improve the reliability of your IPv6 connection. The odhcp6 client an enormous improvement over the WIDE-dhcp6c + rdnssd mess that Asus previously had going on.

 

[RogerSC]

I'm giving it for a test spin here on Comcast *smile*, taking it around the block, as it were. So far (not very long) it's doing fine. We'll see.

 

[neil0311]

Do you recommend a full, hard reset coming from 376.48_1 (or when rolling back to 376.48_1)?

 

[charlie2alpha]

Had a bit of a hard time making this work without losing my settings but seems OK now. I had to deactivate IPv6, reactivate it, reboot, and then it worked.

One issue is that my ISP uses DHCP PD but also assigns a SLAAC address to the ppp0 interface. With the 378_1 I only had the SLAAC address on ppp0 and an address from the prefix dhcp6c got in br0. With this alpha build ppp0 receives an additional IPv6 address from the prefix ending up with 2 addresses, which is redundant but is does not harm.

EDIT: There's also a small cosmetic issue, in the GUI, at the top left where you have "Operation Mode", "Firmware" and "SSID" information it mentions my 2.4GHz SSID correctly but says "undefined" for my 5GHz SSID. It's only cosmetic because the SSID is reported correctly everywhere else in the GUI and the WiFi itself works just fine.

 

[RMerlin]

Do you recommend a full, hard reset coming from 376.48_1 (or when rolling back to 376.48_1)?

Asus does recommend it with 3626, mostly for wifi. I'd say only do one if you experience wifi-specific issues.

I will recommend a factory default reset once the final 376_49 is released however.

 

[RMerlin]

Had a bit of a hard time making this work without losing my settings but seems OK now. I had to deactivate IPv6, reactivate it, reboot, and then it worked.

One issue is that my ISP uses DHCP PD but also assigns a SLAAC address to the ppp0 interface. With the 378_1 I only had the SLAAC address on ppp0 and an address from the prefix dhcp6c got in br0. With this alpha build ppp0 receives an additional IPv6 address from the prefix ending up with 2 addresses, which is redundant but is does not harm.

Isn't there an option that lets you chose between stateless and stateful on the IPv6 settings page? If so, try experimenting with it. But otherwise, yes, having two different IPs shouldn't be a problem.

 

[charlie2alpha]

Isn't there an option that lets you chose between stateless and stateful on the IPv6 settings page? If so, try experimenting with it. But otherwise, yes, having two different IPs shouldn't be a problem.

I'm using stateless, but this option only affects whether the prefix will be advertised via RA or by DHCPv6 server, won't affect anything on the WAN side. Not a real issue to be honest, just noting the little details.

 

[RMerlin]

I'm using stateless, but this option only affects whether the prefix will be advertised via RA or by DHCPv6 server, won't affect anything on the WAN side. Not a real issue to be honest, just noting the little details.

You're right - I just booted my test router, and the setting indeed lies in the LAN section. The WAN section only lets you enable or disable DHCP-PD.

 

[amigohd]

Builds are available for all models except for the RT-AC87U, as I don't have compatible versions of the closed source binaries matching the 3626 GPL code.

any idea if and when you can put out a version for the AC87U @RMerlin?

 

[RMerlin]

any idea if and when you can put out a version for the AC87U @RMerlin?

It's up to Asus. As I wrote in the OP, they haven't released any new GPL for the AC87U, and the previous closed source components don't work with the 3626 source code. Until they do, it's impossible for me to release any new AC87U build.

 

[RogerSC]

No apparent problems yet.

Found these in the log:

Dec  3 23:42:29 dnsmasq-dhcp[682]: DHCPSOLICIT(br0) 00:01:00:01:1b:eb:4f:58:44:8a:5b:bc:44:09 
Dec  3 23:42:29 dnsmasq-dhcp[682]: DHCPADVERTISE(br0) 00:01:00:01:1b:eb:4f:58:44:8a:5b:bc:44:09 no addresses available
Dec  4 08:30:24 dnsmasq-dhcp[682]: DHCPSOLICIT(br0) 00:01:00:01:1b:eb:4f:58:44:8a:5b:bc:44:09 
Dec  4 08:30:24 dnsmasq-dhcp[682]: DHCPADVERTISE(br0) 00:01:00:01:1b:eb:4f:58:44:8a:5b:bc:44:09 no addresses available
Dec  4 09:42:23 dnsmasq-dhcp[682]: DHCPSOLICIT(br0) 00:01:00:01:1b:eb:4f:58:44:8a:5b:bc:44:09 
Dec  4 09:42:23 dnsmasq-dhcp[682]: DHCPADVERTISE(br0) 00:01:00:01:1b:eb:4f:58:44:8a:5b:bc:44:09 no addresses available

Don't know what they mean, but they haven't affected what I'm seeing in my client usage as far as I can tell.

Update: just for yucks I just checked all my clients, and all IPv6 capable clients have IPv6 available. All ports are in stealth mode, as well *smile*.

 

[jim769]

First, Thanks Merlin for jumping on this problem. Just installed the Alpha version and happy to report v6 is working in fact i didnt even have to play around rebooting it just worked the first time thats a change in itself. I will see over the next 24 hours if v6 holds out unlike the 48_1 build.

Also wanted to ask when i go to rename a client i noticed there is a small lock icon the default is unlocked what does this lock icon mean ?

@Roger your sys logs i wonder if that has anything to do with the comcast overflows not sure if Merlin has that patch in the Alpha build maybe he can tell us. I have not had enough up time yet to see them.

EDIT: Comcast, Native DHCPv6, Was not working correctly in previous build.

 

[charlie2alpha]

Those log entries I have too, it's just the stupid windows 8.1 clients insisting to ask for an address via DHCP ignoring the fact that the RA tells them to get a SLAAC address.

 

[RogerSC]

@Roger your sys logs i wonder if that has anything to do with the comcast overflows not sure if Merlin has that patch in the Alpha build maybe he can tell us. I have not had enough up time yet to see them.

Just checked, yes the ip6tables command is there to filter the neighbor solicitation messages in this firmware:

ip6tables -L -v -t mangle

shows that. The -v isn't really necessary, but I'm in the habit of using it so that I can see how many packets are being handled.

 pkts bytes target     prot opt in     out     source               destination
 131K 9466K DROP       ipv6-icmp    eth0   any     anywhere             ff02::1:ff00:0/104   ipv6-icmp neighbour-solicitation

So just a mere 131K messages (~10MB) overnight *smile*.

Update: ISP is Comcast, connection type is DHCP6-PD. IPv6 working correctly in RT-AC68U_3.0.0.4_374.43_2-06j9527, not in RT-AC68U_3.0.0.4_376.48_1. In RT-AC68U_3.0.0.4_376.48_1, dropped the IPv6 WAN addresses after a few hours. Good for over 12 hours on the alpha firmware, no problems thus far. Nothing out of the ordinary, other than the log entries in the post above.

 

[RMerlin]

When reporting results, please make sure to also provide the info I mentioned in the first post, especially

- ISP name
- Connection type used by your ISP for IPv6
- Was it working correctly or not in previous versions

I want to see if the new code actually resolves previous issues, or it just works for people who weren't having any problem with the old code anyway.

 

[RMerlin]

First, Thanks Merlin for jumping on this problem.

All the credit actually goes to Asus there, I simply enabled the code they had been working on these past few months.

Also wanted to ask when i go to rename a client i noticed there is a small lock icon the default is unlocked what does this lock icon mean ?

New feature in 3626, I think it's to generate a static reservation, however I don't know if it works yet or not. At this point I am only looking at the IPv6 feedback, I haven't finalized the rest regarding the 3626 merge, and I haven't studied the changes Asus did in 3626 either.

 

[saintdev]

No apparent problems yet.

Found these in the log:

Dec  3 23:42:29 dnsmasq-dhcp[682]: DHCPSOLICIT(br0) 00:01:00:01:1b:eb:4f:58:44:8a:5b:bc:44:09 
Dec  3 23:42:29 dnsmasq-dhcp[682]: DHCPADVERTISE(br0) 00:01:00:01:1b:eb:4f:58:44:8a:5b:bc:44:09 no addresses available
Dec  4 08:30:24 dnsmasq-dhcp[682]: DHCPSOLICIT(br0) 00:01:00:01:1b:eb:4f:58:44:8a:5b:bc:44:09 
Dec  4 08:30:24 dnsmasq-dhcp[682]: DHCPADVERTISE(br0) 00:01:00:01:1b:eb:4f:58:44:8a:5b:bc:44:09 no addresses available
Dec  4 09:42:23 dnsmasq-dhcp[682]: DHCPSOLICIT(br0) 00:01:00:01:1b:eb:4f:58:44:8a:5b:bc:44:09 
Dec  4 09:42:23 dnsmasq-dhcp[682]: DHCPADVERTISE(br0) 00:01:00:01:1b:eb:4f:58:44:8a:5b:bc:44:09 no addresses available

Don't know what they mean, but they haven't affected what I'm seeing in my client usage as far as I can tell.

Update: just for yucks I just checked all my clients, and all IPv6 capable clients have IPv6 available. All ports are in stealth mode, as well *smile*.

This is normal for stateless IPv6.

What is happening is, the device is sending out a dhcp request for an IPv6 address (DHCPSOLICIT). Because you are using stateless auto configuration, dnsmasq doesn't have any addresses to give out, so it informs the device no addresses are available (DHCPADVERTISE). The device should then fall back to stateless auto configuration once it determines it is not going to receive an address from dhcp.