[Fork] Asuswrt-Merlin 374.43 LTS releases (Archive)

[jrmwvu04]

For what it's worth I am not seeing these issues, or any others for that matter. I flashed over from 44D6.

 

[john9527]

Oh, sorry. No, 44D9 pass2

Double checked with the following loads without any problems....

44EA -> 44D9 -> 44EA -> 44E5 -> 44D6 -> 44D9 -> 44EA

Speaking of firmware updates for anyone worried about doing too many.....a quick back of the envelope estimate is that I've done at least 1500 (probably 2000) firmware updates on my AC68P over the course of the fork development (Hope I haven't jinx'ed myself )

 

[luni]

First off, John, thanks for the work with this firmware. This is the first time I've used it after swapping from tomato and I very much appreciate the ability to utilize the full speed of my connection .

Something isn't working properly with IPv6 which was working with tomato. When I use https://test-ipv6.comcast.net/ on a wired desktop I pass 0/10 tests.

Here's my System Log -> IPv6 output (periods for redactions):

IPv6 Connection Type: Native with DHCP-PD
WAN IPv6 Address: 2001:.....
WAN IPv6 Gateway: fe80:.....
LAN IPv6 Address:
LAN IPv6 Link-Local Address: fe80:..... (different than WAN IPv6 gateway)
DHCP-PD: Enabled
LAN IPv6 Prefix: /64
DNS Address: 2001:558:feed::1,
2001:558:feed::2

Since I'm a comcast customer, I'm pretty sure I should be seeing a LAN IPv6 address start with 2601: if I remember correctly. I'm not sure why I'm not... does this mean prefix delegation isn't working?

I have an RT-AC66U running 374.43_44E5j9527. I installed with the firmware recovery tool to convert from Tomato and yes I did factory reset after installing the Merlin LTS fork.

My IPv6 settings are:

• Connection Type - Native
• DHCP-PD - Enable
• MTU - 1280
• LAN IPv6 Address - (blank)
• LAN Prefix Length - 64
• LAN IPv6 Prefix - (blank)
• Auto Configuration - Stateless
• Lifetime - 86400
• Connect to DNS Server automatically - Enable
• Advertise router as IPv6 DNS server - Yes
• Enable name resolution for fixed addresses - No
• Enable Router Advertisement - Enable
• Enable DHCPv6 Server - Enable
• Enable IPv6 MTU advertisement - Yes
• Release addresses on exit - Yes
• Prefix delegation requires address request - No

I can SSH into the router and successfully run ping/ping6 ipv6.google.com. Log files look clean (no obvious errors).

I'm comfortable running/editing/gathering any information needed, let me know what is helpful. Thank you for your time.

 

[octopus]

Next update, 44EA, posted. This release addresses fixes for user reported issues, some component updates, and one new feature.

Newly added is support for UPNP to obtain the external WAN address via STUN. This may help in some CGNAT environments.
Also of note is updated timezone support, including updated regions and the default DST/TDT start/stop times for each region. Please check your timezone settings after the update, as it may have changed based on the new timezone data.

Please review the first post for the other updates/fixes.

Enjoy!

SHA256

(Default Build - All supported routers)
622fceac1124060146b7e024747132eb26a3b8a77106a94f8734d78bf18f50af  RT-N16_374.43_44EAj9527.trx
2812787eead4ada7ba8abd75c5c48bdb412eb8833cd6af0d977eb5461c3c12df  RT-AC66U_374.43_44EAj9527.trx
8e363513f3a064d50339379093145358894effff311c38a311acb6b6e01a343b  RT-N66U_374.43_44EAj9527.trx
cfd4b929095a28d6eb26752af153ba8a6fdfc916b3448b6d9e8d80ce6973cd85  RT-AC68U_374.43_44EAj9527.trx
9bfddde75c53bac4b2909c904a1ed0ffd74f53d58abd99e7240f3fc311531d55  RT-AC56U_374.43_44EAj9527.trx

@john9527 @ColinTaylor
Thanks! It's working now....................

 

[john9527]

Since I'm a comcast customer, I'm pretty sure I should be seeing a LAN IPv6 address start with 2601: if I remember correctly. I'm not sure why I'm not... does this mean prefix delegation isn't working?

I know I've had Comcast customers using my fork so it should work. Maybe one of them could jump in if they had to do something special.

I don't see anything wrong with your setup, so in the meantime....
The firmware change may somehow may be causing Comcast to see this as a new device. So first thing to try is powering down your modem for about 15-30min to get it to reset the connection at the head end.
Second, some ISPs are very slow to release IPv6 addresses with a change in config if it hadn't been released properly. So, next thing is just to try again in 8-24 hours (yes, it can take that long).
Lastly, would be to upload your full syslog following a reboot to a file sharing site for me to review (PM the link if you are concerned about privacy).

 

[john9527]

Thanks! It's working now....................

Glad to hear it! (sorry it took longer than I expected to get it released...got caught in a little bit of 'scope creep' )

 

[L&LD]

I updated an RT-AC56U used in Bridge Mode to the latest v44EA version and it is working great!

Thank you @john9527 for another excellent release.

 

[dave14305]

I know I've had Comcast customers using my fork so it should work. Maybe one of them could jump in if they had to do something special.

I went back through my posts and the only anomaly I ever encountered with IPv6 on Comcast on the fork was an issue testing a dev build and ending up with multiple udhcpc processes. It wasn’t permanent. Other than that, I don’t recall any other issues when I was running the fork. This was after the radvd updates.

 

[luni]

I know I've had Comcast customers using my fork so it should work. Maybe one of them could jump in if they had to do something special.

I don't see anything wrong with your setup, so in the meantime....
The firmware change may somehow may be causing Comcast to see this as a new device. So first thing to try is powering down your modem for about 15-30min to get it to reset the connection at the head end.
Second, some ISPs are very slow to release IPv6 addresses with a change in config if it hadn't been released properly. So, next thing is just to try again in 8-24 hours (yes, it can take that long).
Lastly, would be to upload your full syslog following a reboot to a file sharing site for me to review (PM the link if you are concerned about privacy).

Thanks John, appreciate the time. I'll run through the steps here, including the "just wait" . If no luck I'll prepare a log file for you. Am I correct that I should see the "LAN IPv6 Address" and "LAN IPv6 Prefix" filled in on the UI when things are working correctly?

I went back through my posts and the only anomaly I ever encountered with IPv6 on Comcast on the fork was an issue testing a dev build and ending up with multiple udhcpc processes. It wasn’t permanent. Other than that, I don’t recall any other issues when I was running the fork. This was after the radvd updates.

Thanks for the input. To help me in my googling/troubleshooting, would you mind ssh-ing to your router and running ifconfig? Should I be expecting to see a "2601:" global scope IPv6 address on the br0 interface? Right now I only see 192.168.1.1 and a fe80: link scoped address.

Thanks for your time!

 

[john9527]

Am I correct that I should see the "LAN IPv6 Address" and "LAN IPv6 Prefix" filled in on the UI when things are working correctly?

Yes....the IPV6 prefix should be 4 hextets, and the LAN IPv6 address should be that prefix with the EUI64 address of the router (address based on the router MAC)

You can also look at the System Log > IPv6 page....all the addresses at the top should be filled in....

Running ifconfig on the router....the LAN IPv6 address should show on interface br0

 

[jrmwvu04]

I know I've had Comcast customers using my fork so it should work. Maybe one of them could jump in if they had to do something special.

I don't use it because it was causing some wrinkles I didn't feel like ironing out, but I have enabled ipv6 in the past with no setup beyond flipping it to Native and it seemingly worked. Certainly much better than you are seeing, @luni

edit: on Comcast

 

[jrmwvu04]

@luni @john9527

Out of curiosity I decided to flip on ipv6 to see what would happen and it indeed does not work now. I don't have time to toy with it at the moment because of covid stuff and working from home, can't have any extended downtime. But I thought I'd throw that information out for the time being since what I just said a bit earlier is no longer the case. I'll look into it more when the weekend comes and I can tinker.

 

[john9527]

@luni @john9527

Out of curiosity I decided to flip on ipv6 to see what would happen and it indeed does not work now. I don't have time to toy with it at the moment because of covid stuff and working from home, can't have any extended downtime. But I thought I'd throw that information out for the time being since what I just said a bit earlier is no longer the case. I'll look into it more when the weekend comes and I can tinker.

Hmmm....the last change to ipv6 was the radvd update back in April....and @dave14305 tested after that change. I wonder if Comcast changed something on their end recently? Cox ipv6 is still working fine for me.

One quick thing to try is to set the 'Prefix delegation requires address request' option to Yes (last option on the ipv6 page)

 

[luni]

Hmmm....the last change to ipv6 was the radvd update back in April....and @dave14305 tested after that change. I wonder if Comcast changed something on their end recently? Cox ipv6 is still working fine for me.

One quick thing to try is to set the 'Prefix delegation requires address request' option to Yes (last option on the ipv6 page)

Tried all your ideas, came up empty. Thanks for the suggestions.

This might have some legs unless I've gotten myself way too far into the weeds...

First I stopped dhcp6c. Then I ran:
dhcp6c -c /etc/dhcp6c.conf -f -D -T LL eth0
...
Jul/16/2020 23:03:27: copyin_option: get DHCP option IA address, len 24
Jul/16/2020 23:03:27: copyin_option: IA_NA address: 2001:.......... pltime=251119 vltime=251119
Jul/16/2020 23:03:27: dhcp6_get_options: get DHCP option IA_PD, len 72
Jul/16/2020 23:03:27: IA_PD: ID=650136, T1=0, T2=0
Jul/16/2020 23:03:27: copyin_option: get DHCP option status code, len 56
Jul/16/2020 23:03:27: status code: no prefixes
Jul/16/2020 23:03:27: dhcp6_get_options: get DHCP option DNS, len 32

Does this mean Comcast just isn't giving me a prefix to begin with? That would explain why dhcp6c cannot pass the prefix to br0 and radvd cannot give my clients global ipv6 addresses (if this is even how it's supposed to work.....).


[edit] People online report that sometimes resetting the DUID helps (pfsense forums), can we just rm /var/dhcpc_duid and it gets regenerated? Or will it always be MAC address based... I guess I could factory reset my router and assign it a different mac address in the startup wizard?

 

[john9527]

@luni - It's easy to get into the weeds with ipv6.....it gives me a headache.

Two other guesses....
Try a different prefix length....60 or 56

ssh to the router and enter
nvram set ipv6_isp_opt=4
nvram commit

then reboot....

There are some other 'ipv6_isp_opt' settings' you could try....doc is in Merlin_Fork_Options.txt
That these options exist at all tells you how much of a mess ipv6 can be.....although things in general seem to have gotten better.

 

[jrmwvu04]

Hmmm....the last change to ipv6 was the radvd update back in April....and @dave14305 tested after that change. I wonder if Comcast changed something on their end recently? Cox ipv6 is still working fine for me.

One quick thing to try is to set the 'Prefix delegation requires address request' option to Yes (last option on the ipv6 page)

Well it has been quite a while since I last used it successfully, many many builds ago. I know it’s sorta crappy to say oh hey this doesn’t work and give no details, so sorry about that on my end. For what it’s worth Comcast’s implementation of ipv6 even when it worked was pretty wonky and is part of why I stopped using it. But I’ll try your recommendations over the weekend.

 

[Raul_77]

Hey Guys, anyone found a way to effectively forward DoH to another provider. ?
I have PiHole installed and to do some testing, I changed my PC DNS to be 9.9.9.9 then in my router (RT-N66U) changed the setting "Prevent Client auto DoH" to YES
Parental Control --> DNS Filtering , enabled it, and fwd all traffic to to my PiHole

To test it, I blocked Instagram in Pihole , in PC command line, pinged insta, no result, disabled my Pihole, ping again, got result, so I know its working, However, in Chrome, I can visit Instagram and all the ads show, which shows Chrome has found a way to bypass Pihole and is using PC DNS directly. Looks like Chrome is using DoH, is there anyway I can fix this? I am trying to block ALL devices on my network to use Pihole.

Thanks,

 

[ColinTaylor]

Hey Guys, anyone found a way to effectively forward DoH to another provider. ?

https://www.tenforums.com/tutorials/145372-how-enable-disable-dns-over-https-doh-google-chrome.html

https://www.chromium.org/developers/dns-over-https

 

[dave14305]

Hey Guys, anyone found a way to effectively forward DoH to another provider. ?
I have PiHole installed and to do some testing, I changed my PC DNS to be 9.9.9.9 then in my router (RT-N66U) changed the setting "Prevent Client auto DoH" to YES
Parental Control --> DNS Filtering , enabled it, and fwd all traffic to to my PiHole

To test it, I blocked Instagram in Pihole , in PC command line, pinged insta, no result, disabled my Pihole, ping again, got result, so I know its working, However, in Chrome, I can visit Instagram and all the ads show, which shows Chrome has found a way to bypass Pihole and is using PC DNS directly. Looks like Chrome is using DoH, is there anyway I can fix this? I am trying to block ALL devices on my network to use Pihole.

Thanks,

Prevent Client auto DoH was meant for Firefox browsers. Chrome takes a different approach of upgrading to DoH if it detects the OS DNS is using a DNS provider that also offers DoH. If you point the PC DNS to the router, does it still use DoH? I don’t use Chrome, so I can’t test this.

 

[Raul_77]

https://www.tenforums.com/tutorials/145372-how-enable-disable-dns-over-https-doh-google-chrome.html

https://www.chromium.org/developers/dns-over-https

Thanks, however I am looking to see if possible to do this at the router level as oppose to disabling it on Chrome. the main reason is, I am trying to prevent ANY device (some that I might not know) to use any DNS other than my PiHole.