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@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