If you've done the downgrade, an update was pushed last night so you should now have:

app-netify-fwa-core-2.3.2-1.v7.noarch

netify-fwa-2.2-1.v7.noarch

If you have not done the downgrade, do:

yum downgrade app-netify* netify*

yum update app-netify* netify*

which should straighten thing out.

This should provide an interim fix for BitTorrent. The blocking will not be perfect but, if anything gets through, it should be very slow and the app should no longer stop. I hope to test myself in the next few days.

But didn't you upgrade components to those in clearos-contribs-testing? If so try a:

yum downgrade app-netify* netify*

But then you'll be back to where you started.......

Peter Baldwin wrote:

You should also know that the Bittorrent detection is not 100%. An end user will be able to start a torrent, but connections to most peers will fail and the download will be extremely slow (or maybe even nil).

I have been installed Protocol Filter from marketplace, but as soon as I turn on the utorrent download after a short time Protocol Filter action status STOPPED.

You should also know that the Bittorrent detection is not 100%. An end user will be able to start a torrent, but connections to most peers will fail and the download will be extremely slow (or maybe even nil).

I am back from an overseas trip. It looks like the versions in contribs-testing are not compatible with the Protocol Filter. That was bad advice on my part... sorry about that. Only the versions in contribs should be used at the moment.

I've found a third component in contribs-testing - app-netify-fwa-core-2.3.2-1.v7 - but that did not help or change the server error messages.

It segfaulted on me earlier today and I was not in the house:

Jan  4 18:17:44 server kernel: enp2s0[27194]: segfault at ffffffffffffffe8 ip 000000000041805b sp 00007f4727a147e0 error 5 in netifyd[400000+82000]

Jan  4 18:17:44 server netify-fwa[17281]: Netify socket hung-up, reconnecting...

Jan  4 18:17:44 server netify-fwa[17281]: Error connecting to Netify node: Connection refused

Jan  4 18:17:44 server systemd: netifyd.service: main process exited, code=killed, status=11/SEGV

Jan  4 18:17:44 server systemd: Unit netifyd.service entered failed state.

Jan  4 18:17:44 server systemd: netifyd.service failed.

Jan  4 18:17:45 server netifyd: Netify Agent v2.3

Jan  4 18:17:45 server netifyd: Unable to hash file: /var/lib/netifyd/app-content-match.csv: No such file or directory

Jan  4 18:17:45 server netifyd: Unable to hash file: /var/lib/netifyd/app-host-match.csv: No such file or directory

Jan  4 18:17:45 server netifyd: enp5s0: capture started on CPU: 0

Jan  4 18:17:45 server netifyd: enp2s0: capture started on CPU: 1

And I've just checked and those two files do not exist.

Edgars Volkovs wrote:

Nick Howitt wrote:

[quote]Edgars Volkovs wrote:
Want to see my / var / log / messages???

It can't harm and may help, so please post them but not the whole thing, just a relevant section.

Okey - I'll post tomorrow.[/quote]


Jan 4 10:38:30 gateway netifyd: void ndSocketThread::ClientHangup(std::map<int, ndSocket*>::iterator&
Jan 4 10:38:30 gateway netify-fwa[24814]:
Jan 4 10:38:30 gateway systemd: start request repeated too quickly for firewall.service
Jan 4 10:38:30 gateway systemd: Failed to start ClearOS Firewall Engine.
Jan 4 10:38:30 gateway systemd: firewall.service failed.
Jan 4 10:38:30 gateway exec-stop-post.sh: Job for firewall.service failed because start of the service was attempted too often. See "systemctl status firewall.service" and "journalctl -xe" for details.
Jan 4 10:38:30 gateway exec-stop-post.sh: To force a start use "systemctl reset-failed firewall.service" followed by "systemctl start firewall.service" again.
Jan 4 10:38:30 gateway systemd: netify-fwa.service: control process exited, code=exited status=1
Jan 4 10:38:30 gateway systemd: Failed to start Netify FWA Daemon.
Jan 4 10:38:30 gateway systemd: Unit netify-fwa.service entered failed state.
Jan 4 10:38:30 gateway systemd: netify-fwa.service failed.
Jan 4 10:38:32 gateway webconfig: Redirecting to /bin/systemctl start netify-fwa.service
Jan 4 10:38:32 gateway systemd: Starting Netify FWA Daemon...
Jan 4 10:38:32 gateway php: Netify Firewall Agent v1.8/1.5
Jan 4 10:38:32 gateway php: Netify Firewall Agent v1.8 starting...
Jan 4 10:38:32 gateway netify-fwa[24924]:
Jan 4 10:38:32 gateway systemd: start request repeated too quickly for firewall.service
Jan 4 10:38:32 gateway systemd: Failed to start ClearOS Firewall Engine.
Jan 4 10:38:32 gateway systemd: firewall.service failed.
Jan 4 10:38:32 gateway exec-start-post.sh: Job for firewall.service failed because start of the service was attempted too often. See "systemctl status firewall.service" and "journalctl -xe" for details.
Jan 4 10:38:32 gateway exec-start-post.sh: To force a start use "systemctl reset-failed firewall.service" followed by "systemctl start firewall.service" again.
Jan 4 10:38:32 gateway systemd: netify-fwa.service: control process exited, code=exited status=1
Jan 4 10:38:32 gateway netify-fwa[25128]: Exiting...

Nick Howitt wrote:

Edgars Volkovs wrote:
Want to see my / var / log / messages???

It can't harm and may help, so please post them but not the whole thing, just a relevant section.

Okey - I'll post tomorrow.

Edgars Volkovs wrote:
Want to see my / var / log / messages???

It can't harm and may help, so please post them but not the whole thing, just a relevant section.

Nick Howitt wrote:

Digging further, I am seeing the following in /var/log/messages:

Jan  3 18:19:12 server clearsyncd[18063]: System Events: Socket hang-up: 33

Jan  3 18:19:12 server clearsyncd[18063]: System Events: Socket hang-up: 33

Jan  3 18:21:07 server netify-fwa[19754]: Exiting...

Jan  3 18:21:07 server netify-fwa[19754]: 

Jan  3 18:21:07 server netifyd: void ndSocketThread::ClientHangup(std::map<int, ndSocket*>::iterator&

Jan  3 18:21:08 server clearsyncd[18063]: System Events: Socket hang-up: 33

Jan  3 18:21:11 server clearsyncd[18063]: System Events: Socket hang-up: 33

Jan  3 18:21:11 server php: Netify Firewall Agent v1.8/1.5

Jan  3 18:21:12 server php: Netify Firewall Agent v1.8 starting...

Jan  3 18:21:12 server netify-fwa[15651]: 

Jan  3 18:21:12 server clearsyncd[18063]: System Events: Socket hang-up: 33

Jan  3 18:21:12 server netify-fwa[15703]: Exiting...

Jan  3 18:21:12 server clearsyncd[18063]: System Events: Socket hang-up: 33

Jan  3 18:21:12 server netify-fwa[15703]: 

Jan  3 18:21:12 server netifyd: void ndSocketThread::ClientHangup(std::map<int, ndSocket*>::iterator&

Jan  3 18:21:12 server clearsyncd[18063]: System Events: Socket hang-up: 33

Jan  3 18:21:16 server clearsyncd[18063]: System Events: Socket hang-up: 33

Jan  3 18:21:16 server php: Netify Firewall Agent v1.8/1.5

Jan  3 18:21:16 server php: Netify Firewall Agent v1.8 starting...

Jan  3 18:21:16 server netify-fwa[17237]: 

Jan  3 18:21:16 server clearsyncd[18063]: System Events: Socket hang-up: 33

Jan  3 18:21:20 server clearsyncd[18063]: System Events: Socket hang-up: 33

and the firewall seems to restart 5 times.

Want to see my / var / log / messages???

Digging further, I am seeing the following in /var/log/messages:

Jan  3 18:19:12 server clearsyncd[18063]: System Events: Socket hang-up: 33

Jan  3 18:19:12 server clearsyncd[18063]: System Events: Socket hang-up: 33

Jan  3 18:21:07 server netify-fwa[19754]: Exiting...

Jan  3 18:21:07 server netify-fwa[19754]: 

Jan  3 18:21:07 server netifyd: void ndSocketThread::ClientHangup(std::map<int, ndSocket*>::iterator&

Jan  3 18:21:08 server clearsyncd[18063]: System Events: Socket hang-up: 33

Jan  3 18:21:11 server clearsyncd[18063]: System Events: Socket hang-up: 33

Jan  3 18:21:11 server php: Netify Firewall Agent v1.8/1.5

Jan  3 18:21:12 server php: Netify Firewall Agent v1.8 starting...

Jan  3 18:21:12 server netify-fwa[15651]: 

Jan  3 18:21:12 server clearsyncd[18063]: System Events: Socket hang-up: 33

Jan  3 18:21:12 server netify-fwa[15703]: Exiting...

Jan  3 18:21:12 server clearsyncd[18063]: System Events: Socket hang-up: 33

Jan  3 18:21:12 server netify-fwa[15703]: 

Jan  3 18:21:12 server netifyd: void ndSocketThread::ClientHangup(std::map<int, ndSocket*>::iterator&

Jan  3 18:21:12 server clearsyncd[18063]: System Events: Socket hang-up: 33

Jan  3 18:21:16 server clearsyncd[18063]: System Events: Socket hang-up: 33

Jan  3 18:21:16 server php: Netify Firewall Agent v1.8/1.5

Jan  3 18:21:16 server php: Netify Firewall Agent v1.8 starting...

Jan  3 18:21:16 server netify-fwa[17237]: 

Jan  3 18:21:16 server clearsyncd[18063]: System Events: Socket hang-up: 33

Jan  3 18:21:20 server clearsyncd[18063]: System Events: Socket hang-up: 33

and the firewall seems to restart 5 times.

With BitTorrent only selected as a filter, the app does not crash for me, but then it neither blocks Transmission on the Server or Halite (a BitTorrent app) on my PC.

I've mentioned your issue to the dev's.

Nick Howitt wrote:

... and working now?

Check the protocol filter as soon as uttorrent starts downloading immediately the protocol filter app is stopped

Protocol filter status: Running, will need to check utorrent download blocking action.

... and working now?

Nick Howitt wrote:

Hmm, it looks like you also need to update netify-fwa:

yum --enablerepo=clearos-contribs-testing upgrade netify*

For me I did not get the stopping with the basic installation. If I installed the updates-testing netifyd on its own then the protocol filter would stop. Updating to the netify-fwa version in updates-testing allowed the protocol filter to run. I found it did not block Transmission running on my server from downloading. I don't know if it is supposed to or if it is only meant to block apps downloading on the LAN.

Updated:
netify-fwa.noarch 0:2.0-1.v7

Complete!
[root@gateway ~]#

Nick Howitt wrote:

App Version 2.3.0-1 is the version of the app-protocol-filter. What is the netify version (and for the sake of it the netify-fwa version):

rpm -q netifyd netify-fwa

Rather than doing a print screen, you can copy text from PuTTy just by selecting it. Then paste it into your post between "code" tags (the piece of paper icon with a <> on it)

[root@gateway ~]# rpm -q netifyd netify-fwa
netifyd-2.3-1.v7.x86_64
netify-fwa-1.6-1.v7.noarch

Hmm, it looks like you also need to update netify-fwa:

yum --enablerepo=clearos-contribs-testing upgrade netify*

For me I did not get the stopping with the basic installation. If I installed the updates-testing netifyd on its own then the protocol filter would stop. Updating to the netify-fwa version in updates-testing allowed the protocol filter to run. I found it did not block Transmission running on my server from downloading. I don't know if it is supposed to or if it is only meant to block apps downloading on the LAN.

App Version 2.3.0-1 is the version of the app-protocol-filter. What is the netify version (and for the sake of it the netify-fwa version):

rpm -q netifyd netify-fwa

Rather than doing a print screen, you can copy text from PuTTy just by selecting it. Then paste it into your post between "code" tags (the piece of paper icon with a <> on it)

Unfortunately not updated.

Yum update on its own won't work as testing repos are disabled by default. You need to use the full line Peter posted.

I run: yum update still does not offer the latest version.

App Version 2.3.0-1

Did it install? It looks like it should be version 2.3-1.v7

Was executed but did not help.
yum --enablerepo=clearos-contribs-testing upgrade netifyd

Edgars Volkovs wrote:

Yes i have been installed Protocol Filter from marketplace, but as soon as I turn on the utorrent download after a short time Protocol Filter action status STOPPED.

There's some corruption in the Bittorrent detection engine. This has been fixed but not yet pushed out for final release. To install the fix, run:

yum --enablerepo=clearos-contribs-testing upgrade netifyd

Okey.

I've no idea. I can't chase the devs too much. I may get the chance to ask on Friday.

Is it not known when the protocol filter will work?

Ok, Thanks.

The Tech team will have a look but no promise of time scales.

I'll ask the tech team as this is a beta app.

Yes i have been installed Protocol Filter from marketplace, but as soon as I turn on the utorrent download after a short time Protocol Filter action status STOPPED.

Have you had a look at the Protocol Filter app from the marketplace?

What happened when you used your rules? Did utorrent use low ports? or did the firewall rules fail. Note at a minimum you should use "iptables -w" and not just "iptables". Better is to use $IPTABLES (but it won't work at the command line.