From owner-freebsd-current@FreeBSD.ORG Sat Sep 25 19:17:53 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2AA2116A4CE for ; Sat, 25 Sep 2004 19:17:53 +0000 (GMT) Received: from fledge.watson.org (fledge.watson.org [204.156.12.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9EA8043D45 for ; Sat, 25 Sep 2004 19:17:52 +0000 (GMT) (envelope-from robert@fledge.watson.org) Received: from fledge.watson.org (localhost [127.0.0.1]) by fledge.watson.org (8.13.1/8.13.1) with ESMTP id i8PJH1Wx080660; Sat, 25 Sep 2004 15:17:01 -0400 (EDT) (envelope-from robert@fledge.watson.org) Received: from localhost (robert@localhost)i8PJH1vX080657; Sat, 25 Sep 2004 15:17:01 -0400 (EDT) (envelope-from robert@fledge.watson.org) Date: Sat, 25 Sep 2004 15:17:00 -0400 (EDT) From: Robert Watson X-Sender: robert@fledge.watson.org To: Hannes Mehnert In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: freebsd-current@freebsd.org Subject: Re: 5.3 IPSEC broken X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 25 Sep 2004 19:17:53 -0000 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