From owner-freebsd-net@FreeBSD.ORG Wed Jan 4 08:27:31 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 12C07106566C; Wed, 4 Jan 2012 08:27:31 +0000 (UTC) (envelope-from borjam@sarenet.es) Received: from proxypop04b.sare.net (proxypop04b.sare.net [194.30.0.79]) by mx1.freebsd.org (Postfix) with ESMTP id BEDE48FC08; Wed, 4 Jan 2012 08:27:30 +0000 (UTC) Received: from [172.16.2.2] (izaro.sarenet.es [192.148.167.11]) by proxypop04.sare.net (Postfix) with ESMTPSA id 34D879DC498; Wed, 4 Jan 2012 09:27:29 +0100 (CET) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Borja Marcos In-Reply-To: <20120103152909.GA83706@sandvine.com> Date: Wed, 4 Jan 2012 09:27:28 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <680405C8-3323-49BC-AE59-494FC394B6F6@sarenet.es> References: <99A5FFD9-8815-4CCC-9868-FB2E3D799566@gridfury.com> <4F027BC0.1080101@FreeBSD.org> <8F87C898-3290-41B9-ACDF-3558D7C28D74@gmail.com> <20120103152909.GA83706@sandvine.com> To: Ed Maste X-Mailer: Apple Mail (2.1084) Cc: Nikolay Denev , freebsd-net@freebsd.org 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 08:27:31 -0000 On Jan 3, 2012, at 4:29 PM, Ed Maste wrote: > Thanks for the link Nikolay. >=20 > Borja, I assume it's the PR submission form that gave you trouble - > sorry for that. Based on your report it sounds to me like the bug is > in OpenBGPd itself. If it works on OpenBSD with the TCP_MD5SIG option > though I'd assume it's due to a difference in our (FreeBSD's) > implementation of the option. Did you look at the OpenBSD/FreeBSD > differences in your investigation? I looked at OpenBGPd. By the way, I was having the same issue on the = different FreeBSD 9 RC's I was trying. Have a look at session.c, line 148, function setup_listeners() opt =3D 1;=20 if (setsockopt(la->fd, IPPROTO_TCP, TCP_MD5SIG,=20 &opt, sizeof(opt)) =3D=3D -1) {=20 if (errno =3D=3D ENOPROTOOPT) { /* system = w/o md5sig */=20 log_warnx("md5sig not available, = disabling");=20 sysdep.no_md5sig =3D 1;=20 } else=20 fatal("setsockopt TCP_MD5SIG");=20 }=20 Seems that the function is using the setsockopt to check the = availability of TCP_MD5.=20 But, even though I haven't had a look at it on OpenBSD, I can make an = educated guess: Behavior on FreeBSD: The setsockopt(TCP_MD5SIG) *enables* TCP_MD5. = According to my packet captures, in case there's no properly set key = with setkey(8) it will use whatever key. Look at the captures mentioned = here: = http://groups.google.com/group/mailing.freebsd.bugs/browse_thread/thread/e= a347a919dbc165d/eeaa2965fc4f64c9?show_docid=3Deeaa2965fc4f64c9&pli=3D1 Behavior on OpenBSD: Maybe the TCP_MD5 isn't *really* working unless = there's a valid key associated to the socket, either using setkey(8) (I = don't know if they use it) or via the API for setting keys. Whatever: Maybe FreeBSD should *ignore* that TCP_MD5SIG option for a = socket unless (or until) a key is associated, or OpenBGPd should be = modified so that it won't "probe" the availability of TCP_MD5SIG by = actually setting it. Of course, if setting it for a socket is the best = way to detect it, you can always create a temporary socket, you don't = even need to bind() it, set TCP_MD5SIG, so that you will know if it = succeeds or returns an error, and destroy the socket.=20 The problem in this case is that OpenBGPd is *setting* TCP_MD5SIG on a = socket no matter if I have configured the BGP peer with or without = TCP_MD5. Neither Quagga nor Bird do it. Borja.