kernel patch doesn't apply

[syadnom]

Would you mind telling me the exact kernel version your fork of the ndpi-netfilter was last built against as working? I can't get the patch to apply to 2.6.32 which is the stock deb6 kernel (maybe I'm patching wrong?) so though I can get ndpi-netfilter compiled and loaded, it wont match anything. I did recompile the kernel as instruct but without the patch. Thanks

[betolj]

This patch is required if you need to use the conntrack tools and applies to the series 3 of linux kernel.

I tested at kernel 3.13 (Ubuntu 14.04). But to evaluate this extension, you can simply remove the nf_conntrack_netlink before loading the module xt_ndpi.

[syadnom]

I can't get it to mark packets with iptables -m, The modules loads on deb6 and deb7 and ubuntu 14.04 but I try to mark packets and nothing happens.

iptables -t mangle -A OUTPUT -m ndpi --icmp -j DSCP --set-dscp 5 this takes but packets are not marked.

iptables -I OUTPUT -m ndpi --icmp -j DROP this takes but I can still ping outbound

iptables -I INPUT -m ndpi --icmp -j DROP box still responds to pings.

[betolj]

Show your netfilter output with:

iptables -nL INPUT -v iptables -nL OUTPUT -v

2014-11-17 16:05 GMT-03:00 syadnom notifications@github.com:

I can't get it to mark packets with iptables -m, The modules loads on deb6 and deb7 and ubuntu 14.04 but I try to mark packets and nothing happens.

iptables -t mangle -A OUTPUT -m ndpi --icmp -j DSCP --set-dscp 5 this takes but packets are not marked.

iptables -I OUTPUT -m ndpi --icmp -j DROP this takes but I can still ping outbound

iptables -I INPUT -m ndpi --icmp -j DROP box still responds to pings.

— Reply to this email directly or view it on GitHub https://github.com/betolj/ndpi-netfilter/issues/3#issuecomment-63356909.

[syadnom]

ok, module loaded: root@nDPI:~# lsmod|grep xt_ndpi xt_ndpi 174962 2 nf_conntrack 46391 2 nf_conntrack_ipv4,xt_ndpi x_tables 12845 3 xt_DSCP,ip_tables,xt_ndpi

root@nDPI:~# iptables -nL OUTPUT -v Chain OUTPUT (policy ACCEPT 1578 packets, 209K bytes) pkts bytes target prot opt in out source destination 0 0 DROP all -- * * 0.0.0.0/0 0.0.0.0/0 protocol ICMP

still can ping the box and ping from it.

On Mon Nov 17 2014 at 1:10:43 PM Humberto Jucá notifications@github.com wrote:

Show your netfilter output with:

iptables -nL INPUT -v iptables -nL OUTPUT -v

2014-11-17 16:05 GMT-03:00 syadnom notifications@github.com:

I can't get it to mark packets with iptables -m, The modules loads on deb6 and deb7 and ubuntu 14.04 but I try to mark packets and nothing happens.

iptables -t mangle -A OUTPUT -m ndpi --icmp -j DSCP --set-dscp 5 this takes but packets are not marked.

iptables -I OUTPUT -m ndpi --icmp -j DROP this takes but I can still ping outbound

iptables -I INPUT -m ndpi --icmp -j DROP box still responds to pings.

— Reply to this email directly or view it on GitHub https://github.com/betolj/ndpi-netfilter/issues/3#issuecomment-63356909.

— Reply to this email directly or view it on GitHub https://github.com/betolj/ndpi-netfilter/issues/3#issuecomment-63367388.

[betolj]

Ok, actually your ndpi build is correct.

Take a look in this link: https://github.com/betolj/ndpi-netfilter/issues/1

Unfortunately, you cann't use all nDPI protocols. Apparently, it is more safe and guaranteed to work with protocols where there was a specific module build (ftp, http, rdp and others) - only protocols in directory "/usr/src/nDPI/src/lib/protocols/".

I will try to update this netfilter extension to display only supported protocols (its a old problem). Do not even try to identify protocols such as icmp or facebook, for example.

2014-11-17 17:20 GMT-03:00 syadnom notifications@github.com:

ok, module loaded: root@nDPI:~# lsmod|grep xt_ndpi xt_ndpi 174962 2 nf_conntrack 46391 2 nf_conntrack_ipv4,xt_ndpi x_tables 12845 3 xt_DSCP,ip_tables,xt_ndpi

root@nDPI:~# iptables -nL OUTPUT -v Chain OUTPUT (policy ACCEPT 1578 packets, 209K bytes) pkts bytes target prot opt in out source destination 0 0 DROP all -- * * 0.0.0.0/0 0.0.0.0/0 protocol ICMP

still can ping the box and ping from it.

On Mon Nov 17 2014 at 1:10:43 PM Humberto Jucá notifications@github.com wrote:

Show your netfilter output with:

iptables -nL INPUT -v iptables -nL OUTPUT -v

2014-11-17 16:05 GMT-03:00 syadnom notifications@github.com:

I can't get it to mark packets with iptables -m, The modules loads on deb6 and deb7 and ubuntu 14.04 but I try to mark packets and nothing happens.

iptables -t mangle -A OUTPUT -m ndpi --icmp -j DSCP --set-dscp 5 this takes but packets are not marked.

iptables -I OUTPUT -m ndpi --icmp -j DROP this takes but I can still ping outbound

iptables -I INPUT -m ndpi --icmp -j DROP box still responds to pings.

— Reply to this email directly or view it on GitHub < https://github.com/betolj/ndpi-netfilter/issues/3#issuecomment-63356909>.

— Reply to this email directly or view it on GitHub https://github.com/betolj/ndpi-netfilter/issues/3#issuecomment-63367388.

— Reply to this email directly or view it on GitHub https://github.com/betolj/ndpi-netfilter/issues/3#issuecomment-63368750.

[syadnom]

I will test with something out of protocols. I was testing with opendpi and icmp and It worked well. What might be causing the regression from opendpi and opendpi-netfilter ? On Nov 17, 2014 3:53 PM, "Humberto Jucá" notifications@github.com wrote:

Ok, actually your ndpi build is correct.

Take a look in this link: https://github.com/betolj/ndpi-netfilter/issues/1

Unfortunately, you cann't use all nDPI protocols. Apparently, it is more safe and guaranteed to work with protocols where there was a specific module build (ftp, http, rdp and others) - only protocols in directory "/usr/src/nDPI/src/lib/protocols/".

I will try to update this netfilter extension to display only supported protocols (its a old problem). Do not even try to identify protocols such as icmp or facebook, for example.

2014-11-17 17:20 GMT-03:00 syadnom notifications@github.com:

ok, module loaded: root@nDPI:~# lsmod|grep xt_ndpi xt_ndpi 174962 2 nf_conntrack 46391 2 nf_conntrack_ipv4,xt_ndpi x_tables 12845 3 xt_DSCP,ip_tables,xt_ndpi

root@nDPI:~# iptables -nL OUTPUT -v Chain OUTPUT (policy ACCEPT 1578 packets, 209K bytes) pkts bytes target prot opt in out source destination 0 0 DROP all -- * * 0.0.0.0/0 0.0.0.0/0 protocol ICMP

still can ping the box and ping from it.

On Mon Nov 17 2014 at 1:10:43 PM Humberto Jucá notifications@github.com

wrote:

Show your netfilter output with:

iptables -nL INPUT -v iptables -nL OUTPUT -v

2014-11-17 16:05 GMT-03:00 syadnom notifications@github.com:

I can't get it to mark packets with iptables -m, The modules loads on deb6 and deb7 and ubuntu 14.04 but I try to mark packets and nothing happens.

iptables -t mangle -A OUTPUT -m ndpi --icmp -j DSCP --set-dscp 5 this takes but packets are not marked.

iptables -I OUTPUT -m ndpi --icmp -j DROP this takes but I can still ping outbound

iptables -I INPUT -m ndpi --icmp -j DROP box still responds to pings.

— Reply to this email directly or view it on GitHub < https://github.com/betolj/ndpi-netfilter/issues/3#issuecomment-63356909>.

— Reply to this email directly or view it on GitHub < https://github.com/betolj/ndpi-netfilter/issues/3#issuecomment-63367388>.

— Reply to this email directly or view it on GitHub https://github.com/betolj/ndpi-netfilter/issues/3#issuecomment-63368750.

— Reply to this email directly or view it on GitHub https://github.com/betolj/ndpi-netfilter/issues/3#issuecomment-63392052.

[syadnom]

Ok, I can match a few protocols like http with ndpi for DROP, but I can't set DSCP. The same exact matcher that gets http for a DROP fails to set DSCP :(

root@nDPI:~# iptables -n -t mangle -L Chain PREROUTING (policy ACCEPT) target prot opt source destination

Chain INPUT (policy ACCEPT) target prot opt source destination

Chain FORWARD (policy ACCEPT) target prot opt source destination

Chain OUTPUT (policy ACCEPT) target prot opt source destination DSCP all -- 0.0.0.0/0 0.0.0.0/0 protocol HTTP DSCP set 0x05

Chain POSTROUTING (policy ACCEPT) target prot opt source destination

this does not mark DSCP on the packets

On Mon Nov 17 2014 at 3:56:25 PM dan dandenson@gmail.com wrote:

I will test with something out of protocols. I was testing with opendpi and icmp and It worked well. What might be causing the regression from opendpi and opendpi-netfilter ? On Nov 17, 2014 3:53 PM, "Humberto Jucá" notifications@github.com wrote:

Ok, actually your ndpi build is correct.

Take a look in this link: https://github.com/betolj/ndpi-netfilter/issues/1

Unfortunately, you cann't use all nDPI protocols. Apparently, it is more safe and guaranteed to work with protocols where there was a specific module build (ftp, http, rdp and others) - only protocols in directory "/usr/src/nDPI/src/lib/protocols/".

I will try to update this netfilter extension to display only supported protocols (its a old problem). Do not even try to identify protocols such as icmp or facebook, for example.

2014-11-17 17:20 GMT-03:00 syadnom notifications@github.com:

ok, module loaded: root@nDPI:~# lsmod|grep xt_ndpi xt_ndpi 174962 2 nf_conntrack 46391 2 nf_conntrack_ipv4,xt_ndpi x_tables 12845 3 xt_DSCP,ip_tables,xt_ndpi

root@nDPI:~# iptables -nL OUTPUT -v Chain OUTPUT (policy ACCEPT 1578 packets, 209K bytes) pkts bytes target prot opt in out source destination 0 0 DROP all -- * * 0.0.0.0/0 0.0.0.0/0 protocol ICMP

still can ping the box and ping from it.

On Mon Nov 17 2014 at 1:10:43 PM Humberto Jucá < notifications@github.com> wrote:

Show your netfilter output with:

iptables -nL INPUT -v iptables -nL OUTPUT -v

2014-11-17 16:05 GMT-03:00 syadnom notifications@github.com:

I can't get it to mark packets with iptables -m, The modules loads on deb6 and deb7 and ubuntu 14.04 but I try to mark packets and nothing happens.

iptables -t mangle -A OUTPUT -m ndpi --icmp -j DSCP --set-dscp 5 this takes but packets are not marked.

iptables -I OUTPUT -m ndpi --icmp -j DROP this takes but I can still ping outbound

iptables -I INPUT -m ndpi --icmp -j DROP box still responds to pings.

— Reply to this email directly or view it on GitHub < https://github.com/betolj/ndpi-netfilter/issues/3#issuecomment-63356909>.

— Reply to this email directly or view it on GitHub < https://github.com/betolj/ndpi-netfilter/issues/3#issuecomment-63367388>.

— Reply to this email directly or view it on GitHub < https://github.com/betolj/ndpi-netfilter/issues/3#issuecomment-63368750>.

— Reply to this email directly or view it on GitHub https://github.com/betolj/ndpi-netfilter/issues/3#issuecomment-63392052 .

[betolj]

Are you sure? I did a test right now ...

Chain OUTPUT (policy ACCEPT 36 packets, 4653 bytes) pkts bytes target prot opt in out source destination 14 2885 DSCP all -- * * 0.0.0.0/0 0.0.0.0/0 protocol HTTP DSCP set 0x05

root@humberto-XPS-8300:~# uname -a Linux humberto-XPS-8300.ms 3.13.0-37-generic #64-Ubuntu SMP Mon Sep 22 21:28:38 UTC 2014 x86_64 x86_64 x86_64 GNU/Linux

root@humberto-XPS-8300:~# iptables --version iptables v1.4.21

root@humberto-XPS-8300:~# cat /etc/debian_version jessie/sid

2014-11-17 21:09 GMT-03:00 syadnom notifications@github.com:

Ok, I can match a few protocols like http with ndpi for DROP, but I can't set DSCP. The same exact matcher that gets http for a DROP fails to set DSCP :(

root@nDPI:~# iptables -n -t mangle -L Chain PREROUTING (policy ACCEPT) target prot opt source destination

Chain INPUT (policy ACCEPT) target prot opt source destination

Chain FORWARD (policy ACCEPT) target prot opt source destination

Chain OUTPUT (policy ACCEPT) target prot opt source destination DSCP all -- 0.0.0.0/0 0.0.0.0/0 protocol HTTP DSCP set 0x05

Chain POSTROUTING (policy ACCEPT) target prot opt source destination

this does not mark DSCP on the packets

[syadnom]

Thanks, I do actually have it kind of working. I can match bittorrent very well, but the netflix matching is basically not happening, and ICMP is 100% not matching.

My goal was match bittorrent and netflix, so I'm 1/2 way there! I'm not 100% sure what might be keeping netflix from matching because I'm running it through squid proxy.

Do you know if the netflix matching should work? If I were to deploy this I would be routing, not running squid proxy.

Every 1.0s: iptables -nv -t mangle -L Tue Nov 18 11:50:53 2014

Chain PREROUTING (policy ACCEPT 575K packets, 791M bytes) pkts bytes target prot opt in out source destination 7 3078 DSCP all -- * * 0.0.0.0/0 0.0.0.0/0 protocol Netflix DSCP set 0x05 437K 634M DSCP all -- * * 0.0.0.0/0 0.0.0.0/0 protocol Bittorrent DSCP set 0x05

Chain INPUT (policy ACCEPT 575K packets, 791M bytes) pkts bytes target prot opt in out source destination 480K 696M DSCP all -- * * 0.0.0.0/0 0.0.0.0/0 protocol Bittorrent DSCP set 0x05 0 0 DSCP all -- * * 0.0.0.0/0 0.0.0.0/0 protocol Netflix DSCP set 0x05

Chain FORWARD (policy ACCEPT 0 packets, 0 bytes) pkts bytes target prot opt in out source destination 0 0 DSCP all -- * * 0.0.0.0/0 0.0.0.0/0 protocol Bittorrent DSCP set 0x05 0 0 DSCP all -- * * 0.0.0.0/0 0.0.0.0/0 protocol Netflix DSCP set 0x05

Chain OUTPUT (policy ACCEPT 391K packets, 170M bytes) pkts bytes target prot opt in out source destination 97272 5652K DSCP all -- * * 0.0.0.0/0 0.0.0.0/0 protocol HTTP DSCP set 0x05 0 0 DSCP all -- * * 0.0.0.0/0 0.0.0.0/0 protocol ICMP DSCP set 0x05 254K 16M DSCP all -- * * 0.0.0.0/0 0.0.0.0/0 protocol Bittorrent DSCP set 0x05 0 0 DSCP all -- * * 0.0.0.0/0 0.0.0.0/0 protocol Netflix DSCP set 0x05

Chain POSTROUTING (policy ACCEPT 391K packets, 170M bytes) pkts bytes target prot opt in out source destination 0 0 DSCP all -- * * 0.0.0.0/0 0.0.0.0/0 protocol Netflix DSCP set 0x05 227K 14M DSCP all -- * * 0.0.0.0/0 0.0.0.0/0 protocol Bittorrent DSCP set 0x05

On Mon Nov 17 2014 at 5:19:43 PM Humberto Jucá notifications@github.com wrote:

Are you sure? I did a test right now ...

Chain OUTPUT (policy ACCEPT 36 packets, 4653 bytes) pkts bytes target prot opt in out source destination 14 2885 DSCP all -- * * 0.0.0.0/0 0.0.0.0/0 protocol HTTP DSCP set 0x05

root@humberto-XPS-8300:~# uname -a Linux humberto-XPS-8300.ms 3.13.0-37-generic #64-Ubuntu SMP Mon Sep 22 21:28:38 UTC 2014 x86_64 x86_64 x86_64 GNU/Linux

root@humberto-XPS-8300:~# iptables --version iptables v1.4.21

root@humberto-XPS-8300:~# cat /etc/debian_version jessie/sid

2014-11-17 21:09 GMT-03:00 syadnom notifications@github.com:

Ok, I can match a few protocols like http with ndpi for DROP, but I can't set DSCP. The same exact matcher that gets http for a DROP fails to set DSCP :(

root@nDPI:~# iptables -n -t mangle -L Chain PREROUTING (policy ACCEPT) target prot opt source destination

Chain INPUT (policy ACCEPT) target prot opt source destination

Chain FORWARD (policy ACCEPT) target prot opt source destination

Chain OUTPUT (policy ACCEPT) target prot opt source destination DSCP all -- 0.0.0.0/0 0.0.0.0/0 protocol HTTP DSCP set 0x05

Chain POSTROUTING (policy ACCEPT) target prot opt source destination

this does not mark DSCP on the packets

—

Reply to this email directly or view it on GitHub https://github.com/betolj/ndpi-netfilter/issues/3#issuecomment-63401784.

[syadnom]

Humberto, thanks for all your help. One last thing. What is the most recent version of nDPI can you build against? I'm on r8323 right now, but I'd like to get more current for better protocol matching.

Thanks!

On Tue Nov 18 2014 at 11:54:42 AM dan dandenson@gmail.com wrote:

Thanks, I do actually have it kind of working. I can match bittorrent very well, but the netflix matching is basically not happening, and ICMP is 100% not matching.

My goal was match bittorrent and netflix, so I'm 1/2 way there! I'm not 100% sure what might be keeping netflix from matching because I'm running it through squid proxy.

Do you know if the netflix matching should work? If I were to deploy this I would be routing, not running squid proxy.

Every 1.0s: iptables -nv -t mangle -L Tue Nov 18 11:50:53 2014

Chain PREROUTING (policy ACCEPT 575K packets, 791M bytes) pkts bytes target prot opt in out source destination 7 3078 DSCP all -- * * 0.0.0.0/0 0.0.0.0/0 protocol Netflix DSCP set 0x05 437K 634M DSCP all -- * * 0.0.0.0/0 0.0.0.0/0 protocol Bittorrent DSCP set 0x05

Chain INPUT (policy ACCEPT 575K packets, 791M bytes) pkts bytes target prot opt in out source destination 480K 696M DSCP all -- * * 0.0.0.0/0 0.0.0.0/0 protocol Bittorrent DSCP set 0x05 0 0 DSCP all -- * * 0.0.0.0/0 0.0.0.0/0 protocol Netflix DSCP set 0x05

Chain FORWARD (policy ACCEPT 0 packets, 0 bytes) pkts bytes target prot opt in out source destination 0 0 DSCP all -- * * 0.0.0.0/0 0.0.0.0/0 protocol Bittorrent DSCP set 0x05 0 0 DSCP all -- * * 0.0.0.0/0 0.0.0.0/0 protocol Netflix DSCP set 0x05

Chain OUTPUT (policy ACCEPT 391K packets, 170M bytes) pkts bytes target prot opt in out source destination 97272 5652K DSCP all -- * * 0.0.0.0/0 0.0.0.0/0 protocol HTTP DSCP set 0x05 0 0 DSCP all -- * * 0.0.0.0/0 0.0.0.0/0 protocol ICMP DSCP set 0x05 254K 16M DSCP all -- * * 0.0.0.0/0 0.0.0.0/0 protocol Bittorrent DSCP set 0x05 0 0 DSCP all -- * * 0.0.0.0/0 0.0.0.0/0 protocol Netflix DSCP set 0x05

Chain POSTROUTING (policy ACCEPT 391K packets, 170M bytes) pkts bytes target prot opt in out source destination 0 0 DSCP all -- * * 0.0.0.0/0 0.0.0.0/0 protocol Netflix DSCP set 0x05 227K 14M DSCP all -- * * 0.0.0.0/0 0.0.0.0/0 protocol Bittorrent DSCP set 0x05

On Mon Nov 17 2014 at 5:19:43 PM Humberto Jucá notifications@github.com wrote:

Are you sure? I did a test right now ...

Chain OUTPUT (policy ACCEPT 36 packets, 4653 bytes) pkts bytes target prot opt in out source destination 14 2885 DSCP all -- * * 0.0.0.0/0 0.0.0.0/0 protocol HTTP DSCP set 0x05

root@humberto-XPS-8300:~# uname -a Linux humberto-XPS-8300.ms 3.13.0-37-generic #64-Ubuntu SMP Mon Sep 22 21:28:38 UTC 2014 x86_64 x86_64 x86_64 GNU/Linux

root@humberto-XPS-8300:~# iptables --version iptables v1.4.21

root@humberto-XPS-8300:~# cat /etc/debian_version jessie/sid

2014-11-17 21:09 GMT-03:00 syadnom notifications@github.com:

Ok, I can match a few protocols like http with ndpi for DROP, but I can't set DSCP. The same exact matcher that gets http for a DROP fails to set DSCP :(

root@nDPI:~# iptables -n -t mangle -L Chain PREROUTING (policy ACCEPT) target prot opt source destination

Chain INPUT (policy ACCEPT) target prot opt source destination

Chain FORWARD (policy ACCEPT) target prot opt source destination

Chain OUTPUT (policy ACCEPT) target prot opt source destination DSCP all -- 0.0.0.0/0 0.0.0.0/0 protocol HTTP DSCP set 0x05

Chain POSTROUTING (policy ACCEPT) target prot opt source destination

this does not mark DSCP on the packets

—

Reply to this email directly or view it on GitHub https://github.com/betolj/ndpi-netfilter/issues/3#issuecomment-63401784 .

[betolj]

I'll try to compile this project using the most current version of nDPI.

I made small fixes to collaborate with the opensource community. But, I have doubts whether it's desirable for production environments. Many kernel changes were made to receive the new nftables support. And, many changes have been made in nDPI too. It is not easy to compile a older version of nDPI in a newer kernel, for example. This makes things more difficult.

And i still have some questions, like:

• Why the kernel support is not official until now?
• Why the xtables-addons package maintains ipp2p support (It's nDPI in embryonic stage)?

I noticed that many people are looking for the ndpi-netfilter to work with QoS. In my opinion, the best choice is the ipp2p module for P2P classify and use IPS signatures (as Suricata) to make firewall marks (MARK).

Take a look in this example: https://home.regit.org/2012/10/defend-your-network-from-word/

You can easily create or change any IPS signature. I did not yet test an approach like this, but I work with Suricata into IPS mode.

[betolj]

I will make several fixes as soon and protocol id bugfix too. Wait a little bit.

[betolj]

The "ndpi-netfilter" projects with logical structure based on "ewildgoose" model don't work well nowadays.

1. Only one exclusive "conntrack notify" call: For this reason, it cann't be used in conjunction with nfnetlink. But, when you remove the nfnetlink kernel module, the conntrack application wont works anymore.
2. The web host detection depends on http or ssl protocols enabled: Youtube or Facebook protocols are not external modules (like /usr/src/nDPI/src/lib/protocols/*).

I finished xt_ndpi fixes today:

• Remove "conntrack notifier" from source code and include a new ndpi flow garbage collector for 3.x kernel series. Now, no longer need remove the nfnetlink kernel module to install xt_ndpi.
• Enable http and ssl protocol for youtube, facebook and others.

My tests, showed satisfactory results. https://github.com/betolj/ndpi-netfilter

[syadnom]

betolj, does this mean that ndpi current can be used with ndpi-netfilter?

[betolj]

Yes .. the project was upgraded to the latest nDPI version.

[syadnom]

awesome, I will take it for a spin tomorrow!

On Mon, Jun 15, 2015 at 8:57 PM, Humberto Jucá notifications@github.com wrote:

Yes .. the project was upgraded to the latest nDPI version.

— Reply to this email directly or view it on GitHub https://github.com/betolj/ndpi-netfilter/issues/3#issuecomment-112266589 .

[syadnom]

I've built ndpi and ndpi-netfilter both from trunk on ubuntu 14.04 x64

I'm unable to load the module, modprobe: ERROR: could not insert 'xt_ndpi': Unknown symbol in module, or unknown parameter (see dmesg)

[syadnom]

I do see a couple warnings in the build: WARNING: "ndpi_search_kakaotalk_voice" [/usr/src/ndpi-netfilter/trunk/src/xt_ndpi.ko] undefined! WARNING: "ndpi_search_eaq" [/usr/src/ndpi-netfilter/trunk/src/xt_ndpi.ko] undefined! LD [M] /usr/src/ndpi-netfilter/trunk/src/xt_ndpi.ko make[2]: Leaving directory /usr/src/linux-headers-3.13.0-55-generic' rm -r ndpi_cpy make[1]: Leaving directory/usr/src/ndpi-netfilter/trunk/src'

here is the dmesg output: [ 381.317982] nf_conntrack version 0.5.0 (16384 buckets, 65536 max) [ 381.319381] xt_ndpi: module verification failed: signature and/or required key missing - tainting kernel [ 381.319459] xt_ndpi: Unknown symbol ndpi_search_eaq (err 0) [ 381.319467] xt_ndpi: Unknown symbol ndpi_search_kakaotalk_voice (err 0) [ 395.498339] xt_ndpi: Unknown symbol ndpi_search_eaq (err 0) [ 395.498374] xt_ndpi: Unknown symbol ndpi_search_kakaotalk_voice (err 0) [ 400.135331] xt_ndpi: Unknown symbol ndpi_search_eaq (err 0) [ 400.135365] xt_ndpi: Unknown symbol ndpi_search_kakaotalk_voice (err 0) [ 434.523824] xt_ndpi: Unknown symbol ndpi_search_eaq (err 0) [ 434.523858] xt_ndpi: Unknown symbol ndpi_search_kakaotalk_voice (err 0) [ 483.377801] xt_ndpi: Unknown symbol ndpi_search_eaq (err 0) [ 483.377836] xt_ndpi: Unknown symbol ndpi_search_kakaotalk_voice (err 0) [ 512.407602] xt_ndpi: Unknown symbol ndpi_search_eaq (err 0) [ 512.407623] xt_ndpi: Unknown symbol ndpi_search_kakaotalk_voice (err 0) [ 961.657982] xt_ndpi: Unknown symbol ndpi_search_eaq (err 0) [ 961.658016] xt_ndpi: Unknown symbol ndpi_search_kakaotalk_voice (err 0) [ 1000.082087] xt_ndpi: Unknown symbol ndpi_search_eaq (err 0) [ 1000.082122] xt_ndpi: Unknown symbol ndpi_search_kakaotalk_voice (err 0)

[syadnom]

I removed kakaotalk and eaq from ndpi which allowed my to build and load xt_ndpi, but now I get a kernel panic whenever iptables loads the ndpi module.

[syadnom]

dmesg shows this when loading the module

[ 2689.841269] xt_ndpi 2.0 (nDPI wrapper module). [ 2689.849190] [NDPI] ndpi_string_to_automa(protoId=193): INTERNAL ERROR [ 2689.849195] [NDPI] ndpi_string_to_automa(protoId=195): INTERNAL ERROR [ 2689.849260] [NDPI] ndpi_string_to_automa(protoId=195): INTERNAL ERROR [ 2689.849496] [NDPI] ndpi_init_protocol_defaults(missing protoId=194) INTERNAL ERROR: not all protocols have been initialized

[syadnom]

sorry for the string of comments.....

iptables -m ndpi --help segfaults

ndpi match options: --ftp Match for FTP_CONTROL protocol packets. --pop Match for MAIL_POP protocol packets. <-- truncated list --> --whatsapp_voice Match for WHATSAPP_VOICE protocol packets. --dpi_check Match for CHECK protocol packets. Segmentation fault (core dumped)

[syadnom]

opened a new issue, please ignore my previous few comments and see updated issue #8