Date: Sat, 25 Sep 2004 15:02:33 -0700 From: Sam Leffler <sam@errno.com> To: freebsd-current@freebsd.org Cc: Robert Watson <rwatson@freebsd.org> Subject: Re: 5.3 IPSEC broken Message-ID: <200409251502.34281.sam@errno.com> In-Reply-To: <cone.1096143756.575691.642.1001@phobos.totalterror.net> References: <Pine.NEB.3.96L.1040925150944.79682C-100000@fledge.watson.org> <cone.1096143756.575691.642.1001@phobos.totalterror.net>
next in thread | previous in thread | raw e-mail | index | archive | help
On Saturday 25 September 2004 01:22 pm, Niki Denev wrote: > Robert Watson writes: > > On Sat, 25 Sep 2004, Robert Watson wrote: > >> On Sat, 25 Sep 2004, Hannes Mehnert wrote: > >> > On Fri, Sep 24, 2004 at 10:58:33PM -0400, Robert Watson wrote: > >> > > I'd like to take a look at this sometime in the next few days. > >> > > Could you send me an appropriately censored version of your racoon > >> > > configuration for each endpoint that I can use as a starting point? > >> > > >> > Sure, my config files are available at > >> > https://berlin.ccc.de/~hannes/racoon/ > >> > > >> > I use a /30 subnet for IPSec, 192.168.2.40/30. > >> > >> So an interesting first observation for anyone else following this is > >> that under mbuma, the number of bytes available in an mbuf has changed > >> by four due (presumably) to the use of extra space by mbuma: > > > > A bit more follow-up in case anyone else starts chasing this also: ktrace > > indicates that it's this sendto: > > > > 621 racoon GIO fd 3 wrote 108 bytes > > "<31>Sep 25 15:03:37 racoon: 2004-09-25 15:03:37: DEBUG: > > pfkey.c:1061:p\ > > k_sendupdate(): call pfkey_send_update" > > 621 racoon RET sendto 108/0x6c > > 621 racoon CALL getpid > > 621 racoon RET getpid 621/0x26d > > 621 racoon CALL sendto(0x4,0x809c800,0xd8,0,0,0) > > 621 racoon RET sendto -1 errno 55 No buffer space available > > 621 racoon CALL gettimeofday(0xbfbfe818,0) > > 621 racoon RET gettimeofday 0 > > 621 racoon CALL write(0x1,0x80a2000,0x72) > > 621 racoon GIO fd 1 wrote 114 bytes > > "2004-09-25 15:03:38: ERROR: pfkey.c:1076:pk_sendupdate(): > > libipsec fai\ > > led send update (No buffer space available) > > > > That's a 216 byte packet, fwiw. I instrumented key.c and ran into the > > following ENOBUFS case on key.c:6957: > > > > /* align the mbuf chain so that extensions are in contiguous > > region. */ error = key_align(m, &mh); > > if (error) > > return error; > > > > if (m->m_next) { /*XXX*/ > > m_freem(m); > > return ENOBUFS; > > } > > > > I.e., the author knew it was a bug (feature) that an additional mbuf > > couldn't be handled here, but we do need to handle one. Looks like much > > of the surrounding code could be replaced with a call to m_defrag() > > and/or m_pullup(). > > > > Robert N M Watson FreeBSD Core Team, TrustedBSD Projects > > robert@fledge.watson.org Principal Research Scientist, McAfee > > Research > > Just to mention that i too experience this problem, > but with FAST_IPSEC so this probably means that if any fix will be made for > netkey/key.c then netipsec/key.c will need it too.(as far as i can tell) > Please correct me if i'm wrong. Correct. I gave Robert a fix that was sent to me for fast ipsec. I was going to commit it this weekend after some testing. Sam
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200409251502.34281.sam>