Skip site navigation (1)Skip section navigation (2)
Date:      Wed, 4 Jan 2012 09:27:28 +0100
From:      Borja Marcos <borjam@sarenet.es>
To:        Ed Maste <emaste@freebsd.org>
Cc:        Nikolay Denev <ndenev@gmail.com>, freebsd-net@freebsd.org
Subject:   Re: openbgpds not talking each other since 8.2-STABLE upgrade
Message-ID:  <680405C8-3323-49BC-AE59-494FC394B6F6@sarenet.es>
In-Reply-To: <20120103152909.GA83706@sandvine.com>
References:  <99A5FFD9-8815-4CCC-9868-FB2E3D799566@gridfury.com> <4F027BC0.1080101@FreeBSD.org> <8F87C898-3290-41B9-ACDF-3558D7C28D74@gmail.com> <20120103152909.GA83706@sandvine.com>

next in thread | previous in thread | raw e-mail | index | archive | help

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.




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?680405C8-3323-49BC-AE59-494FC394B6F6>