Re: 5.3 IPSEC broken

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.

--niki