Tumbleweed 20211223
Just updated to day.
Now all SSh, NFS and Qt apps have a 3 minute delay before connection is established. There is no information available in the system journal; it show a connection start, and 3 minutes later: success. After the long delay, all operations proceed normally.
The 3 minute is a rough guess; it could be 150 seconds, or something close.
Any ideas what this is about? Before I submit a defect report?
I would try an ssh to the IP address (of a destination that has a 3 minute delay) to see if the problem has anything to do with name resolution. I might also use wireshark or similar to see what traffic is being exchanged. Checking routes might be worth a shot (ip route command). But I’m guessing you may have done all this already.
Found the problem.
It is the DHCP6 server in our firewall. We have been having issues with it issuing reply codes the DHCP6 client did not recognize. Firewall tech support offered a knowledge base solution that works ONLY for tumbleweed, caused the timeout delay, and did nothing for LEAP or other hosts.
I found which setting caused the delay and reset it to its useful value. While we still have DHCP6 issues, at least the timeout problem is fixed.
Is it classified information? Did not it occur to you to describe settings to help others?
Very well …
The firewall is a Sonicwall tz-350. Among its available services is DHCP for IPv6. Its os, SonicOS Enhanced 6.5.4.9-92n, is a recent update and proceeded to fail to deliver IPv6 addresses. Their tech support referred me to a configuration article for DHCP6 in their knowledge base. I diligently followed the steps. And ended with the 3 minute timeout for some network apps and services.
The particular setting that resolved the timeout was (re-)enabling “Advertise Subnet Prefix of IPv6 Primary Static Address.”