Kernel panic on 3.14.19 about ndpi-netfilter

[bittorf]

can you provide the output/dmesg/serial log of the panic?
some simple steps to repoduce that?

[jeltevdw]

I only have this. No experience so far with kernel debugging.

[jeltevdw]

At this point in time, i have no idea which traffic is causing this behavior.
I will try to pinpoint this further.

[bittorf]

thank you! @betolj does it help?

[betolj]

A little bit, but I'll try to reproduce this.
Thanks

[tsdmgz]

Not sure if related: on openSUSE 13.2 k3.16.7 serving as a router/gateway with ip_forward=1 at home and also experiencing panics. Right now, I'm trying to figure out how to get kdump to give cores. dmesg isn't giving anything useful right before the panic. Can't tell what kind of traffic is triggering the panic. Last one I remember was something to do with dnsmasq.
Compiled with included nDPI archive.

I'll try to get more details as soon as possible.

iptables rules

# Generated by iptables-save v1.4.21 on Mon Apr 13 03:11:55 2015
*filter
:INPUT DROP [14:699]
:FORWARD ACCEPT [1864:229798]
:OUTPUT ACCEPT [55:8408]
-A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
-A INPUT -i lo -j ACCEPT
-A INPUT -p tcp -m tcp --dport 443 -j ACCEPT
-A INPUT -p udp -m udp --dport 995 -j ACCEPT
-A INPUT -p tcp -m tcp --dport 80 -j ACCEPT
-A INPUT -p tcp -m tcp --dport 22 -j ACCEPT
-A INPUT -i br0 -j ACCEPT
-A INPUT -i tun0 -j ACCEPT
-A INPUT -i tun1 -j ACCEPT
-A FORWARD -i tun0 -j ACCEPT
-A FORWARD -i tun1 -j ACCEPT
-A INPUT -i enp0s14 -p icmp -j ACCEPT


#guest vlan filtering
-N guest
-A INPUT -i vlan10 -j guest
-A FORWARD -i vlan10 -j guest
-A guest -j REJECT
-A guest -p udp --dport 53 -j ACCEPT
-A guest -p udp --dport 67:68 --sport 67:68 -j ACCEPT
-A guest -d 172.16.1.0/24 -j REJECT

COMMIT
# Completed on Mon Apr 13 03:11:55 2015
# Generated by iptables-save v1.4.21 on Mon Apr 13 03:11:55 2015
*mangle
:PREROUTING ACCEPT [100221:11497736]
:INPUT ACCEPT [2877:225164]
:FORWARD ACCEPT [97451:11304727]
:OUTPUT ACCEPT [1567:514621]
:POSTROUTING ACCEPT [99018:11819348]

#from internal
-N internal
-A FORWARD -j internal 
-A INPUT -j internal

#Catchall
-A OUTPUT -o enp0s14 -j CONNMARK --set-mark 140

#NTP
-A internal -m ndpi --ntp -j CONNMARK --set-mark 110

#Skype
-A internal -m ndpi --skype -j CONNMARK --set-mark 110

#Viber
-A internal -m ndpi --viber -j CONNMARK --set-mark 110

#WhatsApp
-A internal -m ndpi --whatsapp --whatsapp_voice -j CONNMARK --set-mark 110

#SFTP or SSH
-N sshsftp
-A POSTROUTING -m ndpi --ssh -j sshsftp
-A sshsftp -m length --length 0:512 -j MARK --set-mark 110
-A sshsftp -m length --length 513:1500 -j MARK --set-mark 140

#DNS
-A POSTROUTING -p udp --dport 53 -j CONNMARK --set-mark 110

#TCP ACK
-A POSTROUTING -o enp0s14 -p tcp --tcp-flags URG,PSH,ACK,RST,SYN,FIN ACK -m length --length 40:64 -j MARK --set-mark 120

#HTTP(S)
-A internal -m ndpi --http -j CONNMARK --set-mark 130
-A internal -m ndpi --ssl -j CONNMARK --set-mark 130

#Torrent
-A internal -s 172.16.1.253/32 -j CONNMARK --set-mark 150

#Catchall forward
-A internal -o enp0s14 -j CONNMARK --set-mark 140

#put mark on all connections
-A POSTROUTING -o enp0s14 -j CONNMARK --restore-mark

COMMIT
# Completed on Mon Apr 13 03:11:55 2015
# Generated by iptables-save v1.4.21 on Mon Apr 13 03:11:55 2015
*nat
:PREROUTING ACCEPT [1691:157995]
:INPUT ACCEPT [145:9176]
:OUTPUT ACCEPT [186:12244]
:POSTROUTING ACCEPT [9326:537258]
-A PREROUTING -p tcp -i enp0s14 -m tcp --dport 12217 -j DNAT --to-destination 172.16.1.102:12217
-A PREROUTING -p udp -i enp0s14 -m udp --dport 12217 -j DNAT --to-destination 172.16.1.102:12217
-A PREROUTING -p tcp -i enp0s14 -m tcp --dport 2687 -j DNAT --to-destination 172.16.1.253:2687
-A PREROUTING -p udp -i enp0s14 -m udp --dport 2687 -j DNAT --to-destination 172.16.1.253:2687
-A PREROUTING -p tcp -m multiport --dports 443,80 -i enp0s14 -j DNAT --to-destination 172.16.1.252
-A POSTROUTING -o enp0s14 -j MASQUERADE
COMMIT
# Completed on Mon Apr 13 03:11:55 2015
# Generated by iptables-save v1.4.21 on Mon Apr 13 03:11:55 2015
*raw
:PREROUTING ACCEPT [100221:11497736]
:OUTPUT ACCEPT [1567:514621]
COMMIT
# Completed on Mon Apr 13 03:11:55 2015

[filippocarletti]

I can consistently have a kernel panic on CentOS 7, kernel 3.10.0 from Redhat.
Here's the first oops:
kp_ndpi_c7.txt

[elico]

@tsdmgz Can you share the way you compile ndpi-netfilter on openSUSE?

[tsdmgz]

Sorry for the delay, still catching up to some tight deadlines coming in. Will fill in more details by the end of the week or so.

I've upgraded to Leap 42.1 since. Compiling it in an LXC container also with 42.1 then cp xt_ndpi.ko /lib/modules/$(uname -r)/extra/ (k4.1.20-11-default as of now) and cp libxt_ndpi.ko /usr/lib64/. Otherwise, I just followed the compile instructions.

On 西元2016年05月23日 22:16, elico wrote:

@tsdmgz Can you share the way you compile ndpi-netfilter on openSUSE?

---

You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHub:
#11 (comment)

[elico]

@tsdmgz I followed the compile instructions (which are for ubuntu 14.04) and it seems to work for 16.04 but yet to find the right set of instructions to compile it on OpenSUSE.
And from what I have seen I might need to recompile the kernel for OpenSUSE.

[tsdmgz]

No need to recompile kernel, it has those enabled. Checked out my build again, turns out I left it at commit a90cad1. Sorry about that. git checkout a90cad1 and try compiling from there? I don't remember why I rolled back, I think I had some issues then.

Or is it complaining of missing headers for iptables? Changes to CFLAGS in ipt/Makefile are needed. Replace it with CFLAGS = -fPIC -I${NDPI_SRC}/include -I${NDPI_SRC}/lib -I/usr/include/pkg/iptables -I../src -DOPENDPI_NETFILTER_MODULE -O2 -Wall -DNDPI_IPTABLES_EXT.

On 西元2016年05月30日 10:33, elico wrote:

@tsdmgz I followed the compile instructions (which are for ubuntu 14.04) and it seems to work for 16.04 but yet to find the right set of instructions to compile it on OpenSUSE.
And from what I have seen I might need to recompile the kernel for OpenSUSE.

---

You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHub:
#11 (comment)

[elico]

@tsdmgz I will try in the next few days to see if I am managing to recompile the kernel and will try to update about it.

[elico]

@tsdmgz the
CFLAGS = -fPIC -I${NDPI_SRC}/include -I${NDPI_SRC}/lib -I/usr/include/pkg/iptables -I../src -DOPENDPI_NETFILTER_MODULE -O2 -Wall -DNDPI_IPTABLES_EXT
Did the trick.
I compiled and installed on latest kernel "4.1.21-14-default".
The only thing which I wasn't sure about was the the xt_ndpi.ko size(40MB):

$ modinfo /lib/modules/4.1.21-14-default/extra/xt_ndpi.ko
filename: /lib/modules/4.1.21-14-default/extra/xt_ndpi.ko
alias: ipt_ndpi
description: nDPI wrapper
author: Humberto Juca [email protected]
author: G. Elian Gidoni [email protected]
license: GPL
srcversion: 15A90752FA2E31031E8B4F7
depends: nf_conntrack,x_tables
vermagic: 4.1.21-14-default SMP preempt mod_unload modversions

I am not sure if it's suppose to be that way and if not then why?
If there would be an option to lower the size it would make it a bit more "portable".

[elico]

@tsdmgz Well it's working but after about 30 minutes or less the VM crashes.

[tsdmgz]

I am not sure if it's suppose to be that way and if not then why?

I'm not sure but it might probably be a distro thing. Ubuntu might be seeing headers for iptables no problem but it might not be the same case for openSUSE.

If there would be an option to lower the size it would make it a bit more "portable".

I believe strip could do that. Not sure if it manages to impair functionality though. See man strip?

Well it's working but after about 30 minutes or less the VM crashes.

Yup, this is what the bug report is about. Still can't get a decent log out of it either.

On 西元2016年06月08日 11:47, elico wrote:

@tsdmgz Well it's working but after about 30 minutes or less the VM crashes.

---

You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHub:
#11 (comment)

[elico]

Just to make sure I must ask if someone is using a kernel and a module that doesn't leak and crash the machine?
May the "Tested on Ubuntu 14.04.1 LTS (Kernel 3.13.0-37-generic)" in the README.md is wrong?

[filippocarletti]

On CentOS 7, I'm having good results with the 4.4 lt kernel from elrepo.

[betolj]

Try the lastest ndpi-netfilter update (v3.0).

[betolj]

spin_lock bugfix applied!