Subject: Re: racoon status?
To: Matthew Grooms <mgrooms@shrew.net>
From: VANHULLEBUS Yvan <vanhu@NetBSD.org>
List: tech-security
Date: 08/27/2007 17:13:22
Hi.


On Fri, Aug 24, 2007 at 06:13:54PM -0500, Matthew Grooms wrote:
[...]
> >My problem: on -current (i386), racoon fails to start complaining that
> >it doesn't have any addresses.  If I add a listen-address directive, it
> >works fine.  I have never before needed a listen-address directive in
> >all my years of running racoon.  This is awkward on a machine that
> >changes addresses.
> 
> Could you send me the exact error string being produced. It will help me 
> to track it down in the source code.

Same exact error string for me, please :-)
(Matthew, if you already got it in another mail, can you send it to me ?).


> >On netbsd-4, racoon works as it has.

Please confirm which version of racoon works on netbsd-4 (is this the
version provided on netbsd-4 ? ipsec-tools's head ? another one ?).


> Unfortunately, I don't have a -current machine to test this with right 
> now. I do have a netbsd-4 machine and can confirm that it works without 
> the listen statements present in the racoon.conf file. There should be 
> very little difference between the ipsec-tools cvs branch and the *very* 
> soon to be released ipsec-tools 0.7 branch. My understanding is that 0.7 
> will be shipped with netbsd-4.

Yep. Matthew, to be completely exact: can you confirm that you tested an
ipsec-tools 0.7.0 release (or at least a very recent RC) on your
netbsd-4 ?


> >seems to mostly consist of PATH_IPSEC_H cleanups, plus some 0/NULL/!=
> >NULL cleanups, a few apparent bugfixes, and some pam changes.
> >
> 
> I believe these changes were added to support the FreeBSD 7 gnn fast 
> ipsec promotion.

Yes, and that patch (related to PATH_IPSEC_H) has been reported to
0.7 branch.


> >Plus this in session.c:
> >
> >
> >                if (lcconf->rtsock >= 0 && FD_ISSET(lcconf->rtsock, 
> >&rfds)) {
> >                        if (update_myaddrs() && lcconf->autograbaddr)
> >-                               sched_new(5, check_rtsock, NULL);
> >-                       initfds();
> >+                               check_rtsock(NULL);
> >+                       else
> >+                               initfds();
> >                }
> >        }
> > }
> >
> >which seems like it could possibly be the cause of my problem.
> >
> 
> This appears to be related to catching dynamic address updates, but I 
> would need to take a closer look. Probably not the cause of your issue. 
> Yvan, Manu or myself will need to dig a bit to see what the cause of 
> your problem is. It may be a new 'feature' that I had yet to take note 
> of. The top priority right now is to get 0.7 out the door and then we 
> will refocus on ipsec-tools head ( in netbsd-current ).

This should just speed up things: check_rtsock is called immediately
instead of being sheduled 5 seconds later.


But while re-reading the patch, there is one difference:
Before the patch, initfds() is called, then check_rtsock() is called,
"some time after" (approx 5 seconds), and check_rtsock() calls again
initfds().

After the patch, initfds() is not called anymore BEFORE check_rtsock()
call, but is only called at the end of check_rtsock().

Could someone who can reproduce the problem do the test by adding a
call to initfds() just before the call to check_rtsock() ?



Yvan.