scale-network
scale-network copied to clipboard
connectivity issues over ipv6
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.
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
@owendelong FYI
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.
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.
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.
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.
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.
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 Per: http://test-ipv6.com/
Setting the MTU on the tunnel to 1480 seems to help (1 less error). But Im still seeing 1 remaining error:
clearing browser cache seems to have fixed the last issue.
But restarting the browser it looks like the Test for Dual Stack DNS and large packet
is timing out again: