Re: 5.3 IPSEC broken

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_at_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