IPv6 processing causes 2 minute delay

English Network/Internet
1

ID=“opensuse-slowroll”
VERSION_ID=“20260901”
7.2.5-1-default x86_64
r8169
amd athlon x4 640
network manager (nmcli tool, version 1.56.1)

I migrated from LEAP 15.6 to slowroll. Since then IPv6 has been spotty. For instance, it refuses to accept a DHCP6-provided IPv6. (I finally configured a manual IP for that.)

Connecting to/from the host with ssh now has a 2 minute delay added to the process. I thought at first it was an ssh issue. Not so! If I add the -4 option to ssh, the connection proceeds normally.

If the remote host (slowroll) has port 2222 open, and does not have sshd running on it, the delay occurs anyway. That is, the delay is unrelated to the service, only to IPv6.

I used Wireshark to capture the connection sequence for a non-connected port 2222. Wireshark shows a listing of packets like the two below. They are repeated about 10 times before the connection is broken after 2min 20 sec.

167     2026-10-06 21:51:09.784Z        fd2f:4760:521f:3f3c::c0a8:4573  fd2f:4760:521f:3f3c::c0a8:456d  TCP     94      [TCP Port numbers reused] 51872 → 2222 [SYN] Seq=0 Win=64800 Len=0 MSS=1440 SACK_PERM TSval=4149987781 TSecr=0 WS=1024
168     2026-10-06 21:51:09.784Z        fd2f:4760:521f:3f3c::c0a8:456d  fd2f:4760:521f:3f3c::c0a8:4573  TCP     74      2222 → 51872 [RST, ACK] Seq=1 Ack=1 Win=0 Len=0

I expect there is a configuration issue with IPv6. I have no idea how to find it.

Any suggestions?

Here is a nmcli output:

$ nmcli
eth0: connected to eth0
        "Realtek RTL8111/8168/8211/8411"
        ethernet (r8169), 00:24:8C:88:9D:F3, hw, mtu 1500
        ip4 default, ip6 default
        inet4 192.168.69.109/24
        route4 192.168.69.0/24 metric 100
        route4 default via 192.168.69.1 metric 100
        inet6 fe80::acc0:6d1f:d200:ca7e/64
        inet6 fd2f:4760:521f:3f3c::c0a8:456d/128
        route6 fd2f:4760:521f:3f3c::c0a8:456d/128 metric 100
        route6 fd2f:4760:521f:3f3c::c0a8:4501/128 metric 20100
        route6 default via fd2f:4760:521f:3f3c::c0a8:4501 metric 20100
        route6 fe80::/64 metric 1024
2

This is related to mdns. Easiest is to zypper rm avahi.

Most people today want to retain some form of mdns if they expect to use local smart home appliances directly from PC.

In /etc/nsswitch.conf There is a mdns_minimal version thats worth trying over mdns if present. If none of these work and you don’t care for direct smart home appliance connections you can remove mdns* from /etc/nsswitch.conf.

3

Removing avahi made no difference in the delay.

4

Missed your IPv6 doesn’t connect at all above.

You should generally only use DHCPv6 on router for getting global IPv6 prefix which starts with 2000::/3 . It should be distributed to clients via router advertisement (RA) which you can monitor with radvdump if u dont see any its not working.

Also its preferred to use the global address/prefix everywhere… the fc00::/7 adresses you have above is mostly default on openwrt, but quite unconventional for regular IPv6 setups, the idea is you route directly to the global addr internally, a local addr is not needed in IPv6 it already has the fe80 link-local addr which represent the other end of the cable meaning every reachable host on the other end…

5

It does connect if there is a service available. Otherwise the connection drops, as it should. It is that it takes over 2 minutes to get there even for a failed connection. Some sort of SYN/RST loop persists until it times out or reaches some other limit.

I do not see that the rest of your post is in any way helpful here.

6

But clearly there are issues, so some basic introduction to IPv6 is in place.

7

Yes.

Provide references that offer useful detail, and would apply to this particular issue.

8

Right… Thats what I did. Perhaps provide more info on your setup if you don’t think it applies?