Why not Zoidberg? (new IPv6 test alpha builds)

[PabloAbonia]

1. Time Warner Cable

2. Native mode

3. Native mode was always very touchy, and would fail after a few hours, with no IPV6 address. For alpha 2 it fails periodically, but restore itself after a while.



When testing with IPV6 (http://test-ipv6.com) I am getting both totally normal 10/10 results and 0/10 at times. The two consistent error message I get are for problems with PMTUD, and inability to ping numeric IPV6 addresses.



When testing with the Chappell family port scanner, all ports are steal they'd except for the yellow echo reply.



Prior to doing a factory reset, several ports were partially open (yellow), meaning it could be detected but not connected to. So a reset appears to be necessary, at least for me.



The DNS screen is not right, as it only displays a partial a screen which is missing the top.



There is no IPV6 (including site local) when in access point mode (rt-ac68u). I also can pin



The PMTUD Is most problematic as it is causing timeouts, and plane failure.







Pablo

Update. I far as I can tell, there is no PMTUD problems on the router, but some of my problems appear to be related to problems with Time Warner. Traceroute won't work at the first hop out or the last hop in.



More importantly there appears to be continued problems with the DDNS page, as I can not setup a tunnel with tunnelbroker anymore. All of the upper header and left navigation columns are gone when you first reach the page, and the only way back is via the general 192.168.1.1 address.



It never saves and looks like this:

Further, if I try to apply an IPV6 configuration such as 6in4, it fails as well (nothing happens).







Pablo

 

[Marcovich]

...Further, if I try to apply an IPV6 configuration such as 6in4, it fails as well (nothing happens).

Now compiling FW .49_alpha3 (commit b55950ba8d) from source "asuswrt-merlin". This bug is present After configure the IPv6 Internet setting in WEBUI, buton "Apply" not pressed and setting not save.

P.S. Router RT-AC56U.

 

[RMerlin]

Now compiling FW .49_alpha3 (commit b55950ba8d) from source "asuswrt-merlin". This bug is present After configure the IPv6 Internet setting in WEBUI, buton "Apply" not pressed and setting not save.

P.S. Router RT-AC56U.

I haven't been able to test the 6in4 (or anything related to IPv6) lately because I was unable to get a working firmware for the RT-AC87U (and didn't have time to completely reconfigure an AC68U and switch routers). Now that I managed to get a Frankenbuild working (pieces of a binary-only beta, pieces of an AC68 GPL, and one additional bugfix that wasn't present in the AC68 GPL), I should be able in the coming days to test at least the 6in4 tunnels.

 

[Marcovich]

Thank you, Merlin for fix. Now everything is good

 

[stevocz]

after few days is ipv6 dead. All pc have ipv6 address but ipv6 rounting is not working

ISP antik slovakia
static ipv6 with 64 prefix.

on 44 firmware ipv6 works ok.

this same bug was in older firmware

 

[Gitsum]

AC87 update soon please! I miss Merlin's extra features but the ASUS beta has the Adaptive QOS pages working much better than before...

 

[RMerlin]

AC87 update soon please! I miss Merlin's extra features but the ASUS beta has the Adaptive QOS pages working much better than before...

It's not always under my control. I was unable to get a working RT-AC87U build these past few weeks because the newer DPI components were not compatible with my kernel options, and I had no new GPL tarball to see what Asus had changed.

Fortunately, last night I finally managed to track down which specific kernel option was causing the DPI modules to fail to load. I'm currently uploading an alpha4 build that has the DPI components from 378_3123 for the RT-AC87U. People should still consider themselves lucky, because this was possible in part due to Asus releasing a recent beta for the RT-AC87U. Without that, there would be no way at all to have an RT-AC87U build based on 376_36xx.

People will have to get used to the fact that occasionally, I won't be able to update all models at once. This will become more frequent with the increasing number of closed-source components that are model-specific, and the fact I currently have to cover no less than four different architectures, each with its own set of closed-source components (MIPS SDK5, MIPS SDK6, ARM SDK6, ARM+QTN SDK6). Asus does not update all models at once, so I rarely get all the necessary updates for all four of these platforms at once.

This is another reason why I am increasingly leaning toward dropping the older one of these, namely the MIPS SDK5 platform. That means specifically the RT-N16. Already, I can no longer add most of the new features to that particular model - that means no SNMP support for it, for example. The fact it only has 32KB of nvram is also seriously limiting things. This router is 5 years old now.

 

[RMerlin]

after few days is ipv6 dead. All pc have ipv6 address but ipv6 rounting is not working

ISP antik slovakia
static ipv6 with 64 prefix.

on 44 firmware ipv6 works ok.

this same bug was in older firmware

At this point, it might be time to consider the possibility that the issue could be with the ISP, considering how radically different the new IPv6 code is, and it still has the same issues as before for some particular ISPs.

 

[RMerlin]

OP updated. I uploaded an RT-AC87U alpha4 test build (same location as the other files). This build is somewhat of a Frankenbuild, as Asus hasn't released any GPL update for that router since 2769, so I had to gather components from multiple sources, and do my best to make them work together. So currently it's a mixture of:

- 376_3677 GPL from the RT-N14U for the core FW code
- 378_3123 RT-AC87U beta firmware for the closed source TrendMicro DPI engine and Tuxera filesystem drivers
- 376_2769 GPL for the 2.4 GHz BCM wireless driver
- 376_3602 GPL for the Quantenna wireless + FW

Once again, the primary focus of this release is to gather feedback on the new IPv6 subsystems. I also want to see in this particular case if this mixture of components is at least as stable as the 376.48 build. After testing it for 24 hours, the wifi + DPI engines seem to be fine here.

 

[RMerlin]

I'm on Comcast cable. This seems to be a different issue. odhcp6c gets correctly restarted, it just doesn't pick up an address.

If you found a particular test-case to reproduce this, try disabling the Comcast filtering rule in case it might somehow be interfering.

nvram set ipv6_neighsol_drop=0
nvram commit
service restart_firewall

 

[stevocz]

At this point, it might be time to consider the possibility that the issue could be with the ISP, considering how radically different the new IPv6 code is, and it still has the same issues as before for some particular ISPs.

It is possible but why on 44 firmware works all ok.

my ntfs usb 16GB (usb2 in usb3 port) works, too. But on 49 is writing total and available space 0 b but all files on usb you can read over ftp and samba

 

[RMerlin]

It is possible but why on 44 firmware works all ok.

My IPv6 code used to contain a number of additional patches on top of Asus's code (provided by other contributors who actually had an IPv6 connection to test and develop patches for). Asus has done radical changes to the IPv6 code in recent firmware releases, which forced me to revert all of these additional patches as they no longer applied to the new codebase. So it's possible that one of these patches resolved your issue, or that it's a new issue that only recently appeared with your ISP.

Since my ISP does not support IPv6 (and this is once again an issue I cannot reproduce - my own 6in4 tunnel works fine so far), it will have to be addressed either by Asus or by someone with the ability to reproduce and troubleshoot the issue.

my ntfs usb 16GB (usb2 in usb3 port) works, too. But on 49 is writing total and available space 0 b but all files on usb you can read over ftp and samba

Asus recently did quite a lot of changes regarding their partition management on the webui. While in 376.48 I managed to fix most of the issues they introduced with the new code (see this and this), there might be some issues left, however I have been unable to reproduce any of these so far. Once again, you will probably have to wait for Asus to resolve these remaining issues.

Keep in mind that I'm trying to deal with non-commented code, and I'm alone to do 95% of the work on this. In comparison, Asus has a whole dedicated team of developers, and they understand the code since they wrote it in the first place. Those kind of arcane issues will have to be addressed by them unfortunately.

 

[bodean]

RMerlin.

Been using your 376.48, but see this test build out in the wild. I use Xfinity, and also use the IPv6 fw on it, but have not had any issues. What is being chnaged with IPv6 and these new builds? Are some providers not working right with ASUS fws and ipv6 firewall? Or are there other ipv6 issues?

 

[RogerSC]

RMerlin.

Been using your 376.48, but see this test build out in the wild. I use Xfinity, and also use the IPv6 fw on it, but have not had any issues. What is being chnaged with IPv6 and these new builds? Are some providers not working right with ASUS fws and ipv6 firewall? Or are there other ipv6 issues?

I'm on Comcast (Xfinitiy) as well, and with the RT-AC68P I was losing my IPv6 address after just a few hours with 48_1. With Zoidberg, haven't lost it yet, IPv6 just continues to work.

I'm pretty happy with this firmware. I use mostly the core functionality of my routers, routing and wireless, and the only problem that I've had was having to reboot it once due to slowness. Don't know what happened there, but fine now.

 

[PabloAbonia]

I haven't been able to test the 6in4 (or anything related to IPv6) lately because I was unable to get a working firmware for the RT-AC87U (and didn't have time to completely reconfigure an AC68U and switch routers). Now that I managed to get a Frankenbuild working (pieces of a binary-only beta, pieces of an AC68 GPL, and one additional bugfix that wasn't present in the AC68 GPL), I should be able in the coming days to test at least the 6in4 tunnels.

After compiling the alpha3, I have been able to test IPV6 with a 6in4 tunnel, which appears to be working quite well. I have the ability to simultaneously assign a SLAAC randomized address, as well as a static address for my devices. The static addresses are from within the addresses assigned to my tunnel, while the SLAAC addresses are autogenerated.

enable-ra
quiet-ra
dhcp-range=lan,::,constructor:br0,static,slaac,64,86400s
dhcp-option=lan,option6:23,[::]
dhcp-option=lan,option6:24,hulk.lan
dhcp-lease-max=253
dhcp-authoritative
# Do not read ethers.
# No additional hosts. Using dhcp-hosts instead.
dhcp-range=lan,::,static
dhcp-option=lan,option6:32,600
dhcp-hostsfile=/jffs/configs/dhcp_hosts
host-record=Router,Router.example.lan,192.168.1.1,IPV6AssignedLANAddressForRouter
quiet-dhcp
quiet-dhcp6
domain-needed

The only way I could do the static addresses was via the host record in this format in the dhcp-hosts file:
MA:CA:ADD:RE:SS,Router,192.168.1.1,[InternalIPV6address],infinite

In this configuration, its pretty stable, and passes everything except for hostname on IP ipv6-test.com. I do not have a domain I want to add, and I am not sure if adding DNS to this would be worthwhile.

I haven't checked to see if if IPV6 is working on the access point, as I had some initially difficulties in compiling for the alpha3.

The IPV6 leases as noted on the IPV6 system log come and go, and are comprised of the SLAAC addresses only. However, nslookups provide both the IPV4 and IPV6 addresses, which can be routed and pinged.

I would note that changing between IPV6 connection types, Native to Tunnel 6in4 for example commonly leads to a crash of some kind when it reaches "Complete". At that point a hard reboot is necessary. It is unclear to me if this represents a problem with one of my scripts and I have not had the opportunity to test it.

One final, but not IPV6 related problem: The "Site Survey" under the Advanced --> Wireless, does not provide any information for the 5 Ghz band. This has been ongoing for a variety of releases, and is still noted on 376.49alpha2.

Merlin, Thanks for all of your hard work on this!!! It is much appreciated.

Pablo

 

[RMerlin]

One final, but not IPV6 related problem: The "Site Survey" under the Advanced --> Wireless, does not provide any information for the 5 Ghz band. This has been ongoing for a variety of releases, and is still noted on 376.49alpha2.

This usually happens if you enable MAC filtering, as it also filters out other APs.

Thanks for the feedback on the IPv6 tests.

 

[RMerlin]

What is being chnaged with IPv6 and these new builds? Are some providers not working right with ASUS fws and ipv6 firewall? Or are there other ipv6 issues?

See the first post. To quote it:

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).

 

[RogerSC]

I would like to request that these system log entries be filtered in the next version (Beta?) of this firmware as part of the DHCP queries that can be filtered by choice:

Dec 16 11:35:26 dnsmasq-dhcp[682]: DHCPSOLICIT(br0) 00:01:00:01:1b:eb:4f:58:44:8a:5b:bc:44:09 
Dec 16 11:35:26 dnsmasq-dhcp[682]: DHCPADVERTISE(br0) 00:01:00:01:1b:eb:4f:58:44:8a:5b:bc:44:09 no addresses available
Dec 16 12:21:46 dnsmasq-dhcp[682]: DHCPSOLICIT(br0) 00:01:00:01:1b:eb:4f:58:44:8a:5b:bc:44:09 
Dec 16 12:21:46 dnsmasq-dhcp[682]: DHCPADVERTISE(br0) 00:01:00:01:1b:eb:4f:58:44:8a:5b:bc:44:09 no addresses available
Dec 16 13:07:33 dnsmasq-dhcp[682]: DHCPSOLICIT(br0) 00:01:00:01:1b:eb:4f:58:44:8a:5b:bc:44:09 
Dec 16 13:07:33 dnsmasq-dhcp[682]: DHCPADVERTISE(br0) 00:01:00:01:1b:eb:4f:58:44:8a:5b:bc:44:09 no addresses available
Dec 16 14:00:07 dnsmasq-dhcp[682]: DHCPSOLICIT(br0) 00:01:00:01:1b:eb:4f:58:44:8a:5b:bc:44:09 
Dec 16 14:00:07 dnsmasq-dhcp[682]: DHCPADVERTISE(br0) 00:01:00:01:1b:eb:4f:58:44:8a:5b:bc:44:09 no addresses available
Dec 16 16:03:10 dnsmasq-dhcp[682]: DHCPSOLICIT(br0) 00:01:00:01:19:7b:81:2c:84:8f:69:bb:78:2f 
Dec 16 16:03:10 dnsmasq-dhcp[682]: DHCPADVERTISE(br0) 00:01:00:01:19:7b:81:2c:84:8f:69:bb:78:2f no addresses available
Dec 16 21:21:36 dnsmasq-dhcp[682]: DHCPSOLICIT(br0) 00:01:00:01:1b:eb:4f:58:44:8a:5b:bc:44:09 
Dec 16 21:21:36 dnsmasq-dhcp[682]: DHCPADVERTISE(br0) 00:01:00:01:1b:eb:4f:58:44:8a:5b:bc:44:09 no addresses available
Dec 17 00:35:38 dnsmasq-dhcp[682]: DHCPSOLICIT(br0) 00:01:00:01:1b:eb:4f:58:44:8a:5b:bc:44:09 
Dec 17 00:35:38 dnsmasq-dhcp[682]: DHCPADVERTISE(br0) 00:01:00:01:1b:eb:4f:58:44:8a:5b:bc:44:09 no addresses available
Dec 17 08:56:10 dnsmasq-dhcp[682]: DHCPSOLICIT(br0) 00:01:00:01:1b:eb:4f:58:44:8a:5b:bc:44:09 
Dec 17 08:56:10 dnsmasq-dhcp[682]: DHCPADVERTISE(br0) 00:01:00:01:1b:eb:4f:58:44:8a:5b:bc:44:09 no addresses available

I find that getting a few of these "noise" messages every day makes it harder to look for significant messages in the system log. Since they're routine DHCP messages (apparently), filtering them with the rest of the filterable DHCP messages shouldn't cause any more loss of information.

Otherwise, this firmware is still doing great here.

Thanks.

 

[RMerlin]

I would like to request that these system log entries be filtered in the next version (Beta?) of this firmware as part of the DHCP queries that can be filtered by choice:

The option Quiet DHCP was already extended to also do the same to DHCPv6 queries.

https://github.com/RMerl/asuswrt-merlin/commit/49846548c27bb2593606b77647d48f7ef075cfa3

 

[buckthe]

Comcast, Native with DHCP-PD enabled
ASUS RT-N66W
---
I 'just' upgraded to 376.49_alpha2 over the top of 376.48_3. No issues with the upgrade.

Performance seems better as web sites load quicker in the browsers (IE/Chrome). Before the upgrade there was a pause before a site would load. Not seeing that now.

...I did not have any issues with Comcast before or after the upgrade.

Additional comment:
The "pause" was not seen in 376.48_3 until IPv6 was enabled a few days ago. So it appears 376.49_alpha2 resolved that.