On Thu, 2016-08-04 at 18:41 +0200, Matthias Fischer wrote:
> Hi,
> 
> ...for the records...:
> 
> Today I found the time to take a look with 'htop' and 'top' for the
> 'iptables'-process and found that 'top' lists '1 zombie' (screenshots
> attached).
> 
> "ps -el | grep 'Z'" says:
> 
> ...
> root(a)ipfire: / # ps -el | grep 'Z'
> Warning: /boot/System.map-3.14.65-ipfire-pae not parseable as a System.map
> F S   UID   PID  PPID  C PRI  NI ADDR SZ  WCHAN TTY          TIME CMD
> 4 Z     0   771 10643  0  80   0 -     0      - ?        00:00:00
> iptables <defunct>
> ...
> 
> IMHO this is definitely not as it should be...

Definitely not. And I would like to stress again that I would like to see the
smaller issues gone as soon as possible so that nothing is holding back a
release.

Best,
-Michael
> 
> Best,
> Matthias
> 
> On 31.07.2016 10:39, Michael Tremer wrote:
> > On Sun, 2016-07-31 at 09:20 +0200, Matthias Fischer wrote:
> > > Hi,
> > > 
> > > On 28.07.2016 20:05, Stefan Schantl wrote:
> > > > New test version (004) available.
> > > > 
> > > > http://people.ipfire.org/~stevee/guardian-2.0/
> > > > 
> > > > 
> > > > Changelog: http://people.ipfire.org/~stevee/guardian-2.0/Changelog.txt
> > > > 
> > > > Installation is the same way than all previous versions.
> > > > 
> > > > Please do a lot of testing, I'm still lacking of feedback for 
> > > > 
> > > > * owncloud
> > > > * proper handling of reconnections on red
> > > > * detection of rotating the logfiles (logrotate)
> > > > 
> > > > As usual please provide your feedback on this list and report any bugs
> > > > to our bugtracker.
> > > > 
> > > > Best regards,
> > > > 
> > > > -Stefan
> > > > > ...
> > > 
> > > Perhaps this is something you need to know?
> > > 
> > > Yesterday 'guardian' was still running, but didn't block anymore. I
> > > think this happened because I had changed the DNS-Servers through
> > > 'setup'!?
> > > 
> > > Since I'm 'static', there is no way doing this through GUI, so I had to
> > > do this with a 'root'-console and PuTTY.
> > > 
> > > After network had stopped/started, 'guardian' was still running, but
> > > scanning with http://www.whatsmyip.org/port-scanner/server/ didn't
> > > trigger a block action on Port 1433 anymore as it usually did before.
> > > 
> > > I'm using Snort 2.9.8.3 with "Emergingthreats.net Community Rules" and
> > > this test normally ends with:
> > > 
> > > Datum:	07/31 01:26:34
> > > Name:	ET POLICY Suspicious inbound to MSSQL port 1433
> > > Priorität:	2
> > > Typ:	Potentially Bad Traffic
> > > IP-Info: 	208.64.38.55:55036 -> 192.168.99.254:1433
> > > Referenzen:	http://doc.emergingthreats.net/2010935
> > > SID: 	2010935
> > > 
> > > But after changing DNS entries and restarting network, 'guardian' didn't
> > > react/block anymore during the next scan test.
> > > 
> > > After restarting 'guardian' with /'etc/init.d/guardian restart',
> > > 'guardian' changed status ID, memory raised from 14342 KB to 14732 KB
> > > and during the next scan, 208.64.38.55 was blocked again.
> > > 
> > > 'pstree' says:
> > > 
> > > ...
> > >      |-guardian-+-iptables
> > >      |          `-4*[{guardian}]
> > > ...
> > 
> > I would like to know as well why this iptables process seems to remain in
> > memory
> > all of the time.
> > 
> > Memory consumption of guardian itself seems to be fixed now.
> > 
> > > 
> > > 
> > > Best,
> > > Matthias
> > > 
> > 
>