From owner-freebsd-net@FreeBSD.ORG Wed Jan 4 05:33:30 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 611E1106564A; Wed, 4 Jan 2012 05:33:30 +0000 (UTC) (envelope-from ndenev@gmail.com) Received: from mail-ee0-f54.google.com (mail-ee0-f54.google.com [74.125.83.54]) by mx1.freebsd.org (Postfix) with ESMTP id 97AAE8FC0A; Wed, 4 Jan 2012 05:33:29 +0000 (UTC) Received: by eekc50 with SMTP id c50so19515229eek.13 for ; Tue, 03 Jan 2012 21:33:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=1s8XubGk/svkO2sYDGnsix2cGcF8bVo1PhAWYcTVRhE=; b=XaEZWZy3FtvTW0ynpmoctBpMBEvMTwUIy0x9oPstAIBBq7nLrAhxBhLhdLekh/PCIp NNVS+AIpCaENNadf5cz3YTx4CYuBqdJfLAugZGALacMwDJ9vy8mvZ6quZHNGiu6AMfls 9/iO+qo9cjjU5ZlJfb2gQ410Qk1ROeYZkwNQ8= Received: by 10.14.16.221 with SMTP id h69mr22088700eeh.126.1325655208333; Tue, 03 Jan 2012 21:33:28 -0800 (PST) Received: from imba-brutale.totalterror.net ([93.152.152.135]) by mx.google.com with ESMTPS id u53sm167373199eeu.6.2012.01.03.21.33.26 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 03 Jan 2012 21:33:27 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v1251.1) Content-Type: text/plain; charset=us-ascii From: Nikolay Denev In-Reply-To: <20120103.203608.74677765.sthaug@nethelp.no> Date: Wed, 4 Jan 2012 07:33:25 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <5739312A-614C-492A-BB89-F386B7F74CF5@gmail.com> References: <6FE9FF15-487F-4A31-AEE0-A0AD92F5DC72@sarenet.es> <20DC0C8A-DD9E-408E-9ACA-82532DB31871@lists.zabbadoz.net> <20120104.040611.1847309275485655567.hrs@allbsd.org> <20120103.203608.74677765.sthaug@nethelp.no> To: sthaug@nethelp.no X-Mailer: Apple Mail (2.1251.1) Cc: dougb@FreeBSD.org, freebsd-net@FreeBSD.org, hrs@FreeBSD.org, emaste@FreeBSD.org, borjam@sarenet.es Subject: Re: openbgpds not talking each other since 8.2-STABLE upgrade X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Jan 2012 05:33:30 -0000 On Jan 3, 2012, at 9:36 PM, sthaug@nethelp.no wrote: >> Doug, does your kernel have TCP_SIGNATURE option? The patch[*] for >> net/openbgpd can be used as a workaround if it was due to TCP_MD5SIG >> option on the listening sockets. >>=20 >> [*] http://people.allbsd.org/~hrs/FreeBSD/openbgpd.20120104-1.diff >>=20 >> While this is an ugly hack and I will investigate more reasonable >> solution for that, I want to narrow down the cause first. Can anyone >> who are using a 8-STABLE kenrel with TCP_SIGNATURE let me know if >> this works or not? >=20 > 8-STABLE on several servers, csup'ed only a couple of days ago, with=20= >=20 > options TCP_SIGNATURE > options IPSEC > device crypto > device cryptodev >=20 > and Quagga bgpd talking to Juniper M/MX routers using MD5 key on the > BGP sessions. No problems. >=20 > Steinar Haug, Nethelp consulting, sthaug@nethelp.no This was always working for me. My problem was that I had two routers having BGP sessions to an ISP with md5 and a session between themselves = without md5. After I upgraded to 8-STABLE some time ago, the md5 sessions still = worked, but the ones without did not. tcpdump showed packets with md5 digest fields = all zeroes. If one of the machines does not have md5 signature support it will = probably work, since when one of the routers tries to speak tcpmd5 even with incorrect = digest field, the other one tries to respond also with tcpmd5. Also there are some things in the tcp(4) manual page that should be = fixed to reflect the new behaviour (the part mentioning that incoming digests are not = verified): TCP_MD5SIG This option enables the use of MD5 digests (also known = as TCP-MD5) on writes to the specified socket. In the = current release, only outgoing traffic is digested; digests on incoming traffic are not verified. The current = default behavior for the system is to respond to a system = advertis- ing this option with TCP-MD5; this may change. Also in the case of my failing BGP sessions I expected to see errors as = per the man page : If an SADB entry cannot be found for the destination, = the outgoing traffic will have an invalid digest option prepended, and the following error message will be = visible on the system console: tcp_signature_compute: SADB = lookup failed for %d.%d.%d.%d. But this was not happening. Regards, Nikolay