Thread: Re: [Fwknop-discuss] Problems with fwknop
Brought to you by:
mbr
From: Ehmke E. <egg...@be...> - 2008-10-06 09:22:31
|
Hi Michael, thanks for your detailed analysis. I will run the new test suite tonight, when I have access to the system again. This time I will disable the monit daemon for the test, agree? Regards Eggert ----- ursprüngliche Nachricht --------- On Oct 04, 2008, Eggert Ehmke wrote: > Hello Michael, Hi Eggert - > attached you find the file generated by the test suite. I followed these steps > to create it: > > -Opened ssh session on root server (fwknop was working) > -stopped fwknop daemon > -changed to test subdirectory of fwknop source > -run "sudo ./fwknop_test.pl" > -run "sudo ./fwknop_test.pl --Prepare-results" > -transfered the generated tar.gz file to my home system and attached it to > this mail > -restarted the fwknop daemon on the root server, but was already running > because of my monit daemon. > > Now that I look into the 175.test file, there are a lot of errors from the > monit daemon, that is used to keep important processes running, including > fwknopd. I have this in my /etc/monit/monit.d/fwknop file: > > check process fwknopd with pidfile /var/run/fwknop/knopwatchd.pid > start program = "/etc/init.d/fwknop start" > stop program = "/etc/init.d/fwknop stop" > group server > > Maybe there is an interference? Yes, having monit start fwknop while the test suite is running might produce unexpected results because the fwknopd daemon normally flushes any existing firewall (iptables or ipfw) rules at init time. The test suite is careful to only apply firewall rules to the loopback interface, so it shouldn't interfere with remote communication with your system. So, it should be safe to run the test suite with the installed fwknop software not running - you could also add a temporary ACCEPT rule for your session if you would like to be completely sure. I've looked through the test suite output that you sent, and it does contain some interesting bits of information. First, for each test that failed, the test ends with the test suite catch-all alarm after attempting to execute an iptables command. It's almost as though executing iptables becomes extremely slow (on the order of 20 seconds) to return. Second, it looks like the default stance in your iptables policy for incoming connections to tcp/22 is to use the REJECT target in the absence of an ACCEPT rule created by fwknop. So, that would imply that the "Connection refused" messages really are coming from iptables instead of the TCP stack (i.e. sshd is definitely listening, but iptables is resetting the connection attempt). Finally, one of the "Local NAT" tests is failing (# 158), which is the mode that I believe you are trying to use, correct? To try and get some more detail on the long running iptables commands I have updated the --debug mode in fwknopd to give better output when executing iptables commands in fwknop-1.9.9-pre2: http://www.cipherdyne.org/fwknop/download/fwknop-1.9.9-pre2.tar.gz If it isn't too much trouble, could you put this on the system running fwknopd currently and send me the anonymized test suite output? You don't need to actually install 1.9.9-pre1 - just untar it somewhere and run the test suite. Thanks, -- Michael Rash http://www.cipherdyne.org/ Key fingerprint: E2EF 0C8A 5AA9 654C 4763 B50F 37AC E946 7F51 8271 > > > Regards > Eggert > > On Samstag 04 Oktober 2008, you wrote: > > (resending this message to the list - seems as though Sourceforge may > > have some mail issues right now) > > > > On Oct 02, 2008, Eggert Ehmke wrote: > > > Hello Michael, > > > > > > occasionaly (every some days of no problems) I cannot log in to my root > > > server and get "Connection refused". In case of these connections, only > > > the two mails are received: > > > xxxx fwknopd: add FWKNOP_PREROUTING xxx.188.31.xxx -> > > > 85.214.47.xxx(tcp/65080 to 22) DNAT rule 20 sec > > > xxxx knoptm: removed iptables FWKNOP_PREROUTING DNAT rule for > > > xxx.188.31.xxx -> 85.214.47.xxx(tcp/22), 20 sec timeout exceeded > > > > > > In the cases when all works fine, I get two additional mails: > > > xxxx fwknopd: add FWKNOP_INPUT xxx.188.49.xxx -> 0.0.0.0/0(tcp/22) ACCEPT > > > rule 20 sec > > > xxxx knoptm: removed iptables FWKNOP_INPUT ACCEPT rule for xxx.188.49.xxx > > > -> 0.0.0.0/0(tcp/22), 20 sec timeout exceeded > > > > > > To restore to the working state, I have to restart the fwknop daemon by > > > /etc/init.d/fwknop restart. I have a terminal server so I can get access > > > to the root server by this means. > > > > Hmm, clearly that needs to be fixed. Thanks for reporting this. Are > > there any additional messages written to syslog by fwknopd? There are > > several places where a syslog message is generated and no corresponding > > email is sent. But, there may not be any log messages that particularly > > help in this situation. > > > > > Currently I run fwknop 1.9.8, but the problem occoured already some > > > releases early. Would be great if we could solve the issue. If you need > > > any debug information or log files, let me know. > > > > Can you run the test suite on the system running fwknopd, and send me > > the anonymized output (-P)? The reason I ask this is that the results > > will collect a lot of system specifics that may be important to this > > this bug (even though the test suite may appear to pass all tests). For > > example, the fact that you are receiving "Connection refused" is > > interesting, because this implies that a RST is being sent. Hence, > > either the daemon itself is not available (the port is closed) but there > > must be an ACCEPT rule to reach the port in the first place, or iptables > > is sending a RST via the REJECT target. Running the test suite will > > collect the iptables policy (anonymized) so this will help clarify. > > > > I may need to send you a -pre release of 1.9.9 to help fix this problem. > > > > Thanks, > > > > -- > > Michael Rash > > http://www.cipherdyne.org/ > > Key fingerprint: E2EF 0C8A 5AA9 654C 4763 B50F 37AC E946 7F51 8271 > > > > > 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 > > > ------------------------------------------------------------------------- > 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 ------------------------------------------------------------------------- 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 ---- ursprüngliche Nachricht Ende ---- |
From: Ehmke E. <egg...@be...> - 2008-10-06 19:09:20
Attachments:
fwknop_test.tar.gz
|
Hello Michael, here is the new test result. The system was not reachable as described at that time. I stopped fwknopd and monit, ran the test suite, transfered the archive to my home system and restarted the daemons. The system was reachable again as normal. Regards Eggert ----- ursprüngliche Nachricht --------- On Oct 06, 2008, Ehmke Eggert wrote: > Hi Michael, > > thanks for your detailed analysis. I will run the new test suite tonight, when I have access to the system again. This time I will disable the monit daemon for the test, agree? Yes, disabling the monit daemon while the test suite runs would be best. Thanks, --Mike > Regards > Eggert > > > > > > ----- ursprüngliche Nachricht --------- > > On Oct 04, 2008, Eggert Ehmke wrote: > > > Hello Michael, > > Hi Eggert - > > > attached you find the file generated by the test suite. I followed these steps > > to create it: > > > > -Opened ssh session on root server (fwknop was working) > > -stopped fwknop daemon > > -changed to test subdirectory of fwknop source > > -run "sudo ./fwknop_test.pl" > > -run "sudo ./fwknop_test.pl --Prepare-results" > > -transfered the generated tar.gz file to my home system and attached it to > > this mail > > -restarted the fwknop daemon on the root server, but was already running > > because of my monit daemon. > > > > Now that I look into the 175.test file, there are a lot of errors from the > > monit daemon, that is used to keep important processes running, including > > fwknopd. I have this in my /etc/monit/monit.d/fwknop file: > > > > check process fwknopd with pidfile /var/run/fwknop/knopwatchd.pid > > start program = "/etc/init.d/fwknop start" > > stop program = "/etc/init.d/fwknop stop" > > group server > > > > Maybe there is an interference? > > Yes, having monit start fwknop while the test suite is running might > produce unexpected results because the fwknopd daemon normally flushes > any existing firewall (iptables or ipfw) rules at init time. The test > suite is careful to only apply firewall rules to the loopback interface, > so it shouldn't interfere with remote communication with your system. > So, it should be safe to run the test suite with the installed fwknop > software not running - you could also add a temporary ACCEPT rule for > your session if you would like to be completely sure. > > I've looked through the test suite output that you sent, and it does > contain some interesting bits of information. First, for each test that > failed, the test ends with the test suite catch-all alarm after > attempting to execute an iptables command. It's almost as though > executing iptables becomes extremely slow (on the order of 20 seconds) > to return. Second, it looks like the default stance in your iptables > policy for incoming connections to tcp/22 is to use the REJECT target in > the absence of an ACCEPT rule created by fwknop. So, that would imply > that the "Connection refused" messages really are coming from iptables > instead of the TCP stack (i.e. sshd is definitely listening, but > iptables is resetting the connection attempt). Finally, one of the > "Local NAT" tests is failing (# 158), which is the mode that I believe > you are trying to use, correct? > > To try and get some more detail on the long running iptables commands I > have updated the --debug mode in fwknopd to give better output when > executing iptables commands in fwknop-1.9.9-pre2: > > http://www.cipherdyne.org/fwknop/download/fwknop-1.9.9-pre2.tar.gz > > If it isn't too much trouble, could you put this on the system running > fwknopd currently and send me the anonymized test suite output? You don't > need to actually install 1.9.9-pre1 - just untar it somewhere and run the > test suite. > > Thanks, > > -- > Michael Rash > http://www.cipherdyne.org/ > Key fingerprint: E2EF 0C8A 5AA9 654C 4763 B50F 37AC E946 7F51 8271 > > > > > > > Regards > > Eggert > > > > On Samstag 04 Oktober 2008, you wrote: > > > (resending this message to the list - seems as though Sourceforge may > > > have some mail issues right now) > > > > > > On Oct 02, 2008, Eggert Ehmke wrote: > > > > Hello Michael, > > > > > > > > occasionaly (every some days of no problems) I cannot log in to my root > > > > server and get "Connection refused". In case of these connections, only > > > > the two mails are received: > > > > xxxx fwknopd: add FWKNOP_PREROUTING xxx.188.31.xxx -> > > > > 85.214.47.xxx(tcp/65080 to 22) DNAT rule 20 sec > > > > xxxx knoptm: removed iptables FWKNOP_PREROUTING DNAT rule for > > > > xxx.188.31.xxx -> 85.214.47.xxx(tcp/22), 20 sec timeout exceeded > > > > > > > > In the cases when all works fine, I get two additional mails: > > > > xxxx fwknopd: add FWKNOP_INPUT xxx.188.49.xxx -> 0.0.0.0/0(tcp/22) ACCEPT > > > > rule 20 sec > > > > xxxx knoptm: removed iptables FWKNOP_INPUT ACCEPT rule for xxx.188.49.xxx > > > > -> 0.0.0.0/0(tcp/22), 20 sec timeout exceeded > > > > > > > > To restore to the working state, I have to restart the fwknop daemon by > > > > /etc/init.d/fwknop restart. I have a terminal server so I can get access > > > > to the root server by this means. > > > > > > Hmm, clearly that needs to be fixed. Thanks for reporting this. Are > > > there any additional messages written to syslog by fwknopd? There are > > > several places where a syslog message is generated and no corresponding > > > email is sent. But, there may not be any log messages that particularly > > > help in this situation. > > > > > > > Currently I run fwknop 1.9.8, but the problem occoured already some > > > > releases early. Would be great if we could solve the issue. If you need > > > > any debug information or log files, let me know. > > > > > > Can you run the test suite on the system running fwknopd, and send me > > > the anonymized output (-P)? The reason I ask this is that the results > > > will collect a lot of system specifics that may be important to this > > > this bug (even though the test suite may appear to pass all tests). For > > > example, the fact that you are receiving "Connection refused" is > > > interesting, because this implies that a RST is being sent. Hence, > > > either the daemon itself is not available (the port is closed) but there > > > must be an ACCEPT rule to reach the port in the first place, or iptables > > > is sending a RST via the REJECT target. Running the test suite will > > > collect the iptables policy (anonymized) so this will help clarify. > > > > > > I may need to send you a -pre release of 1.9.9 to help fix this problem. > > > > > > Thanks, > > > > > > -- > > > Michael Rash > > > http://www.cipherdyne.org/ > > > Key fingerprint: E2EF 0C8A 5AA9 654C 4763 B50F 37AC E946 7F51 8271 > > > > > > > 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 > > > > > > > > ------------------------------------------------------------------------- > > 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 > > > ------------------------------------------------------------------------- > 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 > > ---- ursprüngliche Nachricht Ende ---- > > ------------------------------------------------------------------------- > 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 ------------------------------------------------------------------------- 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 ---- ursprüngliche Nachricht Ende ---- |
From: Michael R. <mb...@ci...> - 2008-10-08 05:38:11
Attachments:
chainmgr.patch
|
On Oct 06, 2008, Ehmke Eggert wrote: > Hello Michael, Hi Eggert - > here is the new test result. The system was not reachable as described at that time. I stopped fwknopd and monit, ran the test suite, transfered the archive to my home system and restarted the daemons. The system was reachable again as normal. That test suite output was interesting once again. The tests that failed were because the 20 second alarm timer expired while the IPTables::ChainMgr module was trying to execute an iptables command. So, the question becomes whether iptables really is taking that long on your system in some cases, or if the IPTables::ChainMgr module thinks it does incorrectly. In the former case, something deeper must be going on - I noticed that you are running kernel 2.6.18, which is a bit old, I don't know of a specific bug that would cause this behavior. In the later case, there could be bug in the signal handling code in the IPTables::ChainMgr module (potentially). The /usr/lib/fwknop directory exists on your system, so at some point I believe that you installed fwknop via the install.pl script? Since you are running Debian, would it be possible for you to remove this directory and use the Debian packages for the IPTables::ChainMgr and IPTables::Parse modules that Franck Joncourt created? Then, if IPTables::ChainMgr is installed at /usr/share/perl5/IPTables/ChainMgr.pm, could you apply the patch I have attached to this email and run the test suite one more time? The patch changes the SIGCHLD / waitpid strategy to just use system() when executing iptables. If the test suite passes the tests in this case, then I will certainly update the module to offer multiple execution styles for the iptables binary. It is also possible that if iptables really is "freezing" for some weird reason then the test suite will show the same results (which would still be useful to know). (You will probably want to make a backup of the original ChainMgr.pm file before trying this). Thanks, --Mike > > Regards > Eggert > > > > > > > ----- ursprüngliche Nachricht --------- > > On Oct 06, 2008, Ehmke Eggert wrote: > > > Hi Michael, > > > > thanks for your detailed analysis. I will run the new test suite tonight, when I have access to the system again. This time I will disable the monit daemon for the test, agree? > > Yes, disabling the monit daemon while the test suite runs would be best. > > Thanks, > > --Mike > > > > Regards > > Eggert > > > > > > > > > > > > ----- ursprüngliche Nachricht --------- > > > > On Oct 04, 2008, Eggert Ehmke wrote: > > > > > Hello Michael, > > > > Hi Eggert - > > > > > attached you find the file generated by the test suite. I followed these steps > > > to create it: > > > > > > -Opened ssh session on root server (fwknop was working) > > > -stopped fwknop daemon > > > -changed to test subdirectory of fwknop source > > > -run "sudo ./fwknop_test.pl" > > > -run "sudo ./fwknop_test.pl --Prepare-results" > > > -transfered the generated tar.gz file to my home system and attached it to > > > this mail > > > -restarted the fwknop daemon on the root server, but was already running > > > because of my monit daemon. > > > > > > Now that I look into the 175.test file, there are a lot of errors from the > > > monit daemon, that is used to keep important processes running, including > > > fwknopd. I have this in my /etc/monit/monit.d/fwknop file: > > > > > > check process fwknopd with pidfile /var/run/fwknop/knopwatchd.pid > > > start program = "/etc/init.d/fwknop start" > > > stop program = "/etc/init.d/fwknop stop" > > > group server > > > > > > Maybe there is an interference? > > > > Yes, having monit start fwknop while the test suite is running might > > produce unexpected results because the fwknopd daemon normally flushes > > any existing firewall (iptables or ipfw) rules at init time. The test > > suite is careful to only apply firewall rules to the loopback interface, > > so it shouldn't interfere with remote communication with your system. > > So, it should be safe to run the test suite with the installed fwknop > > software not running - you could also add a temporary ACCEPT rule for > > your session if you would like to be completely sure. > > > > I've looked through the test suite output that you sent, and it does > > contain some interesting bits of information. First, for each test that > > failed, the test ends with the test suite catch-all alarm after > > attempting to execute an iptables command. It's almost as though > > executing iptables becomes extremely slow (on the order of 20 seconds) > > to return. Second, it looks like the default stance in your iptables > > policy for incoming connections to tcp/22 is to use the REJECT target in > > the absence of an ACCEPT rule created by fwknop. So, that would imply > > that the "Connection refused" messages really are coming from iptables > > instead of the TCP stack (i.e. sshd is definitely listening, but > > iptables is resetting the connection attempt). Finally, one of the > > "Local NAT" tests is failing (# 158), which is the mode that I believe > > you are trying to use, correct? > > > > To try and get some more detail on the long running iptables commands I > > have updated the --debug mode in fwknopd to give better output when > > executing iptables commands in fwknop-1.9.9-pre2: > > > > http://www.cipherdyne.org/fwknop/download/fwknop-1.9.9-pre2.tar.gz > > > > If it isn't too much trouble, could you put this on the system running > > fwknopd currently and send me the anonymized test suite output? You don't > > need to actually install 1.9.9-pre1 - just untar it somewhere and run the > > test suite. > > > > Thanks, > > > > -- > > Michael Rash > > http://www.cipherdyne.org/ > > Key fingerprint: E2EF 0C8A 5AA9 654C 4763 B50F 37AC E946 7F51 8271 > > > > > > > > > > > Regards > > > Eggert > > > > > > On Samstag 04 Oktober 2008, you wrote: > > > > (resending this message to the list - seems as though Sourceforge may > > > > have some mail issues right now) > > > > > > > > On Oct 02, 2008, Eggert Ehmke wrote: > > > > > Hello Michael, > > > > > > > > > > occasionaly (every some days of no problems) I cannot log in to my root > > > > > server and get "Connection refused". In case of these connections, only > > > > > the two mails are received: > > > > > xxxx fwknopd: add FWKNOP_PREROUTING xxx.188.31.xxx -> > > > > > 85.214.47.xxx(tcp/65080 to 22) DNAT rule 20 sec > > > > > xxxx knoptm: removed iptables FWKNOP_PREROUTING DNAT rule for > > > > > xxx.188.31.xxx -> 85.214.47.xxx(tcp/22), 20 sec timeout exceeded > > > > > > > > > > In the cases when all works fine, I get two additional mails: > > > > > xxxx fwknopd: add FWKNOP_INPUT xxx.188.49.xxx -> 0.0.0.0/0(tcp/22) ACCEPT > > > > > rule 20 sec > > > > > xxxx knoptm: removed iptables FWKNOP_INPUT ACCEPT rule for xxx.188.49.xxx > > > > > -> 0.0.0.0/0(tcp/22), 20 sec timeout exceeded > > > > > > > > > > To restore to the working state, I have to restart the fwknop daemon by > > > > > /etc/init.d/fwknop restart. I have a terminal server so I can get access > > > > > to the root server by this means. > > > > > > > > Hmm, clearly that needs to be fixed. Thanks for reporting this. Are > > > > there any additional messages written to syslog by fwknopd? There are > > > > several places where a syslog message is generated and no corresponding > > > > email is sent. But, there may not be any log messages that particularly > > > > help in this situation. > > > > > > > > > Currently I run fwknop 1.9.8, but the problem occoured already some > > > > > releases early. Would be great if we could solve the issue. If you need > > > > > any debug information or log files, let me know. > > > > > > > > Can you run the test suite on the system running fwknopd, and send me > > > > the anonymized output (-P)? The reason I ask this is that the results > > > > will collect a lot of system specifics that may be important to this > > > > this bug (even though the test suite may appear to pass all tests). For > > > > example, the fact that you are receiving "Connection refused" is > > > > interesting, because this implies that a RST is being sent. Hence, > > > > either the daemon itself is not available (the port is closed) but there > > > > must be an ACCEPT rule to reach the port in the first place, or iptables > > > > is sending a RST via the REJECT target. Running the test suite will > > > > collect the iptables policy (anonymized) so this will help clarify. > > > > > > > > I may need to send you a -pre release of 1.9.9 to help fix this problem. > > > > > > > > Thanks, > > > > > > > > -- > > > > Michael Rash > > > > http://www.cipherdyne.org/ > > > > Key fingerprint: E2EF 0C8A 5AA9 654C 4763 B50F 37AC E946 7F51 8271 > > > > > > > > > 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 > > > > > > > > > > > > > ------------------------------------------------------------------------- > > > 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 > > > > > > ------------------------------------------------------------------------- > > 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 > > > > ---- ursprüngliche Nachricht Ende ---- > > > > ------------------------------------------------------------------------- > > 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 > > ------------------------------------------------------------------------- > 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 > > ---- ursprüngliche Nachricht Ende ---- > ------------------------------------------------------------------------- > 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 |
From: Eggert E. <egg...@be...> - 2008-10-08 22:55:51
|
Hello Michael, things start to become weird. I installed the packages as you described and applied your patch. Now the start of the test suite looks like this: $ sudo ./fwknop_test.pl [+] ==> Running fwknop test suite; firewall: iptables <== (Setup) perl program compilation....................................pass (0) (Setup) C program compilation.......................................pass (1) (Setup) Command line argument processing............................pass (2) (Setup) Last command line execution.................................pass (3) (Setup) Expected code version.......................................pass (4) (Setup) List iptables rules.........................................pass (5) (Setup) System information and fwknop installation specifics........pass (6) (Setup) Dump config.................................................fail (7) [-] Could not execute: ../fwknopd --Dump-config STDOUT and STDERR available in: output/7.test file. (Setup) Override config.............................................fail (8) [-] Could not execute: ../fwknopd --Override-config conf/override_sleep_fwknop.conf --Dump-config STDOUT and STDERR available in: output/8.test file. (Setup) Caching SPA packets to disk.................................fail (9) [-] Could not execute: ../fwknop ../fwknop -A tcp/22 --no-save --get-key local_spa.key -D 127.0.0.1 -a 127.0.0.2 --Test-mode -v --debug --Spoof-user root --Save-packet --Save-packet-file output/SPA_pkt.single STDOUT and STDERR available in: output/9.test file. (Setup) Caching multiple SPA packets to disk........................fail (10) [-] Could not execute: ../fwknop ../fwknop -A tcp/22 --no-save --get-key local_spa.key -D 127.0.0.1 -a 127.0.0.2 --Test-mode -v --debug --Spoof-user root --Save-packet --Save-packet-file output/SPA_pkt.multi --Save-packet-append STDOUT and STDERR available in: output/10.test file. (Setup) Stopping any running fwknopd processes......................pass (11) (Setup) Flushing all fwknopd iptables rules.........................pass (12) (Setup) Deleting all fwknopd iptables chains........................fail (13) [-] Not all fwknop chains were removed STDOUT and STDERR available in: output/13.test file. (Basic communications) Generating SPA access packet.................fail (14) [-] Could not generate encrypted SPA packet STDOUT and STDERR available in: output/14.test file. (Basic communications) Sniffing SPA access packet................... [*] Zero-length SPA packet at ./fwknop_test.pl line 772. Not exacly an improvement. When I now try to restart the fwknop daemon, I get this: $ sudo /etc/init.d/fwknop start Starting the fwknop daemons. SYSTEM(/sbin/iptables -t filter -v -n -L INPUT) SYSTEM(/sbin/iptables -t filter -v -n -L FORWARD) SYSTEM(/sbin/iptables -t nat -v -n -L PREROUTING) SYSTEM(/sbin/iptables -t filter -v -n -L FWKNOP_INPUT) SYSTEM(/sbin/iptables -t filter -F FWKNOP_INPUT) SYSTEM(/sbin/iptables -t filter -v -n -L FWKNOP_FORWARD) SYSTEM(/sbin/iptables -t filter -F FWKNOP_FORWARD) SYSTEM(/sbin/iptables -t nat -v -n -L FWKNOP_PREROUTING) SYSTEM(/sbin/iptables -t nat -F FWKNOP_PREROUTING) SYSTEM(/sbin/iptables -v -n -L) Can't locate GnuPG/Interface.pm in @INC (@INC contains: /etc/perl /usr/local/lib/perl/5.8.8 /usr/local/share/perl/5.8.8 /usr/lib/perl5 /usr/share/perl5 /usr/lib/perl/5.8 /usr/share/perl/5.8 /usr/local/lib/site_perl .) at /usr/sbin/fwknopd line 3515. so there is something broken now. Its too late now, will try to fix it tomorrow. Do I need gnupg perl packages from Debian, that where provided by fwknop sources before? Regards Eggert On Mittwoch 08 Oktober 2008, Michael Rash wrote: > On Oct 06, 2008, Ehmke Eggert wrote: > > Hello Michael, > > Hi Eggert - > > > here is the new test result. The system was not reachable as described at > > that time. I stopped fwknopd and monit, ran the test suite, transfered > > the archive to my home system and restarted the daemons. The system was > > reachable again as normal. > > That test suite output was interesting once again. The tests that > failed were because the 20 second alarm timer expired while the > IPTables::ChainMgr module was trying to execute an iptables command. > So, the question becomes whether iptables really is taking that long on > your system in some cases, or if the IPTables::ChainMgr module thinks it > does incorrectly. In the former case, something deeper must be going on > - I noticed that you are running kernel 2.6.18, which is a bit old, > I don't know of a specific bug that would cause this behavior. In the > later case, there could be bug in the signal handling code in the > IPTables::ChainMgr module (potentially). > > The /usr/lib/fwknop directory exists on your system, so at some point I > believe that you installed fwknop via the install.pl script? Since you > are running Debian, would it be possible for you to remove this > directory and use the Debian packages for the IPTables::ChainMgr and > IPTables::Parse modules that Franck Joncourt created? > > Then, if IPTables::ChainMgr is installed at > /usr/share/perl5/IPTables/ChainMgr.pm, could you apply the patch I have > attached to this email and run the test suite one more time? The patch > changes the SIGCHLD / waitpid strategy to just use system() when > executing iptables. If the test suite passes the tests in this case, > then I will certainly update the module to offer multiple execution > styles for the iptables binary. It is also possible that if iptables > really is "freezing" for some weird reason then the test suite will show > the same results (which would still be useful to know). (You will > probably want to make a backup of the original ChainMgr.pm file before > trying this). > > Thanks, > > --Mike > > > Regards > > Eggert > > > > > > > > > > > > > > ----- ursprüngliche Nachricht --------- > > > > On Oct 06, 2008, Ehmke Eggert wrote: > > > Hi Michael, > > > > > > thanks for your detailed analysis. I will run the new test suite > > > tonight, when I have access to the system again. This time I will > > > disable the monit daemon for the test, agree? > > > > Yes, disabling the monit daemon while the test suite runs would be best. > > > > Thanks, > > > > --Mike > > > > > Regards > > > Eggert > > > > > > > > > > > > > > > > > > ----- ursprüngliche Nachricht --------- > > > > > > On Oct 04, 2008, Eggert Ehmke wrote: > > > > Hello Michael, > > > > > > Hi Eggert - > > > > > > > attached you find the file generated by the test suite. I followed > > > > these steps to create it: > > > > > > > > -Opened ssh session on root server (fwknop was working) > > > > -stopped fwknop daemon > > > > -changed to test subdirectory of fwknop source > > > > -run "sudo ./fwknop_test.pl" > > > > -run "sudo ./fwknop_test.pl --Prepare-results" > > > > -transfered the generated tar.gz file to my home system and attached > > > > it to this mail > > > > -restarted the fwknop daemon on the root server, but was already > > > > running because of my monit daemon. > > > > > > > > Now that I look into the 175.test file, there are a lot of errors > > > > from the monit daemon, that is used to keep important processes > > > > running, including fwknopd. I have this in my > > > > /etc/monit/monit.d/fwknop file: > > > > > > > > check process fwknopd with pidfile /var/run/fwknop/knopwatchd.pid > > > > start program = "/etc/init.d/fwknop start" > > > > stop program = "/etc/init.d/fwknop stop" > > > > group server > > > > > > > > Maybe there is an interference? > > > > > > Yes, having monit start fwknop while the test suite is running might > > > produce unexpected results because the fwknopd daemon normally flushes > > > any existing firewall (iptables or ipfw) rules at init time. The test > > > suite is careful to only apply firewall rules to the loopback > > > interface, so it shouldn't interfere with remote communication with > > > your system. So, it should be safe to run the test suite with the > > > installed fwknop software not running - you could also add a temporary > > > ACCEPT rule for your session if you would like to be completely sure. > > > > > > I've looked through the test suite output that you sent, and it does > > > contain some interesting bits of information. First, for each test > > > that failed, the test ends with the test suite catch-all alarm after > > > attempting to execute an iptables command. It's almost as though > > > executing iptables becomes extremely slow (on the order of 20 seconds) > > > to return. Second, it looks like the default stance in your iptables > > > policy for incoming connections to tcp/22 is to use the REJECT target > > > in the absence of an ACCEPT rule created by fwknop. So, that would > > > imply that the "Connection refused" messages really are coming from > > > iptables instead of the TCP stack (i.e. sshd is definitely listening, > > > but iptables is resetting the connection attempt). Finally, one of the > > > "Local NAT" tests is failing (# 158), which is the mode that I believe > > > you are trying to use, correct? > > > > > > To try and get some more detail on the long running iptables commands I > > > have updated the --debug mode in fwknopd to give better output when > > > executing iptables commands in fwknop-1.9.9-pre2: > > > > > > http://www.cipherdyne.org/fwknop/download/fwknop-1.9.9-pre2.tar.gz > > > > > > If it isn't too much trouble, could you put this on the system running > > > fwknopd currently and send me the anonymized test suite output? You > > > don't need to actually install 1.9.9-pre1 - just untar it somewhere and > > > run the test suite. > > > > > > Thanks, > > > > > > -- > > > Michael Rash > > > http://www.cipherdyne.org/ > > > Key fingerprint: E2EF 0C8A 5AA9 654C 4763 B50F 37AC E946 7F51 8271 > > > > > > > Regards > > > > Eggert > > > > > > > > On Samstag 04 Oktober 2008, you wrote: > > > > > (resending this message to the list - seems as though Sourceforge > > > > > may have some mail issues right now) > > > > > > > > > > On Oct 02, 2008, Eggert Ehmke wrote: > > > > > > Hello Michael, > > > > > > > > > > > > occasionaly (every some days of no problems) I cannot log in to > > > > > > my root server and get "Connection refused". In case of these > > > > > > connections, only the two mails are received: > > > > > > xxxx fwknopd: add FWKNOP_PREROUTING xxx.188.31.xxx -> > > > > > > 85.214.47.xxx(tcp/65080 to 22) DNAT rule 20 sec > > > > > > xxxx knoptm: removed iptables FWKNOP_PREROUTING DNAT rule for > > > > > > xxx.188.31.xxx -> 85.214.47.xxx(tcp/22), 20 sec timeout exceeded > > > > > > > > > > > > In the cases when all works fine, I get two additional mails: > > > > > > xxxx fwknopd: add FWKNOP_INPUT xxx.188.49.xxx -> > > > > > > 0.0.0.0/0(tcp/22) ACCEPT rule 20 sec > > > > > > xxxx knoptm: removed iptables FWKNOP_INPUT ACCEPT rule for > > > > > > xxx.188.49.xxx -> 0.0.0.0/0(tcp/22), 20 sec timeout exceeded > > > > > > > > > > > > To restore to the working state, I have to restart the fwknop > > > > > > daemon by /etc/init.d/fwknop restart. I have a terminal server so > > > > > > I can get access to the root server by this means. > > > > > > > > > > Hmm, clearly that needs to be fixed. Thanks for reporting this. > > > > > Are there any additional messages written to syslog by fwknopd? > > > > > There are several places where a syslog message is generated and no > > > > > corresponding email is sent. But, there may not be any log > > > > > messages that particularly help in this situation. > > > > > > > > > > > Currently I run fwknop 1.9.8, but the problem occoured already > > > > > > some releases early. Would be great if we could solve the issue. > > > > > > If you need any debug information or log files, let me know. > > > > > > > > > > Can you run the test suite on the system running fwknopd, and send > > > > > me the anonymized output (-P)? The reason I ask this is that the > > > > > results will collect a lot of system specifics that may be > > > > > important to this this bug (even though the test suite may appear > > > > > to pass all tests). For example, the fact that you are receiving > > > > > "Connection refused" is interesting, because this implies that a > > > > > RST is being sent. Hence, either the daemon itself is not > > > > > available (the port is closed) but there must be an ACCEPT rule to > > > > > reach the port in the first place, or iptables is sending a RST via > > > > > the REJECT target. Running the test suite will collect the > > > > > iptables policy (anonymized) so this will help clarify. > > > > > > > > > > I may need to send you a -pre release of 1.9.9 to help fix this > > > > > problem. > > > > > > > > > > Thanks, > > > > > > > > > > -- > > > > > Michael Rash > > > > > http://www.cipherdyne.org/ > > > > > Key fingerprint: E2EF 0C8A 5AA9 654C 4763 B50F 37AC E946 7F51 8271 > > > > > > > > > > > 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 > > > > > > > > --------------------------------------------------------------------- > > > >---- 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 > > > > > > ----------------------------------------------------------------------- > > >-- 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 > > > > > > ---- ursprüngliche Nachricht Ende ---- > > > > > > ----------------------------------------------------------------------- > > >-- 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 > > > > ------------------------------------------------------------------------- > > 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 > > > > ---- ursprüngliche Nachricht Ende ---- > > > > > > ------------------------------------------------------------------------- > > 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 |
From: Eggert E. <egg...@be...> - 2008-10-08 06:43:34
|
Hello Michael, On Mittwoch 08 Oktober 2008, Michael Rash wrote: > That test suite output was interesting once again. The tests that > failed were because the 20 second alarm timer expired while the > IPTables::ChainMgr module was trying to execute an iptables command. > So, the question becomes whether iptables really is taking that long on > your system in some cases, or if the IPTables::ChainMgr module thinks it > does incorrectly. In the former case, something deeper must be going on > - I noticed that you are running kernel 2.6.18, which is a bit old, > I don't know of a specific bug that would cause this behavior. In the > later case, there could be bug in the signal handling code in the > IPTables::ChainMgr module (potentially). Well, the 2.6.18 is the standard Debian Etch kernel. > The /usr/lib/fwknop directory exists on your system, so at some point I > believe that you installed fwknop via the install.pl script? Ah, yes? How else should I install the package from sources? > Since you > are running Debian, would it be possible for you to remove this > directory and use the Debian packages for the IPTables::ChainMgr and > IPTables::Parse modules that Franck Joncourt created? Will do so. Where do I get them? If posted in the mailing list, I will have a look. > Then, if IPTables::ChainMgr is installed at > /usr/share/perl5/IPTables/ChainMgr.pm, could you apply the patch I have > attached to this email and run the test suite one more time? Right now, there is no directory /usr/share/perl5/IPTables/ChainMgr.pm. Would it be created by the mentioned Debian package? > The patch > changes the SIGCHLD / waitpid strategy to just use system() when > executing iptables. If the test suite passes the tests in this case, > then I will certainly update the module to offer multiple execution > styles for the iptables binary. It is also possible that if iptables > really is "freezing" for some weird reason then the test suite will show > the same results (which would still be useful to know). (You will > probably want to make a backup of the original ChainMgr.pm file before > trying this). That's the one in the fwknop source package, right? Regards Eggert |
From: Franck J. <fra...@dt...> - 2008-10-08 07:47:03
|
[...] >> The /usr/lib/fwknop directory exists on your system, so at some point I >> believe that you installed fwknop via the install.pl script? > > Ah, yes? How else should I install the package from sources? I am waiting for fwknop to reach Sid before adding it to my repository. However, if it can help you, I will upload fwknop for Etch on dthconnex tonight. >> Since you >> are running Debian, would it be possible for you to remove this >> directory and use the Debian packages for the IPTables::ChainMgr and >> IPTables::Parse modules that Franck Joncourt created? > > Will do so. Where do I get them? If posted in the mailing list, I will have a > look. Just add in your sources.list the following lines: [code] deb http://dthrepo.podzone.org/debian/ etch main deb-src http://dthrepo.podzone.org/debian/ etch main [/code] Then: [code] # apt-get update # apt-get install debian-dthconnex-keyring # apt-get install libiptables-chainmgr-perl [/code] You will have both IPTables::Parse and IPTables::ChainMgr installed on your system along with the libnetwork-ipv4addr-perl package. >> Then, if IPTables::ChainMgr is installed at >> /usr/share/perl5/IPTables/ChainMgr.pm, could you apply the patch I have >> attached to this email and run the test suite one more time? > > Right now, there is no directory /usr/share/perl5/IPTables/ChainMgr.pm. Would > it be created by the mentioned Debian package? Yes. >> The patch >> changes the SIGCHLD / waitpid strategy to just use system() when >> executing iptables. If the test suite passes the tests in this case, >> then I will certainly update the module to offer multiple execution >> styles for the iptables binary. It is also possible that if iptables >> really is "freezing" for some weird reason then the test suite will show >> the same results (which would still be useful to know). (You will >> probably want to make a backup of the original ChainMgr.pm file before >> trying this). > > That's the one in the fwknop source package, right? I would say that the one installed on your system. Regards, --- Franck |
From: Eggert E. <egg...@be...> - 2008-10-08 18:43:08
|
On Mittwoch 08 Oktober 2008, Franck Joncourt wrote: > Just add in your sources.list the following lines: > > [code] > deb http://dthrepo.podzone.org/debian/ etch main > deb-src http://dthrepo.podzone.org/debian/ etch main > [/code] I did. When I run apt-get update, I get: W: GPG error: http://dthrepo.podzone.org etch Release: The following signatures couldn't be verified because the public key is not available: NO_PUBKEY 107F5F30888B2140 W: You may want to run apt-get update to correct these problems What can I do to solve this? Regards Eggert |
From: Franck J. <fra...@dt...> - 2008-10-08 19:44:38
Attachments:
signature.asc
|
[...] > W: GPG error: http://dthrepo.podzone.org etch Release: The following > signatures couldn't be verified because the public key is not available: > NO_PUBKEY 107F5F30888B2140 > W: You may want to run apt-get update to correct these problems > > What can I do to solve this? [code] # apt-get update ... # apt-get install debian-dthconnex-keyring Lecture des listes de paquets... Fait Construction de l'arbre des dépendances Lecture des informations d'état... Fait Les NOUVEAUX paquets suivants seront installés : debian-dthconnex-keyring 0 mis à jour, 1 nouvellement installés, 0 à enlever et 162 non mis à jour. Il est nécessaire de prendre 3376o dans les archives. Après cette opération, 53,2ko d'espace disque supplémentaires seront utilisés. ATTENTION : les paquets suivants n'ont pas été authentifiés. debian-dthconnex-keyring Faut-il installer ces paquets sans vérification (o/N) ? o Réception de : 1 http://www.stones.lan etch/main debian-dthconnex-keyring 2008.09.06 [3376B] 3376o réceptionnés en 0s (0o/s) Sélection du paquet debian-dthconnex-keyring précédemment désélectionné. (Lecture de la base de données... 106944 fichiers et répertoires déjà installés.) Dépaquetage de debian-dthconnex-keyring (à partir de .../debian-dthconnex-keyring_2008.09.06_all.deb) ... Paramétrage de debian-dthconnex-keyring (2008.09.06) ... OK [/code] I have just added the package to Etch :)! Regards, -- Franck Joncourt http://debian.org - http://smhteam.info/wiki/ Fingerprint : C10E D1D0 EF70 0A2A CACF 9A3C C490 534E 75C0 89FE |
From: Eggert E. <egg...@be...> - 2008-10-09 06:13:37
Attachments:
fwknop_test(2).tar.gz
|
Hello Franck, thanks, that worked now. After I added some more Debian gnupg packages, it partly worked. Here are the new test results: But there are still things broken, the test is not complete, and fwknop does not work at all now. Regards Eggert On Mittwoch 08 Oktober 2008, Franck Joncourt wrote: > [...] > > > W: GPG error: http://dthrepo.podzone.org etch Release: The following > > signatures couldn't be verified because the public key is not available: > > NO_PUBKEY 107F5F30888B2140 > > W: You may want to run apt-get update to correct these problems > > > > What can I do to solve this? > > [code] > # apt-get update > ... > # apt-get install debian-dthconnex-keyring > Lecture des listes de paquets... Fait > Construction de l'arbre des dépendances > Lecture des informations d'état... Fait > Les NOUVEAUX paquets suivants seront installés : > debian-dthconnex-keyring > 0 mis à jour, 1 nouvellement installés, 0 à enlever et 162 non mis à jour. > Il est nécessaire de prendre 3376o dans les archives. > Après cette opération, 53,2ko d'espace disque supplémentaires seront > utilisés. > ATTENTION : les paquets suivants n'ont pas été authentifiés. > debian-dthconnex-keyring > Faut-il installer ces paquets sans vérification (o/N) ? o > Réception de : 1 http://www.stones.lan etch/main > debian-dthconnex-keyring 2008.09.06 [3376B] > 3376o réceptionnés en 0s (0o/s) > Sélection du paquet debian-dthconnex-keyring précédemment désélectionné. > (Lecture de la base de données... 106944 fichiers et répertoires déjà > installés.) > Dépaquetage de debian-dthconnex-keyring (à partir de > .../debian-dthconnex-keyring_2008.09.06_all.deb) ... > Paramétrage de debian-dthconnex-keyring (2008.09.06) ... > OK > [/code] > > I have just added the package to Etch :)! > > Regards, |
From: Michael R. <mb...@ci...> - 2008-10-09 12:27:11
|
On Oct 09, 2008, Eggert Ehmke wrote: > Hello Franck, > > thanks, that worked now. After I added some more Debian gnupg packages, it > partly worked. Here are the new test results: > > But there are still things broken, the test is not complete, and fwknop does > not work at all now. I will send a new pre release of fwknop out this evening, and also a new version (0.8) of the IPTables::ChainMgr module. In the module, I've implemented the configurable ability to use any of three execution strategies for iptables commands: waitpid(), system(), or popen(). There is a new variable in the fwknop.conf file that can be used to select the execution strategy in the module. Also, the timeout for the waitpid() execution style can be configured via another new variable. I've also updated the test suite to collect a process listing for any iptables processes if the 20 second alarm expires if fwknopd takes longer than it should. Between these new updates, it should be possible to get a better sense of what is happening as far as iptables commands are concerned. Before this evening, if you revert that patch then things should return to normal I believe... Thanks, -- Michael Rash http://www.cipherdyne.org/ Key fingerprint: E2EF 0C8A 5AA9 654C 4763 B50F 37AC E946 7F51 8271 > > Regards > Eggert > > On Mittwoch 08 Oktober 2008, Franck Joncourt wrote: > > [...] > > > > > W: GPG error: http://dthrepo.podzone.org etch Release: The following > > > signatures couldn't be verified because the public key is not available: > > > NO_PUBKEY 107F5F30888B2140 > > > W: You may want to run apt-get update to correct these problems > > > > > > What can I do to solve this? > > > > [code] > > # apt-get update > > ... > > # apt-get install debian-dthconnex-keyring > > Lecture des listes de paquets... Fait > > Construction de l'arbre des dépendances > > Lecture des informations d'état... Fait > > Les NOUVEAUX paquets suivants seront installés : > > debian-dthconnex-keyring > > 0 mis à jour, 1 nouvellement installés, 0 à enlever et 162 non mis à jour. > > Il est nécessaire de prendre 3376o dans les archives. > > Après cette opération, 53,2ko d'espace disque supplémentaires seront > > utilisés. > > ATTENTION : les paquets suivants n'ont pas été authentifiés. > > debian-dthconnex-keyring > > Faut-il installer ces paquets sans vérification (o/N) ? o > > Réception de : 1 http://www.stones.lan etch/main > > debian-dthconnex-keyring 2008.09.06 [3376B] > > 3376o réceptionnés en 0s (0o/s) > > Sélection du paquet debian-dthconnex-keyring précédemment désélectionné. > > (Lecture de la base de données... 106944 fichiers et répertoires déjà > > installés.) > > Dépaquetage de debian-dthconnex-keyring (à partir de > > .../debian-dthconnex-keyring_2008.09.06_all.deb) ... > > Paramétrage de debian-dthconnex-keyring (2008.09.06) ... > > OK > > [/code] > > > > I have just added the package to Etch :)! > > > > Regards, > > > ------------------------------------------------------------------------- > 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 |
From: Eggert E. <egg...@be...> - 2008-10-09 20:48:04
Attachments:
fwknop_test1.tar.gz
fwknop_test2.tar.gz
|
Hello Michael, I installed some more Debian packages, (crypt perl module) and now at least all tests run again. But this means that Francks debian packages miss important dependencies, otherwise these additional debian packages would have been installed automatically. I restored to the state where Francks package was installed, and run the test suite. Then i applied your patch again and run the test suite again. Both results are attached, hope the mail is not too large. The tests seem to be successful, but the problem still remains: my login attempts are rejected: ssh: connect to host xxxxx port 47280: Connection refused Regards Eggert On Donnerstag 09 Oktober 2008, Michael Rash wrote: > On Oct 09, 2008, Eggert Ehmke wrote: > > Hello Franck, > > > > thanks, that worked now. After I added some more Debian gnupg packages, > > it partly worked. Here are the new test results: > > > > But there are still things broken, the test is not complete, and fwknop > > does not work at all now. > > I will send a new pre release of fwknop out this evening, and also a new > version (0.8) of the IPTables::ChainMgr module. > > In the module, I've implemented the configurable ability to use any of > three execution strategies for iptables commands: waitpid(), system(), > or popen(). There is a new variable in the fwknop.conf file that can be > used to select the execution strategy in the module. Also, the timeout > for the waitpid() execution style can be configured via another new > variable. > > I've also updated the test suite to collect a process listing for any > iptables processes if the 20 second alarm expires if fwknopd takes > longer than it should. > > Between these new updates, it should be possible to get a better sense > of what is happening as far as iptables commands are concerned. > > Before this evening, if you revert that patch then things should return > to normal I believe... > > Thanks, > > -- > Michael Rash > http://www.cipherdyne.org/ > Key fingerprint: E2EF 0C8A 5AA9 654C 4763 B50F 37AC E946 7F51 8271 > > > Regards > > Eggert |
From: Franck J. <fra...@dt...> - 2008-10-14 15:08:09
|
Eggert Ehmke a écrit : [...] > I installed some more Debian packages, (crypt perl module) and now at least > all tests run again. But this means that Francks debian packages miss > important dependencies, otherwise these additional debian packages would have > been installed automatically. How do you install fwknop ? I have not released fwknop for Etch, so I suppose you rebuilt the package, and installed it with something like dpkg -i (it should have warned you about missing dependencies). Here is the list of dependencies for fwknop: Package: fwknop-server Architecture: any Depends: ${shlibs:Depends}, ${perl:Depends}, ${misc:Depends}, iptables, libunix-syslog-perl, libnet-rawip-perl, libnet-pcap-perl (>= 0.04-3), libgnupg-interface-perl, libdigest-sha-perl, libcrypt-rijndael-perl, libcrypt-cbc-perl, libterm-readkey-perl, libnetwork-ipv4addr-perl, libiptables-parse-perl, libiptables-chainmgr-perl, mailutils | bsd-mailx Package: fwknop-client Architecture: all Depends: ${perl:Depends}, libnet-rawip-perl, libgnupg-interface-perl, libdigest-sha-perl, libcrypt-rijndael-perl, libcrypt-cbc-perl, libterm-readkey-perl, libnet-ping-external-perl Which dependencies are missing ? --- Franck |
From: Franck J. <fra...@dt...> - 2008-10-14 23:00:37
Attachments:
signature.asc
|
Hi, [...] > I installed some more Debian packages, (crypt perl module) and now at least > all tests run again. But this means that Francks debian packages miss > important dependencies, otherwise these additional debian packages would have > been installed automatically. Already replied. I will package the new pre-release for fwknop and add it to the Dthconnex repository. You did not ask last time. > I restored to the state where Francks package was installed, and run the test > suite. Then i applied your patch again and run the test suite again. Both > results are attached, hope the mail is not too large. On Debian Sid, running the 1.9.9-pre2 release, the test suite runs fine. Adding the previous patch to the ChainMgr.pm file, it fails on test 13 - "Deleting all fwknopd iptables chains". > The tests seem to be successful, but the problem still remains: my login > attempts are rejected: > ssh: connect to host xxxxx port 47280: Connection refused I have tried to slow down iptables by adding a large number of rules: [code] iptables -L -v -n | wc -l 12997 [/code] Twice the test suite run fine. However I have been able to get the following message in debug mode [quote] [-] add_ip_rule() returned 0 Wed Oct 15 00:45:57 2008 iptables: Resource temporarily unavailable [/quote] I need to do more tests quietly since I am a bit lost with all I have tried. > I do think there are some > members on this list that have limited bandwidth, so I think it would > probably be better to send the test suite results to me in separate > emails, but keep the discussion of the results here on the list. If > people are interested in seeing the test suite results I could post them > on cipherdyne.org. What do people think about this? That would be interesting to have them available. > I've made some progress toward the next -pre release. See the following > link for example: > > http://trac.cipherdyne.org/trac/fwknop/changeset/1301 Nice. > I expect to finish the next pre release by tomorrow evening. This one > will include updated IPTables::ChainMgr and IPTables::Parse modules that > allow delays between iptables commands to be configurable, and also > offer all three of waitpid(), popen(), and system() styles of execution. > The test suite has been updated (per the commit above) to add tests for > each of these methods for executing iptables, and it also now collects > any running fwknop or iptables processes if the fwknopd alarm expires. > This should provide a better window for viewing what is going on with > your system. I may also need to try and replicate your environment by > running Debian under VMware with a similar set of installed packages, > but I'm hoping we can solve this issue without attempting this since > it's hard to replicate things correctly. If that could help you, I use a chroot for Etch to build the packages, and both the git and the debian repository are available to help debugging. Regards, -- Franck Joncourt http://debian.org - http://smhteam.info/wiki/ Fingerprint : C10E D1D0 EF70 0A2A CACF 9A3C C490 534E 75C0 89FE |
From: Michael R. <mb...@ci...> - 2008-10-14 12:08:32
|
On Oct 09, 2008, Eggert Ehmke wrote: > Hello Michael, Hi Eggert - Sorry for the delay. I've been out of town. > I installed some more Debian packages, (crypt perl module) and now at least > all tests run again. But this means that Francks debian packages miss > important dependencies, otherwise these additional debian packages would have > been installed automatically. > > I restored to the state where Francks package was installed, and run the test > suite. Then i applied your patch again and run the test suite again. Both > results are attached, hope the mail is not too large. Thanks for sending the test suite results. I do think there are some members on this list that have limited bandwidth, so I think it would probably be better to send the test suite results to me in separate emails, but keep the discussion of the results here on the list. If people are interested in seeing the test suite results I could post them on cipherdyne.org. What do people think about this? > The tests seem to be successful, but the problem still remains: my login > attempts are rejected: > ssh: connect to host xxxxx port 47280: Connection refused I've made some progress toward the next -pre release. See the following link for example: http://trac.cipherdyne.org/trac/fwknop/changeset/1301 I expect to finish the next pre release by tomorrow evening. This one will include updated IPTables::ChainMgr and IPTables::Parse modules that allow delays between iptables commands to be configurable, and also offer all three of waitpid(), popen(), and system() styles of execution. The test suite has been updated (per the commit above) to add tests for each of these methods for executing iptables, and it also now collects any running fwknop or iptables processes if the fwknopd alarm expires. This should provide a better window for viewing what is going on with your system. I may also need to try and replicate your environment by running Debian under VMware with a similar set of installed packages, but I'm hoping we can solve this issue without attempting this since it's hard to replicate things correctly. Thanks, -- Michael Rash http://www.cipherdyne.org/ Key fingerprint: E2EF 0C8A 5AA9 654C 4763 B50F 37AC E946 7F51 8271 > > Regards > Eggert > > On Donnerstag 09 Oktober 2008, Michael Rash wrote: > > On Oct 09, 2008, Eggert Ehmke wrote: > > > Hello Franck, > > > > > > thanks, that worked now. After I added some more Debian gnupg packages, > > > it partly worked. Here are the new test results: > > > > > > But there are still things broken, the test is not complete, and fwknop > > > does not work at all now. > > > > I will send a new pre release of fwknop out this evening, and also a new > > version (0.8) of the IPTables::ChainMgr module. > > > > In the module, I've implemented the configurable ability to use any of > > three execution strategies for iptables commands: waitpid(), system(), > > or popen(). There is a new variable in the fwknop.conf file that can be > > used to select the execution strategy in the module. Also, the timeout > > for the waitpid() execution style can be configured via another new > > variable. > > > > I've also updated the test suite to collect a process listing for any > > iptables processes if the 20 second alarm expires if fwknopd takes > > longer than it should. > > > > Between these new updates, it should be possible to get a better sense > > of what is happening as far as iptables commands are concerned. > > > > Before this evening, if you revert that patch then things should return > > to normal I believe... > > > > Thanks, > > > > -- > > Michael Rash > > http://www.cipherdyne.org/ > > Key fingerprint: E2EF 0C8A 5AA9 654C 4763 B50F 37AC E946 7F51 8271 > > > > > 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 |
From: Michael R. <mb...@ci...> - 2008-10-18 05:14:00
|
On Oct 09, 2008, Eggert Ehmke wrote: Hi Eggert - [...] > The tests seem to be successful, but the problem still remains: my login > attempts are rejected: > ssh: connect to host xxxxx port 47280: Connection refused My previous email to the list provided a link to 1.9.9-pre3, and I'm hoping this release may help to shed some light on the situation. At least, there are now several knobs that can be turned to influence fwknopd operations that weren't available before, and there is also a better way of handling forked processes in the latest IPTables::ChainMgr module (0.8). So, if you have a few spare cycles, do you think you could execute the test suite one more time, and send the results to me (privately)? We can keep the discussion on the list, and I would be happy to post the test results (with your permission) on cipherdyne.org. Here are a few things to note: - This latest -pre3 release takes advantage of new functionality in the most recent versions of the IPTables::ChainMgr and IPTables::Parse (0.8 and 0.7 respectively). So, I believe that Franck will be able to make Debian packages of these new modules, and you can upgrade them once these packages are available. Or, in the meantime, you could also download them and copy the ChainMgr.pm and Parse.pm files to /usr/share/perl5/IPTables/ - If the latest version of IPTables::ChainMgr is installed, then the test suite will automatically enable a series of tests for this version. - What I'm hoping is that the test suite will either 1) fix errors that were seen in previous runs on your system (this is possible with the updated way of handling forked processes from within IPTables::ChainMgr I think), or 2) provide the ability to use a combination of the following newly added config variables to help narrow down what the problem is: IPT_CMD_ALARM - To configure the amount of time IPTables::ChainMgr spends waiting for iptables to come back in waitpid() mode. IPT_EXEC_STYLE - To control the execution model IPTables::ChainMgr (and also IPTables::Parse) use to interact with iptables. This variable can be set to waitpid(), system(), or popen(), and the default is waitpid(). IPT_EXEC_SLEEP - To allow a time delay to be introduced for every iptables command executed by either IPTables::ChainMgr or IPTables::Parse. IPT_EXEC_TRIES - To allow certain iptables commands to be re-tried if there are errors. If the test suite still has errors on a particular series of tests, you can use the --include argument to run just that set of tests. E.g. the following to run just the "Setup" tests: # ./fwknop_test.pl --include Setup If you want to just run the new IPTables::ChainMgr tests, you will need to specify the IPTables::ChainMgr version explicitly on the command line like so: # ./fwknop_test.pl --include IPTables --IPTables 8 This is only necessary when restricting the test suite to run the IPTables::ChainMgr tests - otherwise it detects the version through previous executions of fwknopd. Please let me know if you have any questions. Thanks, -- Michael Rash http://www.cipherdyne.org/ Key fingerprint: E2EF 0C8A 5AA9 654C 4763 B50F 37AC E946 7F51 8271 > > Regards > Eggert > > On Donnerstag 09 Oktober 2008, Michael Rash wrote: > > On Oct 09, 2008, Eggert Ehmke wrote: > > > Hello Franck, > > > > > > thanks, that worked now. After I added some more Debian gnupg packages, > > > it partly worked. Here are the new test results: > > > > > > But there are still things broken, the test is not complete, and fwknop > > > does not work at all now. > > > > I will send a new pre release of fwknop out this evening, and also a new > > version (0.8) of the IPTables::ChainMgr module. > > > > In the module, I've implemented the configurable ability to use any of > > three execution strategies for iptables commands: waitpid(), system(), > > or popen(). There is a new variable in the fwknop.conf file that can be > > used to select the execution strategy in the module. Also, the timeout > > for the waitpid() execution style can be configured via another new > > variable. > > > > I've also updated the test suite to collect a process listing for any > > iptables processes if the 20 second alarm expires if fwknopd takes > > longer than it should. > > > > Between these new updates, it should be possible to get a better sense > > of what is happening as far as iptables commands are concerned. > > > > Before this evening, if you revert that patch then things should return > > to normal I believe... > > > > Thanks, > > > > -- > > Michael Rash > > http://www.cipherdyne.org/ > > Key fingerprint: E2EF 0C8A 5AA9 654C 4763 B50F 37AC E946 7F51 8271 > > > > > 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 |
From: Michael R. <mb...@ci...> - 2008-10-19 00:19:09
|
On Oct 18, 2008, Eggert Ehmke wrote: > Hello Michael, Hi Eggert - > ok, here we go. > > On Samstag 18 Oktober 2008, Michael Rash wrote: > > My previous email to the list provided a link to 1.9.9-pre3, and I'm > > hoping this release may help to shed some light on the situation. At > > least, there are now several knobs that can be turned to influence > > fwknopd operations that weren't available before, and there is also a > > better way of handling forked processes in the latest IPTables::ChainMgr > > module (0.8). > > > > So, if you have a few spare cycles, do you think you could execute the > > test suite one more time, and send the results to me (privately)? We > > can keep the discussion on the list, and I would be happy to post the > > test results (with your permission) on cipherdyne.org. > > Here are my actual test results. It seems to run through without errors. But > even with the last prerelease the access to my server is fine. Ah, excellent. So the problem seems to be fixed then? I saw the test suite results, and they are pefect. Please let me know if you see any other issues. > Normally, I install the package via source and not via Debian packages. Understood. Thanks, --Mike > Regards > Eggert > > > Here are a few things to note: > > > > - This latest -pre3 release takes advantage of new functionality in the > > most recent versions of the IPTables::ChainMgr and IPTables::Parse > > (0.8 and 0.7 respectively). So, I believe that Franck will be able to > > make Debian packages of these new modules, and you can upgrade them > > once these packages are available. Or, in the meantime, you could > > also download them and copy the ChainMgr.pm and Parse.pm files to > > /usr/share/perl5/IPTables/ > > > > - If the latest version of IPTables::ChainMgr is installed, then the > > test suite will automatically enable a series of tests for this > > version. > > > > - What I'm hoping is that the test suite will either 1) fix errors that > > were seen in previous runs on your system (this is possible with the > > updated way of handling forked processes from within IPTables::ChainMgr > > I think), or 2) provide the ability to use a combination of the > > following newly added config variables to help narrow down what the > > problem is: > > > > IPT_CMD_ALARM - To configure the amount of time IPTables::ChainMgr > > spends waiting for iptables to come back in waitpid() > > mode. > > IPT_EXEC_STYLE - To control the execution model IPTables::ChainMgr (and > > also IPTables::Parse) use to interact with iptables. > > This variable can be set to waitpid(), system(), or > > popen(), and the default is waitpid(). > > IPT_EXEC_SLEEP - To allow a time delay to be introduced for every > > iptables command executed by either IPTables::ChainMgr > > or IPTables::Parse. > > IPT_EXEC_TRIES - To allow certain iptables commands to be re-tried if > > there are errors. > > > > If the test suite still has errors on a particular series of tests, you > > can use the --include argument to run just that set of tests. E.g. the > > following to run just the "Setup" tests: > > > > # ./fwknop_test.pl --include Setup > > > > If you want to just run the new IPTables::ChainMgr tests, you will need > > to specify the IPTables::ChainMgr version explicitly on the command line > > like so: > > > > # ./fwknop_test.pl --include IPTables --IPTables 8 > > > > This is only necessary when restricting the test suite to run the > > IPTables::ChainMgr tests - otherwise it detects the version through > > previous executions of fwknopd. > > > > Please let me know if you have any questions. > > > > Thanks, > > > > -- > > Michael Rash > > http://www.cipherdyne.org/ > > Key fingerprint: E2EF 0C8A 5AA9 654C 4763 B50F 37AC E946 7F51 8271 > > > > > Regards > > > Eggert > > > > > > On Donnerstag 09 Oktober 2008, Michael Rash wrote: > > > > On Oct 09, 2008, Eggert Ehmke wrote: > > > > > Hello Franck, > > > > > > > > > > thanks, that worked now. After I added some more Debian gnupg > > > > > packages, it partly worked. Here are the new test results: > > > > > > > > > > But there are still things broken, the test is not complete, and > > > > > fwknop does not work at all now. > > > > > > > > I will send a new pre release of fwknop out this evening, and also a > > > > new version (0.8) of the IPTables::ChainMgr module. > > > > > > > > In the module, I've implemented the configurable ability to use any of > > > > three execution strategies for iptables commands: waitpid(), system(), > > > > or popen(). There is a new variable in the fwknop.conf file that can > > > > be used to select the execution strategy in the module. Also, the > > > > timeout for the waitpid() execution style can be configured via another > > > > new variable. > > > > > > > > I've also updated the test suite to collect a process listing for any > > > > iptables processes if the 20 second alarm expires if fwknopd takes > > > > longer than it should. > > > > > > > > Between these new updates, it should be possible to get a better sense > > > > of what is happening as far as iptables commands are concerned. > > > > > > > > Before this evening, if you revert that patch then things should return > > > > to normal I believe... > > > > > > > > Thanks, > > > > > > > > -- > > > > Michael Rash > > > > http://www.cipherdyne.org/ > > > > Key fingerprint: E2EF 0C8A 5AA9 654C 4763 B50F 37AC E946 7F51 8271 > > > > > > > > > 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 > > > > ------------------------------------------------------------------------- > > 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 > > |
From: Ehmke E. <egg...@be...> - 2008-10-24 07:50:56
|
Hello Michael, indeed the problem seems to be solved. I did not have the fault again since, all my logins were successful so far. Thanks a lot for your help. 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. Kind Regards Eggert ----- ursprüngliche Nachricht --------- On Oct 18, 2008, Eggert Ehmke wrote: > Hello Michael, Hi Eggert - > ok, here we go. > > On Samstag 18 Oktober 2008, Michael Rash wrote: > > My previous email to the list provided a link to 1.9.9-pre3, and I'm > > hoping this release may help to shed some light on the situation. At > > least, there are now several knobs that can be turned to influence > > fwknopd operations that weren't available before, and there is also a > > better way of handling forked processes in the latest IPTables::ChainMgr > > module (0.8). > > > > So, if you have a few spare cycles, do you think you could execute the > > test suite one more time, and send the results to me (privately)? We > > can keep the discussion on the list, and I would be happy to post the > > test results (with your permission) on cipherdyne.org. > > Here are my actual test results. It seems to run through without errors. But > even with the last prerelease the access to my server is fine. Ah, excellent. So the problem seems to be fixed then? I saw the test suite results, and they are pefect. Please let me know if you see any other issues. > Normally, I install the package via source and not via Debian packages. Understood. Thanks, --Mike > Regards > Eggert > > > Here are a few things to note: > > > > - This latest -pre3 release takes advantage of new functionality in the > > most recent versions of the IPTables::ChainMgr and IPTables::Parse > > (0.8 and 0.7 respectively). So, I believe that Franck will be able to > > make Debian packages of these new modules, and you can upgrade them > > once these packages are available. Or, in the meantime, you could > > also download them and copy the ChainMgr.pm and Parse.pm files to > > /usr/share/perl5/IPTables/ > > > > - If the latest version of IPTables::ChainMgr is installed, then the > > test suite will automatically enable a series of tests for this > > version. > > > > - What I'm hoping is that the test suite will either 1) fix errors that > > were seen in previous runs on your system (this is possible with the > > updated way of handling forked processes from within IPTables::ChainMgr > > I think), or 2) provide the ability to use a combination of the > > following newly added config variables to help narrow down what the > > problem is: > > > > IPT_CMD_ALARM - To configure the amount of time IPTables::ChainMgr > > spends waiting for iptables to come back in waitpid() > > mode. > > IPT_EXEC_STYLE - To control the execution model IPTables::ChainMgr (and > > also IPTables::Parse) use to interact with iptables. > > This variable can be set to waitpid(), system(), or > > popen(), and the default is waitpid(). > > IPT_EXEC_SLEEP - To allow a time delay to be introduced for every > > iptables command executed by either IPTables::ChainMgr > > or IPTables::Parse. > > IPT_EXEC_TRIES - To allow certain iptables commands to be re-tried if > > there are errors. > > > > If the test suite still has errors on a particular series of tests, you > > can use the --include argument to run just that set of tests. E.g. the > > following to run just the "Setup" tests: > > > > # ./fwknop_test.pl --include Setup > > > > If you want to just run the new IPTables::ChainMgr tests, you will need > > to specify the IPTables::ChainMgr version explicitly on the command line > > like so: > > > > # ./fwknop_test.pl --include IPTables --IPTables 8 > > > > This is only necessary when restricting the test suite to run the > > IPTables::ChainMgr tests - otherwise it detects the version through > > previous executions of fwknopd. > > > > Please let me know if you have any questions. > > > > Thanks, > > > > -- > > Michael Rash > > http://www.cipherdyne.org/ > > Key fingerprint: E2EF 0C8A 5AA9 654C 4763 B50F 37AC E946 7F51 8271 > > > > > Regards > > > Eggert > > > > > > On Donnerstag 09 Oktober 2008, Michael Rash wrote: > > > > On Oct 09, 2008, Eggert Ehmke wrote: > > > > > Hello Franck, > > > > > > > > > > thanks, that worked now. After I added some more Debian gnupg > > > > > packages, it partly worked. Here are the new test results: > > > > > > > > > > But there are still things broken, the test is not complete, and > > > > > fwknop does not work at all now. > > > > > > > > I will send a new pre release of fwknop out this evening, and also a > > > > new version (0.8) of the IPTables::ChainMgr module. > > > > > > > > In the module, I've implemented the configurable ability to use any of > > > > three execution strategies for iptables commands: waitpid(), system(), > > > > or popen(). There is a new variable in the fwknop.conf file that can > > > > be used to select the execution strategy in the module. Also, the > > > > timeout for the waitpid() execution style can be configured via another > > > > new variable. > > > > > > > > I've also updated the test suite to collect a process listing for any > > > > iptables processes if the 20 second alarm expires if fwknopd takes > > > > longer than it should. > > > > > > > > Between these new updates, it should be possible to get a better sense > > > > of what is happening as far as iptables commands are concerned. > > > > > > > > Before this evening, if you revert that patch then things should return > > > > to normal I believe... > > > > > > > > Thanks, > > > > > > > > -- > > > > Michael Rash > > > > http://www.cipherdyne.org/ > > > > Key fingerprint: E2EF 0C8A 5AA9 654C 4763 B50F 37AC E946 7F51 8271 > > > > > > > > > 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 > > > > ------------------------------------------------------------------------- > > 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 > > ------------------------------------------------------------------------- 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 ---- ursprüngliche Nachricht Ende ---- |
From: Michael R. <mb...@ci...> - 2008-10-24 12:23:09
|
On Oct 24, 2008, Ehmke Eggert wrote: > Hello Michael, Hi Eggert - > indeed the problem seems to be solved. I did not have the fault again since, all my logins were successful so far. Thanks a lot for your help. 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. Were there any other updates on your system? Such as an upgraded kernel and/or iptables itself? Thanks, -- Michael Rash http://www.cipherdyne.org/ Key fingerprint: E2EF 0C8A 5AA9 654C 4763 B50F 37AC E946 7F51 8271 > > Kind Regards > Eggert > > > > > > ----- ursprüngliche Nachricht --------- > > On Oct 18, 2008, Eggert Ehmke wrote: > > > Hello Michael, > > Hi Eggert - > > > ok, here we go. > > > > On Samstag 18 Oktober 2008, Michael Rash wrote: > > > My previous email to the list provided a link to 1.9.9-pre3, and I'm > > > hoping this release may help to shed some light on the situation. At > > > least, there are now several knobs that can be turned to influence > > > fwknopd operations that weren't available before, and there is also a > > > better way of handling forked processes in the latest IPTables::ChainMgr > > > module (0.8). > > > > > > So, if you have a few spare cycles, do you think you could execute the > > > test suite one more time, and send the results to me (privately)? We > > > can keep the discussion on the list, and I would be happy to post the > > > test results (with your permission) on cipherdyne.org. > > > > Here are my actual test results. It seems to run through without errors. But > > even with the last prerelease the access to my server is fine. > > Ah, excellent. So the problem seems to be fixed then? I saw the test > suite results, and they are pefect. Please let me know if you see any > other issues. > > > Normally, I install the package via source and not via Debian packages. > > Understood. > > Thanks, > > --Mike > > > > Regards > > Eggert > > > > > Here are a few things to note: > > > > > > - This latest -pre3 release takes advantage of new functionality in the > > > most recent versions of the IPTables::ChainMgr and IPTables::Parse > > > (0.8 and 0.7 respectively). So, I believe that Franck will be able to > > > make Debian packages of these new modules, and you can upgrade them > > > once these packages are available. Or, in the meantime, you could > > > also download them and copy the ChainMgr.pm and Parse.pm files to > > > /usr/share/perl5/IPTables/ > > > > > > - If the latest version of IPTables::ChainMgr is installed, then the > > > test suite will automatically enable a series of tests for this > > > version. > > > > > > - What I'm hoping is that the test suite will either 1) fix errors that > > > were seen in previous runs on your system (this is possible with the > > > updated way of handling forked processes from within IPTables::ChainMgr > > > I think), or 2) provide the ability to use a combination of the > > > following newly added config variables to help narrow down what the > > > problem is: > > > > > > IPT_CMD_ALARM - To configure the amount of time IPTables::ChainMgr > > > spends waiting for iptables to come back in waitpid() > > > mode. > > > IPT_EXEC_STYLE - To control the execution model IPTables::ChainMgr (and > > > also IPTables::Parse) use to interact with iptables. > > > This variable can be set to waitpid(), system(), or > > > popen(), and the default is waitpid(). > > > IPT_EXEC_SLEEP - To allow a time delay to be introduced for every > > > iptables command executed by either IPTables::ChainMgr > > > or IPTables::Parse. > > > IPT_EXEC_TRIES - To allow certain iptables commands to be re-tried if > > > there are errors. > > > > > > If the test suite still has errors on a particular series of tests, you > > > can use the --include argument to run just that set of tests. E.g. the > > > following to run just the "Setup" tests: > > > > > > # ./fwknop_test.pl --include Setup > > > > > > If you want to just run the new IPTables::ChainMgr tests, you will need > > > to specify the IPTables::ChainMgr version explicitly on the command line > > > like so: > > > > > > # ./fwknop_test.pl --include IPTables --IPTables 8 > > > > > > This is only necessary when restricting the test suite to run the > > > IPTables::ChainMgr tests - otherwise it detects the version through > > > previous executions of fwknopd. > > > > > > Please let me know if you have any questions. > > > > > > Thanks, > > > > > > -- > > > Michael Rash > > > http://www.cipherdyne.org/ > > > Key fingerprint: E2EF 0C8A 5AA9 654C 4763 B50F 37AC E946 7F51 8271 > > > > > > > Regards > > > > Eggert > > > > > > > > On Donnerstag 09 Oktober 2008, Michael Rash wrote: > > > > > On Oct 09, 2008, Eggert Ehmke wrote: > > > > > > Hello Franck, > > > > > > > > > > > > thanks, that worked now. After I added some more Debian gnupg > > > > > > packages, it partly worked. Here are the new test results: > > > > > > > > > > > > But there are still things broken, the test is not complete, and > > > > > > fwknop does not work at all now. > > > > > > > > > > I will send a new pre release of fwknop out this evening, and also a > > > > > new version (0.8) of the IPTables::ChainMgr module. > > > > > > > > > > In the module, I've implemented the configurable ability to use any of > > > > > three execution strategies for iptables commands: waitpid(), system(), > > > > > or popen(). There is a new variable in the fwknop.conf file that can > > > > > be used to select the execution strategy in the module. Also, the > > > > > timeout for the waitpid() execution style can be configured via another > > > > > new variable. > > > > > > > > > > I've also updated the test suite to collect a process listing for any > > > > > iptables processes if the 20 second alarm expires if fwknopd takes > > > > > longer than it should. > > > > > > > > > > Between these new updates, it should be possible to get a better sense > > > > > of what is happening as far as iptables commands are concerned. > > > > > > > > > > Before this evening, if you revert that patch then things should return > > > > > to normal I believe... > > > > > > > > > > Thanks, > > > > > > > > > > -- > > > > > Michael Rash > > > > > http://www.cipherdyne.org/ > > > > > Key fingerprint: E2EF 0C8A 5AA9 654C 4763 B50F 37AC E946 7F51 8271 > > > > > > > > > > > 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 > > > > > > ------------------------------------------------------------------------- > > > 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 > > > > > > > > ------------------------------------------------------------------------- > 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 > > ---- ursprüngliche Nachricht Ende ---- > > ------------------------------------------------------------------------- > 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 |
From: Eggert E. <egg...@be...> - 2008-10-25 16:51:27
|
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. Regards Eggert |
From: Michael R. <mb...@ci...> - 2008-10-25 17:36:03
|
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 |
From: Michael R. <mb...@ci...> - 2008-10-06 12:56:19
|
On Oct 06, 2008, Ehmke Eggert wrote: > Hi Michael, > > thanks for your detailed analysis. I will run the new test suite tonight, when I have access to the system again. This time I will disable the monit daemon for the test, agree? Yes, disabling the monit daemon while the test suite runs would be best. Thanks, --Mike > Regards > Eggert > > > > > > ----- ursprüngliche Nachricht --------- > > On Oct 04, 2008, Eggert Ehmke wrote: > > > Hello Michael, > > Hi Eggert - > > > attached you find the file generated by the test suite. I followed these steps > > to create it: > > > > -Opened ssh session on root server (fwknop was working) > > -stopped fwknop daemon > > -changed to test subdirectory of fwknop source > > -run "sudo ./fwknop_test.pl" > > -run "sudo ./fwknop_test.pl --Prepare-results" > > -transfered the generated tar.gz file to my home system and attached it to > > this mail > > -restarted the fwknop daemon on the root server, but was already running > > because of my monit daemon. > > > > Now that I look into the 175.test file, there are a lot of errors from the > > monit daemon, that is used to keep important processes running, including > > fwknopd. I have this in my /etc/monit/monit.d/fwknop file: > > > > check process fwknopd with pidfile /var/run/fwknop/knopwatchd.pid > > start program = "/etc/init.d/fwknop start" > > stop program = "/etc/init.d/fwknop stop" > > group server > > > > Maybe there is an interference? > > Yes, having monit start fwknop while the test suite is running might > produce unexpected results because the fwknopd daemon normally flushes > any existing firewall (iptables or ipfw) rules at init time. The test > suite is careful to only apply firewall rules to the loopback interface, > so it shouldn't interfere with remote communication with your system. > So, it should be safe to run the test suite with the installed fwknop > software not running - you could also add a temporary ACCEPT rule for > your session if you would like to be completely sure. > > I've looked through the test suite output that you sent, and it does > contain some interesting bits of information. First, for each test that > failed, the test ends with the test suite catch-all alarm after > attempting to execute an iptables command. It's almost as though > executing iptables becomes extremely slow (on the order of 20 seconds) > to return. Second, it looks like the default stance in your iptables > policy for incoming connections to tcp/22 is to use the REJECT target in > the absence of an ACCEPT rule created by fwknop. So, that would imply > that the "Connection refused" messages really are coming from iptables > instead of the TCP stack (i.e. sshd is definitely listening, but > iptables is resetting the connection attempt). Finally, one of the > "Local NAT" tests is failing (# 158), which is the mode that I believe > you are trying to use, correct? > > To try and get some more detail on the long running iptables commands I > have updated the --debug mode in fwknopd to give better output when > executing iptables commands in fwknop-1.9.9-pre2: > > http://www.cipherdyne.org/fwknop/download/fwknop-1.9.9-pre2.tar.gz > > If it isn't too much trouble, could you put this on the system running > fwknopd currently and send me the anonymized test suite output? You don't > need to actually install 1.9.9-pre1 - just untar it somewhere and run the > test suite. > > Thanks, > > -- > Michael Rash > http://www.cipherdyne.org/ > Key fingerprint: E2EF 0C8A 5AA9 654C 4763 B50F 37AC E946 7F51 8271 > > > > > > > Regards > > Eggert > > > > On Samstag 04 Oktober 2008, you wrote: > > > (resending this message to the list - seems as though Sourceforge may > > > have some mail issues right now) > > > > > > On Oct 02, 2008, Eggert Ehmke wrote: > > > > Hello Michael, > > > > > > > > occasionaly (every some days of no problems) I cannot log in to my root > > > > server and get "Connection refused". In case of these connections, only > > > > the two mails are received: > > > > xxxx fwknopd: add FWKNOP_PREROUTING xxx.188.31.xxx -> > > > > 85.214.47.xxx(tcp/65080 to 22) DNAT rule 20 sec > > > > xxxx knoptm: removed iptables FWKNOP_PREROUTING DNAT rule for > > > > xxx.188.31.xxx -> 85.214.47.xxx(tcp/22), 20 sec timeout exceeded > > > > > > > > In the cases when all works fine, I get two additional mails: > > > > xxxx fwknopd: add FWKNOP_INPUT xxx.188.49.xxx -> 0.0.0.0/0(tcp/22) ACCEPT > > > > rule 20 sec > > > > xxxx knoptm: removed iptables FWKNOP_INPUT ACCEPT rule for xxx.188.49.xxx > > > > -> 0.0.0.0/0(tcp/22), 20 sec timeout exceeded > > > > > > > > To restore to the working state, I have to restart the fwknop daemon by > > > > /etc/init.d/fwknop restart. I have a terminal server so I can get access > > > > to the root server by this means. > > > > > > Hmm, clearly that needs to be fixed. Thanks for reporting this. Are > > > there any additional messages written to syslog by fwknopd? There are > > > several places where a syslog message is generated and no corresponding > > > email is sent. But, there may not be any log messages that particularly > > > help in this situation. > > > > > > > Currently I run fwknop 1.9.8, but the problem occoured already some > > > > releases early. Would be great if we could solve the issue. If you need > > > > any debug information or log files, let me know. > > > > > > Can you run the test suite on the system running fwknopd, and send me > > > the anonymized output (-P)? The reason I ask this is that the results > > > will collect a lot of system specifics that may be important to this > > > this bug (even though the test suite may appear to pass all tests). For > > > example, the fact that you are receiving "Connection refused" is > > > interesting, because this implies that a RST is being sent. Hence, > > > either the daemon itself is not available (the port is closed) but there > > > must be an ACCEPT rule to reach the port in the first place, or iptables > > > is sending a RST via the REJECT target. Running the test suite will > > > collect the iptables policy (anonymized) so this will help clarify. > > > > > > I may need to send you a -pre release of 1.9.9 to help fix this problem. > > > > > > Thanks, > > > > > > -- > > > Michael Rash > > > http://www.cipherdyne.org/ > > > Key fingerprint: E2EF 0C8A 5AA9 654C 4763 B50F 37AC E946 7F51 8271 > > > > > > > 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 > > > > > > > > ------------------------------------------------------------------------- > > 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 > > > ------------------------------------------------------------------------- > 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 > > ---- ursprüngliche Nachricht Ende ---- > > ------------------------------------------------------------------------- > 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 |