From nobody Fri Nov 19 17:54:18 2021
X-Original-To: freebsd-net@mlmmj.nyi.freebsd.org
Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1])
	by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id B445A189ACD0
	for <freebsd-net@mlmmj.nyi.freebsd.org>; Fri, 19 Nov 2021 17:54:29 +0000 (UTC)
	(envelope-from pi@freebsd.org)
Received: from fc.opsec.eu (fc.opsec.eu [IPv6:2001:14f8:200:4::4])
	(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
	 key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256)
	(Client did not present a certificate)
	by mx1.freebsd.org (Postfix) with ESMTPS id 4Hwknd1V07z3FPv;
	Fri, 19 Nov 2021 17:54:29 +0000 (UTC)
	(envelope-from pi@freebsd.org)
Received: from pi by fc.opsec.eu with local (Exim 4.95 (FreeBSD))
	(envelope-from <pi@freebsd.org>)
	id 1mo85a-000Q0h-Iz;
	Fri, 19 Nov 2021 18:54:18 +0100
Date: Fri, 19 Nov 2021 18:54:18 +0100
From: Kurt Jaeger <pi@freebsd.org>
To: "Andrey V. Elsukov" <bu7cher@yandex.ru>
Cc: tuexen@freebsd.org, freebsd-net@freebsd.org
Subject: Workaround: Re: dtrace to trace incoming connection not suceeding ?
Message-ID: <YZfkyisWEabI1/Vj@fc.opsec.eu>
References: <YY5nhomjYRnRojwa-v2@fc.opsec.eu>
 <866D4765-25EF-4C5F-AA2E-D6BE8D5EBEEB@freebsd.org>
 <YY6C2/OyG3KTvV+M@fc.opsec.eu>
 <43FC040E-E5DE-4F4E-B91E-AAA807207D05@freebsd.org>
 <YY6ITiq+8x5nw5a/@fc.opsec.eu>
 <36CCF1D0-34EE-4E1C-B593-71CF936F4DE7@freebsd.org>
 <YY6k1JzP4EbKCF7m@fc.opsec.eu>
 <eec5880e-3164-f0a2-3748-687098de3026@yandex.ru>
 <YZFKPIEROC1cwcOQ@fc.opsec.eu>
List-Id: Networking and TCP/IP with FreeBSD <freebsd-net.freebsd.org>
List-Archive: https://lists.freebsd.org/archives/freebsd-net
List-Help: <mailto:freebsd-net+help@freebsd.org>
List-Post: <mailto:freebsd-net@freebsd.org>
List-Subscribe: <mailto:freebsd-net+subscribe@freebsd.org>
List-Unsubscribe: <mailto:freebsd-net+unsubscribe@freebsd.org>
Sender: owner-freebsd-net@freebsd.org
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <YZFKPIEROC1cwcOQ@fc.opsec.eu>
X-Rspamd-Queue-Id: 4Hwknd1V07z3FPv
X-Spamd-Bar: /
Authentication-Results: mx1.freebsd.org;
	none
X-Spamd-Result: default: False [0.00 / 15.00];
	 local_wl_from(0.00)[freebsd.org];
	 ASN(0.00)[asn:12502, ipnet:2001:14f8::/32, country:DE]
X-Spam: Yes
X-ThisMailContainsUnwantedMimeParts: N

Hi!

> > > There's one small diff between the two that I do not understand:

> > > -       18040 times no signature provided by segment
> > > +       18045 times no signature provided by segment
> > 
> > This means, that received TCP segment has not TCP-MD5 signature, but
> > listen socket expects it. Such SYN segment will be dropped by syncache
> > code. Probably your BGP daemon configured to use TCP-MD5 for connection,
> > but remote side does not.
> 
> Thanks, that might be another possible cause.

Thanks to your pointer, analysis done by KlaraSystems shows that
the problem seems to be like this:

frr has this open socket where it listens on incoming tcp/179:

tcp4       0      0 *.179                  *.*                    LISTEN     
tcp6       0      0 *.179                  *.*                    LISTEN     

The problem starts sometime after FreeBSD 12.1p8, when some of the bgp
peers have tcp-md5 set and others have not.

If any bgp peer has tcp-md5, it seems, some (all?) non-tcp-md5 secured
bgp peers will fail to connect, until a tcp-md5 secret is configured.

Therefore, we can use this workaround for now and investigate frr
and/or FreeBSD for a proper fix without too much hurry.

-- 
pi@FreeBSD.org         +49 171 3101372                  Now what ?