openbgpds not talking each other since 8.2-STABLE upgrade

[Borja Marcos]

On Jan 3, 2012, at 4:29 PM, Ed Maste wrote:

> Thanks for the link Nikolay.
> 
> 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 = 1; 
                if (setsockopt(la->fd, IPPROTO_TCP, TCP_MD5SIG, 
                    &opt, sizeof(opt)) == -1) { 
                        if (errno == ENOPROTOOPT) {     /* system w/o md5sig */ 
                                log_warnx("md5sig not available, disabling"); 
                                sysdep.no_md5sig = 1; 
                        } else 
                                fatal("setsockopt TCP_MD5SIG"); 
                } 

Seems that the function is using the setsockopt to check the availability of TCP_MD5. 

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/ea347a919dbc165d/eeaa2965fc4f64c9?show_docid=eeaa2965fc4f64c9&pli=1


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. 

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.