tychosmoose

Nice. I’m aiming to go from bare metal to rootless podman managed via quadlets. Networking seems like the difficult part.

Definitely weird. WiFi connections are poor, but VPN connection over the same WiFi link is good.

That makes me think perhaps DNS like others have said, or it could be something with your local routing table trying to reach something that’s not reachable. I would probably check the routing table first for anything weird. Like, you might have a static route applied from DHCP, but it’s ignored by your phone OS.

Since you can reproduce it in the browser I would probably look next at browser dev tools (F12). Go to the network tab. Then reproduce the problem. Once the task properly finishes, hit pause and sort by duration. You can also right click the headers and add a Timings>Latency column. See if there’s anything interesting.

Like, are the slow steps hitting a new domain name? Is there a slow POST among faster GETs? Is a step repeating after a timeout?

If nothing’s obvious there I would be tempted to repeat but lower level with wireshark to get the whole network picture. Get a good capture of the problem with a general sense of the timing of the problem pauses (in seconds from the start of capture). Find them in the cap and see what’s what. Compare good vs bad if no clear trends present themselves.

In #1, are you connecting to the VPN from the PC or from the router?

Same here. I have 2 other Pi servers and they’ve got no SD card - one has a USB SSD and the other is NVMe on the Pi 5.

On this one I was only somewhat concerned about SD rot. It was more that on a read/write file system any bad shutdown has a small chance of corrupting something. I wanted it to be bulletproof since it’s got to come up to start the other gear when I’m far from home and unable to fsck and troubleshoot.

I use a 3B as a low-power NUT server and power orchestrator with my UPS and a managed PDU. It’s set up with a read-only file system to protect against corruption. It’s connected to the UPS for status so that if power goes down it can manage the power off timing for servers and network gear. I have a low power rack and a long runtime UPS to keep the core Internet access components up as long as possible.

If the UPS runtime ends the 3B gets a bad shutdown. But with the read only fs it’ll happily boot when power returns and then it brings up all the gear in a controlled way. This has saved me a couple of times already while traveling.

This flag seems to only disable ipv6 on the default Docker bridge network, not daemon-wide. At least per this discussion.

It’s in the dnsutils package.

Well crap. Do you have no ipv6 address now in ip addr?

Guess I gave Docker too much benefit of the doubt and assumed it should failover to v4 once v6 was disabled. Bad assumption on my part.

Could it be a DNS problem? If you dig registry-1.docker.io +short does it return an ipv4 or v6 address?

It looks like there have been sporadic reports of problems from people since last year.

Ok, so it’s probably using NetworkManager. I would try disabling it in /etc/NetworkManager/NetworkManager.conf by adding a block like:

[ipv6]
addr-gen-mode=stable-privacy
method=disabled

Then sudo systemctl restart NetworkManager. Can’t say for sure if this will work. I dislike using NetworkManager on my servers so I can’t test if this works. But hopefully the before/after of ip addr is different.

Although it looks like your ip addr output posted an hour or so ago doesn’t show any ipv6 addressing. Maybe the problem is solved now.

Different programs have different defaults.

But in your situation which would be more helpful - prevent this one docker command from using ipv6 (likely more difficult), or preventing all commands from using your broken ipv6 config (likely easier)?

I have no idea about the first. Maybe some people know this detail. But I’m sure that with a distro and version that you’re running, there are lots of people who could help with the second. Raspberry Pi 3B+ is the hardware. What software are you using?

Docker is a distraction in your problem description.

It’s like if you asked why the top gear in your car isn’t working and gave the model of car and engine type and gearbox. But it’s really that you’re stuck in slow traffic. Focus on the road name and destination to find a faster route.

For your problem, search for how to disable ipv6 for the Linux distribution and version that you have installed. You will find lots of guidance. Or share those details here for someone to help.

Or, better might be to see if there is a way to get ipv6 tunneling working on your connection. It may be possible even if the ISP is unhelpful.

Some routers advertise a routable link local.

openSUSE Tumbleweed is the rolling release, where you may have dependency decisions to make during regular updates. Updates must be done in the terminal.

The more beginner friendly version is openSUSE Leap. That has a longer release cycle, and you use the Discover interface (or yeast, or zypper in the terminal) to update.

Either is pretty friendly. Both have recent KDE.