FreeBSD "pkg upgrade" problem over IPv6



Reaction score: 12
Messages: 78

I do not know if this the correct place to post this. Maybe the moderator can move it if it is in the wrong place.

I have over the last weeks started to see problems from one of my FreeBSD 12.2 server hosted at RamNode on their European location. When doing a "pkg upgrade” the terminal often hangs. Doing “pkg -4 upgrade” and it works well. This is something I have seen over the last weeks and not before that.

Looking into it I can se that (2604:1380:2000:9501::50:2) is contacted on port 80. A netstat shows a “SYN_SENT” and no more.

And trying to contact it gives….
19:17:35 huey:~ # telnet -6 2604:1380:2000:9501::50:2 80
Trying 2604:1380:2000:9501::50:2...
telnet: connect to address 2604:1380:2000:9501::50:2: Operation timed out
telnet: Unable to connect to remote host

Sometimes it works though, but not always. Intermittent problem it is… My IPv6 /64 is within the network operator RouteLabel V.O.F.

My server have no problems whatsoever with IPv6 apart from this. Therefor I can conclude that it is either a routing/network issue between my node and the FreeBSD upgrade server, or maybe a problem in or near the FreeBSD update server. Before posting this, I logged a case at the VPS hosting provider RamNode asking them if they had any ongoing known problems. They have checked.. All green. And as I have no IPv6 problems against anything else, I think they are correct...

Have anyone seen anything similar when doing "pkg upgrade" lately?




Reaction score: 12
Messages: 41

I experienced this in 2018 and although I fixed it, I never found a specific root cause. I was short on time and forced to make too many changes at once. However, I suspect that my problem was a combination of Squid proxy, a mix of declared and transparent proxies, DNS, passive FTP, firewall rules (ICMP) and environment variables. My production environment is mostly built using Ansible and I wrote a lot of playbooks to get 'all my ducks in a row'.

I started my troubleshooting by building an IPv6 only network segment and development workstation. My problems started immediately and I had to dip into IPv4 now and then just to download and install packages to get basic network services operational on IPv6. Once I had single IPv6 only segment running properly with IPv6 DNS and DHCP6 I installed a local IPv6 webhost on the segment for testing and then reintroduced proxying.

Finding all of the proxy related environment variables for tools and application configs can take a while in a mixed OS environment. I now have all of my environment variables configured from Ansible. Some have to be set twice, once with an uppercase variable name and again with a lowercase. E.g. HTTP_PROXY and http_proxy. These need to be fixed in every level of config for all of the shells installed. Configs for tools like wget and fetch need to be pinned down, particularly those that look for a config file in multiple locations and have an override hierarchy.

Once I had IPv6 only running I reintroduced IPv4 on my development network. My Ansible playbook changes were rolled into production use and I have not had any problem since with FreeBSD updates. I think dual stack IPv4/v6 can mask a lot of config problems where tools can fall back to IPv4. I was surprised how hard it was to setup up an IPv6 only network from scratch with single stack IPv6 servers and workstations compared to doing the same with IPv4.


Son of Beastie

Reaction score: 1,991
Messages: 3,997

The people at RamNode are easy to talk to and accessible on irc. You might want to check with them or file a report. Recently, I had a problem they found with their containerization and it was resolved quickly.