ClearFoundation

Hi,

I couldn't find a bug tracker for ClearOS, and sales haven't responded to our email about transitioning to ClearOS, so I'll just post it here.

The protocol filter seems to work as expected with most protocols, but some don't seem to show up in iptables. Two examples are Counterstrike and Day of Defeat.

Another bug is in the Layer7Filter.class.php API file. The regular expression it uses in GetStatus doesn't match correctly when the number of packages or bytes gets "K", "M", "G", etc. appended. This causes the Protocol Filter Report page to show zeros in those fields after 99,999 blocked packages or bytes, when iptables begins to report it as "100K".

When I fixed the regular expression myself, I also had to change protocol-filter-report.php and protocol-filter-report.xml.php to use %s in the printf's for printing the number of packages and bytes. This is what lead me to discover that there were protocols which weren't matched by the regular expression because they weren't there, as the JavaScript reading the XML fails when there is no text between the "bytes" and "packets" tags.

Hope this helps someone somehow

- Marcus

Hello,

I would love to know if the ClearOs team is working on this bug or not.

Thanks.

Best Regards,
Julien.

There are a number of things associated with the protocol filter that we are working on at the moment. The bug tracker is here.

Hi David,

Thanks for answering!

I've checked bugs related to "Protocol Filter" and what i've notice is that the first bug resolved (tracker.clearfoundation.com/view.php?id=5) will be fixed in version 5.2

The most annoying bug with Protocol Filter is that sometimes it blocks traffic when we unblock all protocols and i couldn't understand why. I need to activate some traffic to be blocked in order to be able to retrieve mails, for example...

Will you correct all this bugs in version 5.2 and if so, when do you think (approximatively) version 5.2 will be released?

Last question, do you know a way to see which IP address is being blocked by the protocol filter?

Thanks in advance.

Best Regards,
Julien.

I'll let Peter or Darryl field these questions since they are developing the roadmap for l7-filter.

We got some of the same issues reported in the bug tracker as you do ...

Just 60 km north of vejle In Århus C

The Protocol Filter just stops ... I wanted to make a note in the bug tracker on this site, but can't seem to login ... nor can I find a way to create a user there ....

Have you found a solution to the Protocol Filter crash ? the bug is rather old now .... and its a pain in the ***** cause the users starts to complain .... GRRRR

mvh

Here is the script we use to restart it when it dies:


Just save it as an executable file somewhere and the run it with "./file.sh &", that should background it and keep it running after you log out of SSH. You could also add that command to /etc/rc.local to make the script run automatically on boot.

It's not pretty, but it keeps disruptions down. There was mention of a wrapper script, which catches signals in the bug report. That might be a more elegant solution, but ultimately the l7-filter package should be fixed upstream, which I think is in the works.

Unfortunately, either the software is working fine for a majority of users, or it is just not very widely used. In either case a real fix may be far off, but since we've used this script, it hasn't been a big problem for us.

- Marcus

Marcus Calverley wrote:
Here is the script we use to restart it when it dies:

Code:

#!/bin/bash log="/some/path/filter.log" pid="$(pidof /usr/bin/l7-filter)" if [ $? -eq 1 ] then         echo "$(date) starting l7-filter" >> $log         /sbin/service l7-filter start         /sbin/service firewall restart fi while sleep 60 do         pid="$(pidof /usr/bin/l7-filter)"         if [ $? -eq 1 ]         then                 echo "$(date) error: l7-filter crashed..." >> $log                 $0 & # Run this script again                 exit 0         fi done

Just save it as an executable file somewhere and the run it with "./file.sh &", that should background it and keep it running after you log out of SSH. You could also add that command to /etc/rc.local to make the script run automatically on boot.

It's not pretty, but it keeps disruptions down. There was mention of a wrapper script, which catches signals in the bug report. That might be a more elegant solution, but ultimately the l7-filter package should be fixed upstream, which I think is in the works.

Unfortunately, either the software is working fine for a majority of users, or it is just not very widely used. In either case a real fix may be far off, but since we've used this script, it hasn't been a big problem for us.

- Marcus

Thanks ...

I think I will try it ... and just add a "mail command" to the script ... to get notified when it stops working ... its not often is goes down here ... but, it happens.

Maybe every 1-2 weeks ... but still annoying as hell.

mvh

Hello all,

I think that L7-filter is not mature enough...


We have noticed 2 huge bugs with it...

First is we can't use more than the half of our WAN bandwidth when the l7-filter is activated...
We haven't found why but disabling it gave back normal values to the Wan network report.

Second is that, our mail server, another ClearOs system on a DMZ, was not able anymore to send mails whereas it was able to receive some when we were filtering the Skype protocol.
Every smtp connection to the outside was taken as a udp skype connection which was blocked.

So i won't use anymore this software as it always gave me troubles and i have nothing good to say from it.

Best Regards,
Julien.

Hi,

Well ... we are only using it to block p2p ... and have uncommented the Skype ... since alot of out users to use it ...

I dont think we have any problems with the traffic ... we can get 15 MB/sec ... when the Protocol Filtering is activated ...

How fast are your connection, since you can't max it out ?