OpenWrt Forum Archive

Topic: Application Layer Packet Classifier testing

The content of this topic has been archived on 11 Apr 2018. There are no obvious gaps in this topic, but there may still be some posts missing at the end.

Hi all,

just a little word to say I uploaded some stuff to test layer7

You can find the firmwares, packages and instructions here


--
Nico

Huston, we got a problem...

~ # ipkg status |grep layer7
Package: ipt-layer7
Package: kmod-ipt-layer7
~ # ipkg files ipt-layer7
/
//usr
//usr/lib
//usr/lib/iptables
//usr/lib/iptables/libipt_layer7.so
~ # ipkg files kmod-ipt-layer7
/
//lib
//lib/modules
//lib/modules/2.4.20
//lib/modules/2.4.20/netfilter
//lib/modules/2.4.20/netfilter/ipt_limit.o

I am not sure if kmod-ipt-layer7 ipt_limit.o is really ipt_layer7,
but you should re-upload the ipkg files and update the control smile

I guess limit=limit and now I am missing still kmod layer7 smile

Hi Blackvel,

sorry for this silly mistake, this is fixed in the 2.4.20-4 kmod-ipt-* series...

Thanks again

--
Nico

Same effect like with our older ipt_layer7.o file.

The WRT reboots after the iptables command
#$IPT -A PREROUTING -t mangle -m layer7 --l7dir /etc/l7-protocols --l7proto edonkey -j MARK --set-mark 0x16

has been setup.

I use ipt_layer7.o + libipt_layer7.o in /usr/lib/iptables.

It makes no difference, if I use any other protocol.

I do not yet use your firmware in the test directory.

Is there a relation to a newer OpenWRT CVS version ?

I am using a WRT V1.1, flash almost filled besides 200 kbytes.

I do not yet use your firmware in the test directory.

You must use the supplied firmware to test it, because the layer7 module extends conntrack'ing data and the netfilter core must be aware of that.
If not, I guess the layer7 module is just (over)writing data somewhere it's not allowed to, causing the reboot.

--
Nico

Nico, I am wondering if you have compiled netfilter conntrack as a kernel module which you can install by ipkg
(you know the *patched* conntrack by layer7).

Looks like ADSL, dynamic IP + NAT table is a bad choice.

For VOIP you have to reload the conntrack table (or reboot the router) once you got a new PPPoE IP and you want to flush old entries
(VOIP SIP entries).

I made the mistake to compile conntrack as included into my very old OpenWRT firmware.

Seems that it is finally the time to upgrade to a newer Linux version (Win2000 crashed grub anyways smile ), compile OpenWRT firmware on my own or use your test .bin file.
I wanted to test layer7 anyways.

For VOIP you have to reload the conntrack table (or reboot the router) once you got a new PPPoE IP and you want to flush old entries
(VOIP SIP entries).

Have you tried playing with /proc/sys/net/ipv4/ip_dynaddr ?

--
Nico

Not yet. I'll check docs.
So is conntrack included in kernel or as a module in your openwrt.bin ? smile

I have tested now ip_dynaddr.
I have restarted rp-pppoe (adsl-stop, adsl-start) and I can tell now, that with ip_dynaddr the packet/connection in conntrack get's not updated.
It uses (internet -> local) for ip_dst still the old ppp0 IP.

I'll move forward and scan google for conntrack dynip workarounds smile

The discussion might have continued from here.