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.