scale-network icon indicating copy to clipboard operation
scale-network copied to clipboard

connectivity issues over ipv6

Open nixinator opened this issue 1 year ago • 11 comments

Description

Once you have authenticated your browser to gmail/google.com via ipv4, you can not then access the same google services via ipv6

Acceptance Criteria

What is the expected outcome that resolves this issue?

using a incognito window or reauthenticating over ipv6 is a potential work around.

this may cause the opposite shenanigan when you go back to ipv4, but this is unconfirmed.

nixinator avatar Mar 09 '23 16:03 nixinator

This seems to be more than just a google thing, or at least more than the google.com and gmail sites. I was unable to load https://forum.openwrt.org/t/rssi-threshold-for-joining/68753 from Pop_OS! until I disabled IPv6. I have IPv6 on my home network and have never had issues loading sites as a result, so I believe this is related to this network. Here is some information about my system:

╔ ☕️  carbonbean:~     
╚ᐅ iwconfig wlp0s20f3 
wlp0s20f3  IEEE 802.11  ESSID:"scale-public-fast"  
          Mode:Managed  Frequency:5.18 GHz  Access Point: 08:BD:43:C3:7E:BB   
          Bit Rate=130 Mb/s   Tx-Power=22 dBm   
          Retry short limit:7   RTS thr:off   Fragment thr:off
          Power Management:on
          Link Quality=60/70  Signal level=-50 dBm  
          Rx invalid nwid:0  Rx invalid crypt:0  Rx invalid frag:0
          Tx excessive retries:0  Invalid misc:3909   Missed beacon:0

╔ ☕️  carbonbean:~     
╚ᐅ lspci|grep -i network
00:14.3 Network controller: Intel Corporation Wi-Fi 6 AX201 (rev 20)

╔ ☕️  carbonbean:~     
╚ᐅ uname -a 
Linux carbonbean 6.2.0-76060200-generic #202302191831~1677858327~22.04~3cea1be SMP PREEMPT_DYNAMIC Fri M x86_64 x86_64 x86_64 GNU/Linux

╔ ☕️  carbonbean:~     
╚ᐅ cat /etc/os-release                                                                                        
NAME="Pop!_OS"
VERSION="22.04 LTS"
ID=pop
ID_LIKE="ubuntu debian"
PRETTY_NAME="Pop!_OS 22.04 LTS"
VERSION_ID="22.04"
HOME_URL="https://pop.system76.com"
SUPPORT_URL="https://support.system76.com"
BUG_REPORT_URL="https://github.com/pop-os/pop/issues"
PRIVACY_POLICY_URL="https://system76.com/privacy"
VERSION_CODENAME=jammy
UBUNTU_CODENAME=jammy
LOGO=distributor-logo-pop-os

genebean avatar Mar 09 '23 23:03 genebean

@owendelong FYI

sarcasticadmin avatar Mar 10 '23 00:03 sarcasticadmin

We using some tunnelling, I wonder if MTU or PMTU, or something to do with the GRE encapsulation sizes because we using a tunnel.

Maybe worth researching.

nixinator avatar Mar 10 '23 02:03 nixinator

Last I checked, we were generating proper ICMP packet too big messages for both v4 and v6.

Further, if it were a PMTU-D issue, it would probably affect virtually all large downloads over IPv6 at the conference and those don't seem to be an issue.

It would be really nice if someone actually experiencing the issue could put it in front of me in a way that I can do some actual troubleshooting while it is happening. Unfortunately, instead, we have clowns running around telling everyone to just disable IPv6.

owendelong avatar Mar 26 '23 05:03 owendelong

I don't have these problems with google at home, either, but I have IPv6 at home. The problem doesn't seem to occur if you authenticate via IPv6.

owendelong avatar Mar 26 '23 05:03 owendelong

I am a clown, that is telling people to disable ipv4.

Without the help of the google network gods, i think were a bit stuck on this.

I have every confidence that PMTU and all the ICMP stuff that you need has been correctly setup and configured.

I'm sure this is shenanigans at their end, but it might be impossible to prove one way or another.

nixinator avatar Mar 26 '23 19:03 nixinator

I did run across some people having the google problem, and telling them to logout and login again did seem to work.

David Lang

On Sun, 26 Mar 2023, Lee Hughes wrote:

I am a clown, that is telling people to disable ipv4.

Without the help of the google network gods, i think were a bit stuck on this.

I have every confidence that PMTU and all the ICMP stuff that you need has been correctly setup and configured.

I'm sure this is shenanigans at their end, but it might be impossible to prove one way or another.

davidelang avatar Mar 26 '23 20:03 davidelang

I'm not sure what we can do about this during the year. I'd like to encourage ANYONE who encounters this during the show to immediately try to get me involved in working with the affected party to troubleshoot it while it is happening.

owendelong avatar Sep 13 '23 05:09 owendelong

@owendelong Per: http://test-ipv6.com/

ss-202403121710222614 ss-202403121710220181

sarcasticadmin avatar Mar 12 '24 16:03 sarcasticadmin

Setting the MTU on the tunnel to 1480 seems to help (1 less error). But Im still seeing 1 remaining error:

ss-202403121710261161 ss-202403121710261154

sarcasticadmin avatar Mar 12 '24 16:03 sarcasticadmin

clearing browser cache seems to have fixed the last issue. ss-202403121710261341

But restarting the browser it looks like the Test for Dual Stack DNS and large packet is timing out again:

ss-202403121710261585

sarcasticadmin avatar Mar 12 '24 16:03 sarcasticadmin