> On 16. Apr 2022, at 00:05, tue...@freebsd.org wrote: > >> On 15. Apr 2022, at 23:39, Florian Smeets <f...@smeets.xyz> wrote: >> >> On 15.04.22 21:24, tue...@freebsd.org wrote: >>>> On 15. Apr 2022, at 20:20, Florian Smeets <f...@smeets.xyz> wrote: >>>> >>>> >>>> Hi, >>>> >>>> there seems to be an issue with local IPv6 TCP connections on main. I have >>>> been seeing this for a couple of months at least. pkg upgr on my webserver >>>> hosting the pkg repo is very slow, all other hosts can connect to the pkg >>>> repo just fine. So IPv6 connections from external hosts are not affected. >>>> >>>> I thought I must have misconfigured something, as my setup is a bit weird. >>>> Yesterday I noticed the same issue on a different host, turns out all my >>>> 14.0 hosts seem to be affected, cognet@ could also reproduce it on one of >>>> his systems. >>>> >>>> The service/software used does not seem to matter, I tried with port 22, >>>> 25, 80 and 443. >>>> >>>> ICMP and UDP don't seem to be affected. ping6 gets replies immediately. >>>> And UDP connections with nc -l -u / nc -u don't have any delay, sent data >>>> is received immediately. >>>> >>>> Testing local TCP connections show this: >>>> >>>> flo@rp64:~ $ ifconfig dwc0|grep 2003 >>>> inet6 2003:cf:df49:c97:4c59:ebff:fec1:463d prefixlen 64 autoconf >>>> flo@rp64:~ $ nc -v 2003:cf:df49:c97:4c59:ebff:fec1:463d 22 >>>> [3 second delay here] >>>> Connection to 2003:cf:df49:c97:4c59:ebff:fec1:463d 22 port [tcp/ssh] >>>> succeeded! >>>> SSH-2.0-OpenSSH_8.9 FreeBSD-20220413 >>>> >> >>>> >>>> I need help debugging this, I don't know how to analyze this further. I >>>> will start bisecting this, but I thought maybe someone has an idea. >>> Hi Florian, >>> I can reproduce this locally, will try to figure out what is going on. If >>> you can bisect it, it would be great. >> >> Found the culprit 1817be481b8703ae86730b151a6f49cc3022930f. And indeed >> toggling net.inet6.ip6.source_address_validation makes the issue go away on >> latest main. > Cool, thanks for providing the information. However, I don't understand why > results in dropping the first two SYN segments (this should not happen) > and why the third is accepted (they should all treated the same). The first two packets don't have the loopback interface as its rcv interface, so Gleb's check for IFF_LOOPBACK fails. The second retransmission of the SYN has the loopback interface as its rcv interface, so Gleb check passes. I also do not see the problem with ICMP6, UDP or SCTP over IPv6. Don't know what is special about TCP, maybe Gleb knows out of his head...
Best regards Michael > > Best regards > Michael >> >> Florian >> <OpenPGP_0xEF5BA4DCD5A9F3C0.asc> > >
