Date: Fri, 24 Aug 2007 22:26:15 +0100 From: "Bruce M. Simpson" <bms@FreeBSD.org> To: Randy Bush <randy@psg.com> Cc: FreeBSD Net <freebsd-net@freebsd.org>, boris@tagnet.ru Subject: Re: quagga 0.99.8 on current, tcpmd5 config confusion Message-ID: <46CF4CF7.4030606@FreeBSD.org> In-Reply-To: <18125.12795.336977.904060@roam.psg.com> References: <18125.12795.336977.904060@roam.psg.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Randy Bush wrote: > just did a cvsup build and portupgrade of a six month old -current > i386 system running quagga. quagga cranked to 0.99.8. i got > slammed by bgp tcpmd5 requirement. > > bgpd[469]: can't set sockopt TCP_MD5SIG 0 to socket 17 > bgpd[469]: can't set sockopt TCP_MD5SIG 0 to socket 18 > bgpd[469]: can't set sockopt TCP_MD5SIG 0 to socket 22 > > madly googled and found that i needed to hack kernel for tcp md5 > hash, even though i am not using md5 auth (these are not really > infrastructure peerings. yes i know better for production). > This I haven't seen before, then again, it's been years since I've used Zebra/Quagga let alone hacked the patch for md5 support, which is now ~3.5 years old. It was only ever intended as a belt-and-braces attempt at getting things up in a way which the sponsor was satisfied with, with no other refinements. I wasn't 100% happy about how I ended up doing the kernel support, and had to go with what I had working in my tree because of that old demon 'economics', rather than doing things 'the right way': i.e. in the IPSEC Security Policy Database (SPD), with the routing daemon loading the keys, rather than the Security Associations Database (SADB) and keys loaded manually using setkey(8). Other individuals have since made changes to this code. Now that we have settled on FAST_IPSEC thanks to gnn's hard work, it will be easier for Someone(tm) to pick this up, as KAME IPSEC and FAST_IPSEC interfaced to key sockets differently enough to change the implementation of the SPD. > with this kernel, i got a lot of whining about no keys > > tcp_signature_compute: SADB lookup failed for 666.42.69.96 > I remember putting in the SADB lookup failed message to help people track down problems with their configuration. If TCP_MD5SIG is not enabled on the tcp socket, no SADB lookup should happen, so you shouldn't be seeing this message. It sounds to me as though Quagga may be enabling the TCP_MD5SIG option unconditionally based on all of the output you've posted. This is obviously incorrect. I can't speak for Quagga, though it seems reasonable to suggest that it shouldn't be doing that unless you tell it to. I believe the MD5 patches only get pulled in if you request them, and that md5 auth specifically needs to be enabled per peer. Still, this is nearly 4 years on and I have other things going on now. regards, BMS
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?46CF4CF7.4030606>