Re: [Fwknop-discuss] Problems with fwknop

[Michael R. <mb...@ci...>]

On Oct 25, 2008, Eggert Ehmke wrote:

> Hello Michael,
> 
> On Freitag 24 Oktober 2008, Michael Rash wrote:
> > Glad to hear that the issue is solved.
> >
> > > Can you explain what might have been the reason for my problems? As far
> > > as I understood there was a timing issue, but my machine is not
> > > particular slow.
> >
> > Did things start working properly in 1.9.9-pre2 or 1.9.9-pre3?  If pre2,
> > then I'm not sure because there weren't really any significant changes
> > there.  In -pre3 (with the upgraded IPTables::* modules) the changes to
> > the signal handling code is most likely the reason things work properly,
> > although it's a bit difficult to verify this.
> 
> I  guess it works since 1.9.9-pre3. Kernel or IPTables have not been updated 
> recently. But this is a Gentoo system, it might be that other parts have been 
> updated, but I dont think so.

Ok, understood.  It's hard to say for sure exactly what was happening.
The code were the test suite was having problems on your system was
essentially the following in pseudo-code:

if (receive_spa_packet()) {
    for (@ipt_hr) {
        add_iptables_accept_rule();
    }
}

Multiple iptables rules would be added when NAT access was involved, and
each rule addition just used fork/exec/waitpid on the iptables binary
via the IPTables::ChainMgr module.  The module actually interacts with
iptables in several places to check for the existence of the appropriate
chain, check for duplicate rules, etc.  So, iptables would be execute
several times in quick succession.  But, this has never been a problem
for iptables on most systems, and indeed many shell scripts execute
iptables similarly (instead of using iptables-restore which does not
require multiple separate iptables processes to instantiate a policy).

So, I was left with the best theory being that there could be a problem
with the fork/exec/waitpid method of executing iptables.  Previous to
this latest update, the IPTables::ChainMgr module maintained its own
signal handlers and reaper function for child processes, but fwknopd did
also had its own handlers too.  Given that signals are a per-process
API, I thought that this could lead to conflicts (even though I used the
'local' function in perl within the module).  This is the reason for the
module update to accept a reference to a reaper function for SIGCHLD,
which itself is defined in fwknopd.  It is my hope that this fixes the
issue, but even if it doesn't there are other things can now be
configured (such as extra sleep calls between iptables commands to
reduce the rapidity of iptables execution, and the ability to re-try
iptables commands if there is a failure).  Franck had noticed the
"resource temporarily unavailable" message, so the re-try feature may
come in handy.  If the issue still exists, then one of these features
may help.

Thanks,

--Mike


> 
> Regards
> Eggert
> 
> 
> 
> -------------------------------------------------------------------------
> This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
> Build the coolest Linux based applications with Moblin SDK & win great prizes
> Grand prize is a trip for two to an Open Source event anywhere in the world
> http://moblin-contest.org/redirect.php?banner_id=100&url=/
> _______________________________________________
> Fwknop-discuss mailing list
> Fwk...@li...
> https://lists.sourceforge.net/lists/listinfo/fwknop-discuss