dslreports logo
 
    All Forums Hot Topics Gallery
spc
uniqs
34

rolande
Certifiable
MVM,
join:2002-05-24
Dallas, TX
ARRIS BGW210-700
Cisco Meraki MR42

rolande to sushiglob

MVM,

to sushiglob

Re: UVERSE IPv6 Problems

said by sushiglob:

I have IPv6 OFF now on the NVG589. I've set 6rd within Tomato. I have an IPv6 connection, but now just like with Native...Facebook isn't loading and with the Xfinity IPV6 speedtest page, I can run a test, but it times out when it gets to IPv6. I do believe a full reset is in order.

No. It is likely it is one of the security settings on the 589 that is not allowing the tunnel to work. If I recall there are at least 1 or 2 settings on the 589 that have to be disabled in order for a 6rd tunnel behind the RG to work.

Personally, I'd recommend you just run the 6rd tunnel off of your 589 like I am doing and let your router just delegate a prefix using DHCP-PD from the 589.
sushiglob
join:2014-08-02

2 edits

sushiglob

Member

said by rolande:

said by sushiglob:

I have IPv6 OFF now on the NVG589. I've set 6rd within Tomato. I have an IPv6 connection, but now just like with Native...Facebook isn't loading and with the Xfinity IPV6 speedtest page, I can run a test, but it times out when it gets to IPv6. I do believe a full reset is in order.

No. It is likely it is one of the security settings on the 589 that is not allowing the tunnel to work. If I recall there are at least 1 or 2 settings on the 589 that have to be disabled in order for a 6rd tunnel behind the RG to work.

Personally, I'd recommend you just run the 6rd tunnel off of your 589 like I am doing and let your router just delegate a prefix using DHCP-PD from the 589.

Okay, well I'm off to the gym, but when I get back....I'm doing a full reset on everything and starting again from scratch.

I will go ahead and leave IPv6 ON for the NVG589 and run a DHCPv6 with Prefix Delegation from the RT-N66U Tomato router.

I will then go back to the NVG589 and figure out what settings are causing these issues.

Where abouts do you think these two mystery settings may be? I'm thinking Firewall -- Advanced section.

Thoughts?

Edit: found this thread: »forums.att.com/t5/Equipm ··· /3860323

Sounds similar to me.

Mr Fel
INTJ - The Architect
Premium Member
join:2008-03-17
Louisville, KY
Asus RT-N66

Mr Fel to rolande

Premium Member

to rolande
said by rolande:

It is likely it is one of the security settings on the 589 that is not allowing the tunnel to work. If I recall there are at least 1 or 2 settings on the 589 that have to be disabled in order for a 6rd tunnel behind the RG to work.

I have dug through multiple threads and haven't found any mention of what 589 settings were turned off, all listed chronologically. Included the Pace threads since there was a lot of cross posting about the 589. Hell, included just about every AT&T UVerse IPv6 thread since the 6rd tunnel breaking and fixing since then.

»new firmware 6.9.1.42-enh.tm he.net tunnel no longer works. Self Explanatory
»AT&T now blocking IPv6 tunnels Self Explanatory
»Att U-verse IPv6 More tunnel blocking bashing
»NVG589 & IPV6 Self Explanatory
»IPv6 tunnel still broken on ATT Uverse Self Explanatory
»AT&T blocking IPv6 tunnels -- update Self Explanatory
»Help with IPv6 setup Trying to setup the RT-N66U, same router as this thread, on Pace CPE before newer firmware re-enabled IPv6
»IPv6 and my current configuration discussion.... IPv6 via DHCP-PD via Arris 589 CPE
»3600HGV + Cisco-Linksys E4200 IPv6 assignment address problem IPv6 Tunneling still broke
»New Firmware:6.11.1.29-enh.tm Where IPv6 was brought back to Pace 3800/1 CPE.
»UVerse IPv6 On a Zywall Zywall behind a 589 via DHCP-PD
»Interesting note on IPv6 performance Closer look at varying results in speed with IPv6.
»Anybody get IPv6 with router cascaded under DMZPlus working? Thread covering the fact IPv6 does work through DMZ+ with Pace CPE
»UVERSE and IPv6 with a cascaded router OP's previous thread.
Then finally this thread.

For a breakdown of what happened it looks like AT&T disabled Protocol 41 and other parts of IPv6 due to security flaws. This completely disabled it on the Pace gear and left IPv6 on the 589 gimped for a while. Eventually DHCP-PD was, somewhat, enabled with IPv6 allowing the use of it on 3rd party routers again on the 589's. Problems with throughput had been noticed this far back (well before IPv6 was back on the Pace gear). Finally newer firmware brought back IPv6 to the Pace gear, took a while before everything was sorted out between using DMZ+ for IPv4 and DHCP-PD for v6 with a 3rd party router. I haven't noticed any complaints about speed variations coming from anyone using the Pace gear however, just the 589 from the looks of it. Even then it has varied greatly even there by just which OS was used in the testing, with newer versions of Linux running just fine on the 589 as far as speed goes while Mac's and PC's have struggled with this issue to date. Which brings us to now, still dealing with the same unresolved issue as far as speed goes. I'm not digging through all the regular threads to find where it was suggested to just turn off IPv6 since it was causing higher hang times for people trying to normally browse on IPv4.

Anyway, you all have finally piqued my interest enough that I'll pick up a 589 from the shop this morning (off today) and start working on redoing my setup later this morning. I have the same router as OP, different firmware though, V117 of Shibby's Tomato Build. I should probably update to V121 now that I'm thinking about it, only dealt with V117 since it fixed my vulnerability to heartbleed.

Anyway time for a quick nap, didn't realize it was this late in the morning already.
sushiglob
join:2014-08-02

4 edits

1 recommendation

sushiglob

Member

said by Mr Fel:

said by rolande:

It is likely it is one of the security settings on the 589 that is not allowing the tunnel to work. If I recall there are at least 1 or 2 settings on the 589 that have to be disabled in order for a 6rd tunnel behind the RG to work.

I have dug through multiple threads and haven't found any mention of what 589 settings were turned off, all listed chronologically. Included the Pace threads since there was a lot of cross posting about the 589. Hell, included just about every AT&T UVerse IPv6 thread since the 6rd tunnel breaking and fixing since then.

»new firmware 6.9.1.42-enh.tm he.net tunnel no longer works. Self Explanatory
»AT&T now blocking IPv6 tunnels Self Explanatory
»Att U-verse IPv6 More tunnel blocking bashing
»NVG589 & IPV6 Self Explanatory
»IPv6 tunnel still broken on ATT Uverse Self Explanatory
»AT&T blocking IPv6 tunnels -- update Self Explanatory
»Help with IPv6 setup Trying to setup the RT-N66U, same router as this thread, on Pace CPE before newer firmware re-enabled IPv6
»IPv6 and my current configuration discussion.... IPv6 via DHCP-PD via Arris 589 CPE
»3600HGV + Cisco-Linksys E4200 IPv6 assignment address problem IPv6 Tunneling still broke
»New Firmware:6.11.1.29-enh.tm Where IPv6 was brought back to Pace 3800/1 CPE.
»UVerse IPv6 On a Zywall Zywall behind a 589 via DHCP-PD
»Interesting note on IPv6 performance Closer look at varying results in speed with IPv6.
»Anybody get IPv6 with router cascaded under DMZPlus working? Thread covering the fact IPv6 does work through DMZ+ with Pace CPE
»UVERSE and IPv6 with a cascaded router OP's previous thread.
Then finally this thread.

For a breakdown of what happened it looks like AT&T disabled Protocol 41 and other parts of IPv6 due to security flaws. This completely disabled it on the Pace gear and left IPv6 on the 589 gimped for a while. Eventually DHCP-PD was, somewhat, enabled with IPv6 allowing the use of it on 3rd party routers again on the 589's. Problems with throughput had been noticed this far back (well before IPv6 was back on the Pace gear). Finally newer firmware brought back IPv6 to the Pace gear, took a while before everything was sorted out between using DMZ+ for IPv4 and DHCP-PD for v6 with a 3rd party router. I haven't noticed any complaints about speed variations coming from anyone using the Pace gear however, just the 589 from the looks of it. Even then it has varied greatly even there by just which OS was used in the testing, with newer versions of Linux running just fine on the 589 as far as speed goes while Mac's and PC's have struggled with this issue to date. Which brings us to now, still dealing with the same unresolved issue as far as speed goes. I'm not digging through all the regular threads to find where it was suggested to just turn off IPv6 since it was causing higher hang times for people trying to normally browse on IPv4.

Anyway, you all have finally piqued my interest enough that I'll pick up a 589 from the shop this morning (off today) and start working on redoing my setup later this morning. I have the same router as OP, different firmware though, V117 of Shibby's Tomato Build. I should probably update to V121 now that I'm thinking about it, only dealt with V117 since it fixed my vulnerability to heartbleed.

Anyway time for a quick nap, didn't realize it was this late in the morning already.

Cheers! Let's get into this.

Just a quick update. I've started from scratch and performed a full reset. Now, what is a bit odd is that IPv6 was turned off after the full default reset. I thought that was strange because a few days ago I did a full default reset and IPv6 was enabled...by default. Why that didn't happen this time is interesting.

I'm directly connected with Cat6 to the NVG859 with IPv6 enabled and I'm getting hangups still! Google Music for example timesout and pauses when playing. I hate to say it, but I'm thinking something is just not right on ATT's side of the IPv6 stuff. Google Music has been smooth for the last 4 songs though. So...maybe IPv6 slowly works itself out in some sense once a IPv6 connection is established. I might account for the inconsistency with pages loading. Then again, I'm just some average user with beginner's network experience...so I really don't know how any of this stuff really works.

So far, I have yet to put the NVG589 in passthrough mode.

For now though, I have enabled IPv6 and also disabled HPNA since I don't use any coax. Wireless is also disabled.

That's it so far.

My RT-n66U is set to DHCPv6 with Preflix Delegation with Accept RA from WAN checked off, but I believe that's default and you can't turn it off.

Again, I don't have the NVG589 in passthrough mode, but I don still have it hooked up to the RT-N66U's WAN port. I have Cat6 going it that me, so I'm switching between the NVG589 and RT-N66U.

When I plug the RT-N66U cable back in and run some IPv6 stuff, Facebook stalls...Google Music freezes constantly...and the Xfinity Speed Test site refuses to run the IPv6 test...it runs IPv4, but completely stops there.

So....Even without the NVG589 in passthrough mode, I'm still getting these issues.

EDIT: One last update before I sleep.

- I've put my NVG589 and followed the instructions here: »forums.att.com/t5/Featur ··· /3552057

- The only thing I did not do from that guide was go to "Advanced Settings" for the Firewall section of the NVG589 firmware. Everything is still on default there. Part of the experiment.

- My RT-N66U is getting the proper info from the NVG589 and I'm able to get online and stuff.

- Since this is about IPv6, this is what I observed. First off, I have kept IPv6 turned ON in the NVG589. Second, I have an IPv6 address and everything looks good when I view the info within my tomato firmware. Third, I loaded up Facebook. It loads and it's quick. Interesting. Then I went to here: »test-ipv6.com/ and tested to see if IPv6 was working. It says NO, it is not. Well, I have an IPv6 address coming into my RT-N66U...soooo.....what gives?

I did a Tracert in a command prompt to www.Facebook.com, I got two hops in then the rest timed out. It got to 12 timeouts before I killed it.

So, when I initially visited Facebook.com, it must have been using IPv4 to get there because it loaded quickly. However, I have an IPv6 address and the www.Facebook.com tracerout showed I was going through the IPv6 address. If that be the case, why does »test-ipv6.com/ say that IPv6 is not working?

And with that, sleep.

EDIT: Couldn't help myself. One more test. In my Tomato firmware, the three static DNS areas were empty. I just now added Google's IPv6 DNS. Saved. Released/renewed IP. Re-ran »test-ipv6.com/ and got all green 10/10.

Traceroute to Facebook completed this time via IPv6, but there was one * at the third hop. Noticed it goes from my 2602:306: address on hops 1 and 2, but on third hop...the one with the *...has an address of 2602:300: Weird or normal? Facebook won't load in browser...probably because of that third hop...??

Google Music is also pausing a lot now.

rolande
Certifiable
MVM,
join:2002-05-24
Dallas, TX
ARRIS BGW210-700
Cisco Meraki MR42

1 recommendation

rolande

MVM,

A traceroute timeout is benign and doesn't really mean much. The key is you were able to resolve a AAAA name and get a response from the remote host via IPv6. So the trick with Tomato was that you need to enter DNS servers for the router and your internal clients to use.

Just because your RT-N66U has an IPv6 address assigned does not mean that it is properly delegating the /64 prefix and performing auto-addressing on the internal segment. The router is not going to do NAT66 behind that IPv6 address. So, unless the router assigns one of the /64 prefixes to the internal segment and you can see your internal client auto-addressing using that IPv6 prefix, you're out of luck.
rolande

1 recommendation

rolande to Mr Fel

MVM,

to Mr Fel
said by Mr Fel:

I have dug through multiple threads and haven't found any mention of what 589 settings were turned off, all listed chronologically.

Yeah, I went digging for it last night to and couldn't find it either. I need to remember to use the site mark feature so I don't lose this stuff in the shuffle.

From what I recall, if you want to disable IPv6 on the RG and run your own tunnel from your router, you need to disable a couple of the features in the Advanced Firewall settings section. I believe it is the last 2 settings: Reflexive ACL and ESP ALG.




The Reflexive ACL feature should only be used when IPv6 is enabled on the RG itself. Otherwise, I believe it will mangle the tunnel packets trying to pass through. The ESP ALG feature has to do with how IPv6 tunneled traffic is managed for encrypted sessions. Though it is likely no one is really doing anything actively with that implementation yet, this feature I believe also mangles tunneled IPv6 traffic like the Reflexive ACL.

The other potential issue might be with the Event Notifications feature under Diagnostics. You may want to disable both of the checkbox options on that page to prevent the RG from trying to intercept and redirect traffic accidentally.

Mr Fel
INTJ - The Architect
Premium Member
join:2008-03-17
Louisville, KY

1 recommendation

Mr Fel

Premium Member

Good to know, my nap ran longer than expected lol, but I'm still going to start this project today.
Mr Fel

1 recommendation

Mr Fel

Premium Member

Well this has just turned into a fine mess. Converted over to the 589, set IP Passthrough back up and enabled DHCP-PD. I go to »test-ipv6.com/ and I get 10/10 on testing, try one of the alternate location sites and get 1/10, failing on my MTU. However now I'm capped at 1Mb on my upload out to the internet and most websites hang unless I disable IPv6, load the site on IPv4, and then re-enable IPv6 (IPv6 settings on the testing computer that is). The Comcast Speedtest site hangs as soon as it starts the IPv6 portion of the test.

I suspect the 1Mb upload cap is a separate issue caused from when I had my profile upgraded to 32/5 and starting getting 4.7M on my upload on the 12M Package. Which is the one the major reasons I've been reluctant to swap my rg until now. Probably have to get my speed reprovisioned to get that fixed.

I'm going to have to continue testing this later, a lot of other things I need to get done today.
sushiglob
join:2014-08-02

1 edit

1 recommendation

sushiglob to rolande

Member

to rolande
said by rolande:

The other potential issue might be with the Event Notifications feature under Diagnostics. You may want to disable both of the checkbox options on that page to prevent the RG from trying to intercept and redirect traffic accidentally.

I cannot turn off "Missing Filter Notification" under Event Notifications. Seems it's on be default no matter what I do.

I'll continue testing, but the most I read and the more I try to get these bumps worked out, I can't help but feel it's nothing on my end.

EDIT: well, I've decided to throw in the towel. I'll just keep IPv6 disabled for now. There's just too many issues...way too man inconsistencies. I find it completely unstable. If the service was ready to go, I don't think it would be this difficult to get it to play nicely. Until ATT fixes it, I'll be off IPv6.

Thanks for the replies and such. If someone ever runs into issues with IPv6 and UVERSE service, they'll have this thread to poke through.

Mr Fel
INTJ - The Architect
Premium Member
join:2008-03-17
Louisville, KY
Asus RT-N66

1 recommendation

Mr Fel

Premium Member

Well I've fixed my upload speed issue, just needed to be reprovisioned exactly like I though.

Alright, I've narrowed it down to just the N66U (that or a mismatched setting with 589 when used in combination). With DHCP-PD enabled I experience times out any new site that I haven't visited previously. This is with test-ipv6.com now coming up 10/10 on it and the alternate testing sites that have noted full support for IPv6. Then the IPv6 portion of the Comcast speedtests is completely skipped. I've tried a prefix length of both 64 (default) and 32, same result both ways.



Running my PC directly off the 589, no timeouts, and testing perfectly on the Comcast Speedtest. Speed varied a bit, but I have netflix on in the background causing that. Test run on Windows 7 on Waterfox (64bit Firefox) over a patch cable directly to the RG. So default IPv6 out of the 589 appears to be working exactly as intended.

Anyone else running an N66U that has gotten it running without timing out with DHCP-PD enabled? Really hoping to avoid multiple firmware flashes testing out different builds.

Edit: Having an attached image is causing odd behavior out of my linked speedtest image.
sushiglob
join:2014-08-02

1 recommendation

sushiglob

Member

said by Mr Fel:

Well I've fixed my upload speed issue, just needed to be reprovisioned exactly like I though.

Alright, I've narrowed it down to just the N66U (that or a mismatched setting with 589 when used in combination). With DHCP-PD enabled I experience times out any new site that I haven't visited previously. This is with test-ipv6.com now coming up 10/10 on it and the alternate testing sites that have noted full support for IPv6. Then the IPv6 portion of the Comcast speedtests is completely skipped. I've tried a prefix length of both 64 (default) and 32, same result both ways.

Running my PC directly off the 589, no timeouts, and testing perfectly on the Comcast Speedtest. Speed varied a bit, but I have netflix on in the background causing that. Test run on Windows 7 on Waterfox (64bit Firefox) over a patch cable directly to the RG. So default IPv6 out of the 589 appears to be working exactly as intended.

Anyone else running an N66U that has gotten it running without timing out with DHCP-PD enabled? Really hoping to avoid multiple firmware flashes testing out different builds.

Edit: Having an attached image is causing odd behavior out of my linked speedtest image.

So, just like me, IPv6 works fine when directly connected to it with your computer, yes? That is exactly what I experience as well.

Once I have my RT-N66U do Tunnel 6rd or DHCPv6 with Prefix Delegation, I get timeouts.

Appears the only way right now to use IPv6, is to directly connect yourself to the NVG589. The minute you put a router behind it and have it do the IPv6 stuff, you're looking at timeouts.

Mr Fel
INTJ - The Architect
Premium Member
join:2008-03-17
Louisville, KY

1 recommendation

Mr Fel

Premium Member

Exactly, I'm going to flash it back to stock firmware and see how that holds up when I have more time. I can say for now Shibbly's Tomato build won't cut it with IPv6 via DHCP-PD.
sushiglob
join:2014-08-02

1 recommendation

sushiglob

Member

said by Mr Fel:

Exactly, I'm going to flash it back to stock firmware and see how that holds up when I have more time. I can say for now Shibbly's Tomato build won't cut it with IPv6 via DHCP-PD.

Make that Shibby's Tomato and the Merlin builds. They both have IPv6 issues thus far.

Since Merlin builds are based off of official Asus drivers, I highly doubt there'd be a difference with the stock firmware.

I came across this Wiki article regarding "IPv6 Brokenness." What it describes sound exactly like what we are experiencing.
»en.wikipedia.org/wiki/IP ··· elisting

It's an old article, but at this moment...I have no one else to blame except ATT. Just doing a general search on this whole thing shows many people simply turning off IPv6 on their UVERSE service to "fix" issues.

Mr Fel
INTJ - The Architect
Premium Member
join:2008-03-17
Louisville, KY
Asus RT-N66

1 recommendation

Mr Fel

Premium Member

I'm leaning more toward ASUS considering there is no "Brokenness" directly from the rg, nor is there any brokenness for others who use other routers like rolande See Profile on a Cisco 3825 or TestBoy See Profile on a Zywall for example. Those are more heavy duty in nature than our consumer grade gear, which is clearly not overly concerned with IPv6 yet either.
sushiglob
join:2014-08-02

1 recommendation

sushiglob

Member

said by Mr Fel:

I'm leaning more toward ASUS considering there is no "Brokenness" directly from the rg.

True-true. Good point.

hhhhmmmmm.........

Perhaps the RT-N66U hardware just sucks? Maybe it can't handle it? I'm reaching here, but I have nowhere else to look.

ILpt4U
Premium Member
join:2006-11-12
Saint Louis, MO

1 recommendation

ILpt4U

Premium Member

I still really haven't had an issue with IPv6. Is there any website I should try to see if it "breaks"?
sushiglob
join:2014-08-02

1 recommendation

sushiglob

Member

Facebook.com, Xfinity's IPv6 speed test site, a few other random ones that specifically dealt with IPv6.

What's your setup and settings? I can cross check them with mine.

Mr Fel
INTJ - The Architect
Premium Member
join:2008-03-17
Louisville, KY

1 recommendation

Mr Fel to ILpt4U

Premium Member

to ILpt4U
For me it breaks with ANY IPv4 webpage I haven't visited previously on my browser. Turn off IPv6, visit the site, turn on IPv6 again and site starts working with IPv6 still on. Even then with IPv6 websites it's hit and miss beyond the test-ipv6.com

ILpt4U
Premium Member
join:2006-11-12
Saint Louis, MO
ARRIS TM822
Asus RT-N66

1 recommendation

ILpt4U to sushiglob

Premium Member

to sushiglob
facebook's home page launches, but i don't have a facebook (well, thats not technically true, but its been inactive for almost 8 years now)

Comcast's IPv6 test works. I never get a good test, IPv4 or v6 unless I hardwire in (too much WiFi pollution; my laptop only has WiFi 2.4 Ghz)

On the NVG589:
IP Passthru:
Allocation mode: Passthrough
Default Server Internal Address: Blank
Passthrough mode: DHCPS-Fixed
Passthrough fixed Mac Address: Mac of WAN port of the Asus

On the Asus RT-N66U (running the latest Stock Asus firmware, 3.0.0.4.376_1071)

WAN:
Basic Config:
WAN Connection type: Static IP
Enable WAN: yes
Enable NAT: yes
Enable UPnP: yes
WAN IP Setting:
IP Address: *Public IP from AT&T via NVG589*
Subnet Mask: 255.255.252.0
Default Gateway: *Public IP Gateway from AT&T via NVG589*
WAN DNS:
DNS Server 1: 99.99.99.53
DNS Server 2: 99.99.99.153

IPv6:
Basic Settings:
Connection type: Native
DHCP-PD: Enable
IPv6 LAN Setting: (populates on own)
Auto Configuration: Stateless
IPv6 DNS Setting:
Connect to DNS Server Automatically: Enable
Auto Configuration Setting:
Enable Router Configuration: Enable
sushiglob
join:2014-08-02

sushiglob

Member

said by ILpt4U:

facebook's home page launches, but i don't have a facebook (well, thats not technically true, but its been inactive for almost 8 years now)

Comcast's IPv6 test works. I never get a good test, IPv4 or v6 unless I hardwire in (too much WiFi pollution; my laptop only has WiFi 2.4 Ghz)

On the NVG589:
IP Passthru:
Allocation mode: Passthrough
Default Server Internal Address: Blank
Passthrough mode: DHCPS-Fixed
Passthrough fixed Mac Address: Mac of WAN port of the Asus

On the Asus RT-N66U (running the latest Stock Asus firmware, 3.0.0.4.376_1071)

WAN:
Basic Config:
WAN Connection type: Static IP
Enable WAN: yes
Enable NAT: yes
Enable UPnP: yes
WAN IP Setting:
IP Address: *Public IP from AT&T via NVG589*
Subnet Mask: 255.255.252.0
Default Gateway: *Public IP Gateway from AT&T via NVG589*
WAN DNS:
DNS Server 1: 99.99.99.53
DNS Server 2: 99.99.99.153

IPv6:
Basic Settings:
Connection type: Native
DHCP-PD: Enable
IPv6 LAN Setting: (populates on own)
Auto Configuration: Stateless
IPv6 DNS Setting:
Connect to DNS Server Automatically: Enable
Auto Configuration Setting:
Enable Router Configuration: Enable

Hrm...doesn't seem all that different from my configuration.

Mr Fel
INTJ - The Architect
Premium Member
join:2008-03-17
Louisville, KY
Asus RT-N66

1 recommendation

Mr Fel to ILpt4U

Premium Member

to ILpt4U
After reading through a slightly old article »community.plus.net/forum ··· 21352.16 it's like I suspected, it's probably the choice of firmware. Oh well, looks like you made the right choice sticking with stock firmware in this case. I'll give it a whirl tomorrow.

ILpt4U
Premium Member
join:2006-11-12
Saint Louis, MO

1 recommendation

ILpt4U

Premium Member

Well, interesting, the Comcast IPv6 speedtest starts to crap out @ about 90% complete, after running hot up to that point. Never noticed that before
sushiglob
join:2014-08-02

sushiglob

Member

said by ILpt4U:

Well, interesting, the Comcast IPv6 speedtest starts to crap out @ about 90% complete, after running hot up to that point. Never noticed that before

Haha, what can I say? Welcome to the club.

ILpt4U
Premium Member
join:2006-11-12
Saint Louis, MO

ILpt4U

Premium Member

Its up to 98% now! Its still clocking it at ~45 Mbps, even though the progress bar is barely moving...weird
sushiglob
join:2014-08-02

4 edits

2 recommendations

sushiglob to Mr Fel

Member

to Mr Fel
said by Mr Fel:

After reading through a slightly old article »community.plus.net/forum ··· 21352.16 it's like I suspected, it's probably the choice of firmware. Oh well, looks like you made the right choice sticking with stock firmware in this case. I'll give it a whirl tomorrow.

Very interesting. I wonder what's up with the Tomato builds. They must have some kind of bug in them as well.

I might try this Merlin build: 3.0.0.4_374.35_4

EDIT: Okay, I'm going to flash this and test. Perhaps it is indeed just a bug and if we can find out if that build works, then maybe Merlin can adjust future builds. Let's see how this goes down.

EDIT: Big update.
I flashed Merlin's 3.0.0.4_374.35_4 build and low and behold, IPv6 is working. Facebook loads, all the IPv6 test sites work, Xfinity actually completes a full benchmark and speeds are close to IPv4 testing.

Whatever is in 3.0.0.4_374.35_4, it seems to fix IPv6 issues.

I'm set to Native in my RT-N66U and my NVG589 is in passthrough mode, IPv6 enabled, and everything is still set to ON under Firewall Advanced per defaults.

I didn't really have to do much. Just set "Native" mode on my RT-N66U...and bam. It works.

I will continue to monitor and browse around. I'll report tomorrow on how things are holding up. It would be interesting if something degrades overnight. Stay tuned...

EDIT: Another observation. After running a few speed tests over at Xfinity, I noticed that IPv6 speed began to decrease. At first it was as fast as my IPv4 connection. Then it slowed back down to about 15Mbps.

Only thing I can think of to fix that would be to kill some advanced firewall stuff on my NVG589. The last time I ran into speed issues, turning everything to OFF in Advanced under Firewall did the trick.

EDIT: Speed is back up to what it should be on IPv6. Not sure what was up, perhaps it was a server side issue or something. Or maybe there's some kind of throttle on IPv6? Too many tests in a row causes it to throttle? No idea.

rolande
Certifiable
MVM,
join:2002-05-24
Dallas, TX
ARRIS BGW210-700
Cisco Meraki MR42

1 recommendation

rolande

MVM,

said by sushiglob:

I flashed Merlin's 3.0.0.4_374.35_4 build and low and behold, IPv6 is working.

Barring any config issue, I was leaning to a firmware issue on your router. I've had mine working perfectly for quite some time now, even with the old NVG589 firmware.
sushiglob
join:2014-08-02

sushiglob

Member

said by rolande:

said by sushiglob:

I flashed Merlin's 3.0.0.4_374.35_4 build and low and behold, IPv6 is working.

Barring any config issue, I was leaning to a firmware issue on your router. I've had mine working perfectly for quite some time now, even with the old NVG589 firmware.

Well, it's both good news and bad. I wonder if I can get Merlin to look into this issue.

j1349705
Premium Member
join:2006-04-15
Holly Springs, NC

1 edit

1 recommendation

j1349705 to rolande

Premium Member

to rolande
said by rolande:

said by sushiglob:

I flashed Merlin's 3.0.0.4_374.35_4 build and low and behold, IPv6 is working.

Barring any config issue, I was leaning to a firmware issue on your router. I've had mine working perfectly for quite some time now, even with the old NVG589 firmware.

It seems to be a Path MTU discovery issue.

The router advertisements from my ASUS RT-AC66U (stock firmware 3.0.0.4.376_1123) seem to lack the MTU option. I haven't been able to determine why yet.

The router advertisements from the NVG589 set the MTU to 1472.

If I manually set my connection's MTU to 1472, everything works perfectly behind the ASUS router... all IPv6 sites including the Comcast speed test work perfectly. Here's the Windows way through the command prompt since that is what I was using to test (don't feel like disturbing my main Linux box at the moment):
netsh interface ipv6 set subinterface "Wireless Network Connection" mtu=1472

Don't forget to use the proper connection name in the above command if you give it a try.

Have to step away from this again to take care of more important tasks but I hope to be able to look into it more soon. For those using different routers, I'm curious to hear whether your router advertisements set the MTU to 1472.
j1349705

1 edit

1 recommendation

j1349705

Premium Member

Update... I can also reproduce these issues with my pfSense box. The "fix" is the same as for the ASUS router. Lowering the MTU to 1472 seems to fix the issue based on limited testing, or at the very least I can say it greatly improves reliability.

All firewall related features on the NVG589 are disabled.

Still not sure yet why this problem suddenly started happening after working reliably for a few weeks.