Date: Sat, 25 Sep 2004 15:17:00 -0400 (EDT) From: Robert Watson <rwatson@freebsd.org> To: Hannes Mehnert <hannes@mehnert.org> Cc: freebsd-current@freebsd.org Subject: Re: 5.3 IPSEC broken Message-ID: <Pine.NEB.3.96L.1040925150944.79682C-100000@fledge.watson.org> In-Reply-To: <Pine.NEB.3.96L.1040925133727.79682B-100000@fledge.watson.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.NEB.3.96L.1040925150944.79682C-100000>