Support for layer7,classify, tos, ipset in netfilter/iptables

[GoogleCodeExporter]

Enhancement idea: Support for more recent netfilter/iptables.
I don't know if there is some kernel dependence (so that with 2.4.x kernels
only older versions would work), if not maybe newer version could be added
to firmware (and to modules).

Original issue reported on code.google.com by ecadd...@gmail.com on 13 May 2009 at 11:55

[GoogleCodeExporter]

Please tell what you expect in "more recent netfilter/iptables" exactly? Which
version? Why 1.3.8 isn't enough?

P.S. Please, don't convince us that new version is always better than older!

Original comment by lly.dev on 13 May 2009 at 12:32

• Added labels: Priority-Low
• Removed labels: Priority-Medium

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

I'm actually looking for support of e.g. the following line:
iptables -t mangle -A PREROUTING  -m layer7 --l7proto ... -j CLASSIFY 
--set-class x:y

I understand that the l7 filter is not part of the standard nefilter modules 
and it
may have some 2.6.x kernel dependence.
I also know that l7 can be processor intensive so before the l7 match there 
would be
some other -m match to save on CPU time (if that works).

If that can be done done with 1.3.8 that's fine me as well.

Original comment by ecadd...@gmail.com on 13 May 2009 at 3:23

[GoogleCodeExporter]

layer7 already present in source tree, but never be tested. And it consume much 
space
in firmware, even without patterns. Moreover, I'm not iptables guru and haven't
enough time to study it :(

In case of you want to test it - you should build custom firmware with
CONFIG_IP_NF_MATCH_LAYER7=y in kernel.config

Original comment by lly.dev on 13 May 2009 at 4:04

[GoogleCodeExporter]

OK, thanks. l7 filter would be used in module, hopefully not impacting firmware 
size
too much.

Do you have some description (preferable in English) where it's described how to
create the environment and build custom firmware?
Once I've built vsftpd on the router. It was not too fast, but working.
If I could use Linux on PC to build the firmware that would be though the best.

Original comment by ecadd...@gmail.com on 13 May 2009 at 7:02

[GoogleCodeExporter]

Have you look at wiki ? ;)

http://code.google.com/p/wl500g/wiki/CompilingCustomFirmware_en

P.S. At the worst, I can compile firmware for you, but remember that you have to
explore iptables yourself.

Original comment by lly.dev on 13 May 2009 at 7:10

[GoogleCodeExporter]

size of ipt_layer7.o is 20064 bytes, ipt_CLASSIFY.o is only 2380 bytes

Original comment by v...@orient-96.ru on 14 May 2009 at 8:33

[GoogleCodeExporter]

I agree to include this modules to firmware, but they have to be tested before 
this.

Original comment by lly.dev on 15 May 2009 at 6:10

[GoogleCodeExporter]

Thanks for the link, I've missed it somehow.
Having quite limited time, so far I've manged to download only the 
sources/tools (it
was really slow).

If you include modules, could you please include also the TRACE target? So far 
I have
not used it but maybe it can help testing.

Original comment by ecadd...@gmail.com on 15 May 2009 at 11:02

[GoogleCodeExporter]

Unfortunately TRACE target (XT_TARGET_TRACE) exists in 2.6 kernel tree only. 
And I
don't know is somebody backport it to 2.4.

btw., You didn't point your router model!

Original comment by lly.dev on 15 May 2009 at 11:10

• Changed title: Support for layer7,classify in netfilter/iptables

[GoogleCodeExporter]

Router is 500gPv1

Original comment by ecadd...@gmail.com on 15 May 2009 at 12:31

[GoogleCodeExporter]

From the matches it would be good to have also:
connbytes, connlimit (more important)
time, u32 (less important)

Are these depending also on 2.6 kernel?

I promise: no more netfilter wishes ;-)

The following examples (all of them working in Fedora), give the following 
result in
the rotuer:

iptables -t mangle -A PREROUTING -p tcp --dport 80 -m connbytes --connbytes 
524288:
--connbytes-dir both --connbytes-mode bytes -j MARK --set-mark 4
iptables: No chain/target/match by that name

iptables -A INPUT -p tcp --dport 80 -m connbytes --connbytes 524288: 
--connbytes-dir
both --connbytes-mode bytes -j DROP
iptables: No chain/target/match by that name

iptables -A INPUT -p tcp --syn --dport 22 -m connlimit --connlimit-above  2 -j 
REJECT
iptables v1.3.8: Couldn't load match `connlimit':File not found

Try `iptables -h' or 'iptables --help' for more information.T -p tcp --syn 
--dport 22
-m connlimit --connlimit-above 2 -j REJECT

Original comment by ecadd...@gmail.com on 15 May 2009 at 6:09

[GoogleCodeExporter]

I've built new firmware and it has created WL500gp-1.9.2.7-d-r285.trx in 
../broadcom/src/gateway/mipsel-uclibc

If I'd like to include some more kernel options, is the
broadcom/src/linux/linux-2.4.37.1/.config
that I have to edit?

Based on what's available in 2.4 kernel I'd like to have the following options:
#
#   IP: Netfilter Configuration
#
CONFIG_IP_NF_MATCH_CONNBYTES=m
CONFIG_IP_NF_MATCH_IPRANGE=m
CONFIG_IP_NF_MATCH_TOS=m
CONFIG_IP_NF_MATCH_DSCP=m
CONFIG_IP_NF_MATCH_LAYER7=m
CONFIG_IP_NF_TARGET_TOS=m
CONFIG_IP_NF_TARGET_CLASSIFY=m

#
# QoS and/or fair queueing
#
CONFIG_NET_SCH_DSMARK=m
CONFIG_NET_CLS_TCINDEX=m

Would it be possible that you also include these in new release?
Do these require new iptables version as well?

Original comment by ecadd...@gmail.com on 16 May 2009 at 7:05

[GoogleCodeExporter]

>If I'd like to include some more kernel options, is the
broadcom/src/linux/linux-2.4.37.1/.config that I have to edit?

Yes, after edit you should issue

make koldconf

and then ordinary make && make install

>Would it be possible that you also include these in new release?

Maybe. It depends to amount of people which like to have this feature, since we 
have
very limited space in flash for 4Mb devices.

>Do these require new iptables version as well?
>connbytes, connlimit (more important)
>time, u32 (less important)

connbytes - you found it ;-)
connlimit - we should to find proper patch for it in patch-o-matic
time      - it already working (ipt_time)
u32       - no, it not exists for 2.4 kernels

Original comment by lly.dev on 18 May 2009 at 7:04

• Changed title: Support for layer7,classify,connlimit in netfilter/iptables
• Changed state: Started

[GoogleCodeExporter]

It seems to be that connlimit patch duplicates functionality of iplimit target,
please check.

Original comment by lly.dev on 18 May 2009 at 10:28

• Changed title: Support for layer7,classify in netfilter/iptables

[GoogleCodeExporter]

Yes, for many practical purposes the iplimit match would bring equal 
functionality I
guess though connlimit seems to have more options (i.e. --connlimit-mask; I 
guess
iplimit is the predecessor of connlimit).

What's bad about this, that configuration becomes less portable because of the 
naming
(i.e. making testing also more complicated).

I'll continue with the custom firmware building (I have only time here and 
there for
this) but the best would be if you could include more useful nefilter/iptables 
stuff
via modules. The trouble with own firmware that if you add corrections to the
releases I have to repeat this exercise release by release. (Also if something 
is
readily available more people are willing/can take into use than if they have to
build their own firmware...)

I don't count too much on many people wishing for these functions (at lease not 
yet).
Rather as these are not visible via Web interface most people are unaware even 
of
their existence.

How close is the current firmware to 4MB flash limit? I guess even when 
supported via
modules it will increase firmware size but is the 4MB limit very close?

Original comment by ecadd...@gmail.com on 18 May 2009 at 12:27

[GoogleCodeExporter]

Well, in 2.6 iplimit replaced with connlimit (the real difference is in 
processing
TIME_WAIT connections). By default, in iptables 1.3.8, we have an extension 
named
"iplimit" only, but it can be easy migrated to "connlimit" due to identical 
structures.
Are you sure that modifications above should be done?

Currently, I don't want to turn connbytes on for all people, since this may 
affect
performance (it requires CONFIG_IP_NF_CT_ACCT).
QoS (NET_SCH_DSMARK, NET_CLS_TCINDEX) will not packed to main .trx, so this can 
be
safely added for all.
All other small modules (IP_NF_MATCH_IPRANGE, IP_NF_MATCH_TOS, IP_NF_MATCH_DSCP,
IP_NF_TARGET_TOS, IP_NF_TARGET_CLASSIFY) requires to turn they on in iptables
extensions, so it WILL increase firmware size, and I want to be sure that 
features
will be used not only by you.

Maximum size for firmware in 4Mb devices is about 3800 Kb, i.e. we have spare 
near to
32Kb in squashfs. But we want to include 3g/4g/cdma functionality to firmware,
requested by many people, and this require much space :(

Original comment by lly.dev on 18 May 2009 at 1:17

[GoogleCodeExporter]

OK, understood.
It's a pity that 8MB flash routers (also having more RAM and more powerful CPU)
suffer from this 4MB flash limitation (and as SW is bound to grow, it's 
expected to
suffer more and more in future) but it seems reasonable that xg/CDDMA has higher
priority (not to me, but probably more people are interested in this what I've
brought up in this issue).

Don't take then too much of your time with iplimit->connlimit modification. 
It's just
one building block, so alone it does not make much difference.

I'm hoping now that one day this 4MB flash limitation can be overcome. I guess 
when
this router was designed 4MB flash was regarded as decent size...

Original comment by ecadd...@gmail.com on 18 May 2009 at 2:32

[GoogleCodeExporter]

Maybe someday we prepare separate builds for 4/8 Mb routers.

Now, let's prioritize this issue:
1. layer7   - public release after you confirm that it is works.
2. CLASSIFY, TOS - in firmware for all
3. NET_SCH_DSMARK, NET_CLS_TCINDEX as separate modules for all
4. All other - in your custom build

Agree?

Original comment by lly.dev on 18 May 2009 at 4:56

[GoogleCodeExporter]

OK. but I cannot do a complete l7 testing.
So far I've built the new firmware (in fact I've added a few more options; as
building it for myself why to restrict it...) and made the upgrade.
At least it has booted etc. No sign of obvious failure.

I've did this with my spare HW and as I'd like to minimize disturbance for the 
NW
usage maybe I have to create a separate environment for the testing. This may 
take
some time.

One question: Is it possible to mix modules from r276 and r285 (kernel version 
seems
to be the same)? If not, this will further complicate things as I have to 
duplicate
also USB storage...

Original comment by ecadd...@gmail.com on 18 May 2009 at 6:40

[GoogleCodeExporter]

Nobody do a 100% complete tests ;-) 

About modules - yes. As you mentioned, kernel version is the same, and was no 
global
patches on kernel.

Original comment by lly.dev on 18 May 2009 at 6:48

[GoogleCodeExporter]

btw, we need to specify kernel modules included in the fw vs outside modules
this will be require changes in еру Makefile.diff

Original comment by v...@orient-96.ru on 18 May 2009 at 7:00

[GoogleCodeExporter]

themiron:

Unfortunately, I didn't find pretty solution (i.e. without many manual changes 
every
time we enable/disable module) yet.

Original comment by lly.dev on 19 May 2009 at 7:05

[GoogleCodeExporter]

solution is to have a list of included/not included modules used in Makefile 
while 
installing to target/lib

Original comment by v...@orient-96.ru on 19 May 2009 at 7:17

[GoogleCodeExporter]

themiron:

1) We have to have iptables extensions libraries in /usr/lib/iptables even for
external(not included in .trx) now. I don't know easy solution for this, "mount 
-o
bind" choice only. IPTABLES_LIB_DIR env. variable may not working good for 
post-* scripts

2) Ideally, we should have a list of excluded modules only.

ecaddict:

I've done points 2,3 (Comment 19) at r287, you move ;-)

Original comment by lly.dev on 20 May 2009 at 8:51

• Changed title: Support for layer7,classify, tos in netfilter/iptables

[GoogleCodeExporter]

Do I need to rebuild the firmware with r287?
I'm struggling to get it working (with r285), e.g.:

iptables -t mangle -A POSTROUTING -m layer7 --l7dir /opt/etc/l7-protocols 
--l7proto
bittorrent 
-j CLASSIFY --set-class 1:4
iptables v1.3.8: Unknown arg `--set-class'
Try `iptables -h' or 'iptables --help' for more information.

Does it mean that I have to load also some iptables (that is not netfilter) 
modules?

Similarly:
iptables -t mangle -A chktos -p tcp -m length --length 0:512 -j RETURN
iptables v1.3.8: Couldn't load match `length':File not found

Try `iptables -h' or 'iptables --help' for more information.

At least netfilter modules are there (relevant part of lsmod):
lsmod
    Tainted: P  
ipt_length               472   0 (unused)
ipt_layer7             10968   0 (unused)
ipt_CLASSIFY             856   0 (unused)
ipt_recent              8424   4

This is what's in /usr/lib/iptables:
 ls -la /usr/lib/iptables
total 296
-rwxr-xr-x 1 admin root  6632 May 18 20:05 libipt_CONNMARK.so
-rwxr-xr-x 1 admin root  7716 May 18 20:05 libipt_DNAT.so
-rwxr-xr-x 1 admin root  4836 May 18 20:05 libipt_IMQ.so
-rwxr-xr-x 1 admin root  8172 May 18 20:05 libipt_LOG.so
-rwxr-xr-x 1 admin root  6356 May 18 20:05 libipt_MARK.so
-rwxr-xr-x 1 admin root  6016 May 18 20:05 libipt_MASQUERADE.so
-rwxr-xr-x 1 admin root  4200 May 18 20:05 libipt_MIRROR.so
-rwxr-xr-x 1 admin root  6104 May 18 20:05 libipt_NETMAP.so
-rwxr-xr-x 1 admin root  7392 May 18 20:05 libipt_POOL.so
-rwxr-xr-x 1 admin root  6160 May 18 20:05 libipt_REDIRECT.so
-rwxr-xr-x 1 admin root  7008 May 18 20:05 libipt_REJECT.so
-rwxr-xr-x 1 admin root  7892 May 18 20:05 libipt_SET.so
-rwxr-xr-x 1 admin root  7684 May 18 20:05 libipt_SNAT.so
-rwxr-xr-x 1 admin root  4348 May 18 20:05 libipt_TARPIT.so
-rwxr-xr-x 1 admin root  5348 May 18 20:05 libipt_TCPMSS.so
-rwxr-xr-x 1 admin root  6024 May 18 20:05 libipt_TTL.so
-rwxr-xr-x 1 admin root  6844 May 18 20:05 libipt_autofw.so
-rwxr-xr-x 1 admin root  5248 May 18 20:05 libipt_condition.so
-rwxr-xr-x 1 admin root  7128 May 18 20:05 libipt_connbytes.so
-rwxr-xr-x 1 admin root  5552 May 18 20:05 libipt_connmark.so
-rwxr-xr-x 1 admin root 11540 May 18 20:05 libipt_conntrack.so
-rwxr-xr-x 1 admin root  8628 May 18 20:05 libipt_icmp.so
-rwxr-xr-x 1 admin root  5708 May 18 20:05 libipt_iplimit.so
-rwxr-xr-x 1 admin root 10916 May 18 20:05 libipt_layer7.so
-rwxr-xr-x 1 admin root  6752 May 18 20:05 libipt_limit.so
-rwxr-xr-x 1 admin root  5668 May 18 20:05 libipt_mac.so
-rwxr-xr-x 1 admin root  5472 May 18 20:05 libipt_mark.so
-rwxr-xr-x 1 admin root 10620 May 18 20:05 libipt_multiport.so
-rwxr-xr-x 1 admin root  7464 May 18 20:05 libipt_nth.so
-rwxr-xr-x 1 admin root  7480 May 18 20:05 libipt_pool.so
-rwxr-xr-x 1 admin root  6716 May 18 20:05 libipt_psd.so
-rwxr-xr-x 1 admin root  4944 May 18 20:05 libipt_quota.so
-rwxr-xr-x 1 admin root  5500 May 18 20:05 libipt_random.so
-rwxr-xr-x 1 admin root  9052 May 18 20:05 libipt_recent.so
-rwxr-xr-x 1 admin root  7392 May 18 20:05 libipt_set.so
-rwxr-xr-x 1 admin root  4296 May 18 20:05 libipt_standard.so
-rwxr-xr-x 1 admin root  6248 May 18 20:05 libipt_state.so
-rwxr-xr-x 1 admin root  8864 May 18 20:05 libipt_string.so
-rwxr-xr-x 1 admin root 10528 May 18 20:05 libipt_tcp.so
-rwxr-xr-x 1 admin root  6040 May 18 20:05 libipt_tcpmss.so
-rwxr-xr-x 1 admin root  8300 May 18 20:05 libipt_time.so
-rwxr-xr-x 1 admin root  7344 May 18 20:05 libipt_udp.so

echo $IPTABLES_LIB_DIR

gives empty string, setting it does not seem to help.

Can you please help how to proceed?

Original comment by ecadd...@gmail.com on 20 May 2009 at 8:04

[GoogleCodeExporter]

>Do I need to rebuild the firmware with r287?

Seems to be, yes. Alternatively, you should enable iptables extensions 
"CLASSIFY",
"length" by editing variable PF_EXT_SLIB in 
gateway/iptables/extensions/Makefile file.

Original comment by lly.dev on 21 May 2009 at 8:05

[GoogleCodeExporter]

Can you please do some basic testing (as you have already the firmware and
the earliest when I can continue is half day)?

There is a good practical description (that's what I was also using):
http://blog.edseek.com/~jasonb/articles/traffic_shaping/
Chapter 8 has very good real life examples (especially for very asymmetrical
uplink/downlink connections like ADSL), and the most of it can be directly used
for testing.

The protocol definitions can be fetched:
http://sourceforge.net/project/showfiles.php?group_id=80085
everything from /protocols directory of tgz has to be copied to 
/opt/etc/l7-protocols
(after creating the directory).

So my test sequence where I've tried if basics are working:

# vlan1 is actually what `nvram get wan_ifname` gives so it can be also ppp0

# removes all QoS stuff e.g. wondershaper
tc qdisc del dev vlan1 root    2> /dev/null > /dev/null
tc qdisc del dev vlan1 ingress 2> /dev/null > /dev/null

insmod ipt_layer7
insmod ipt_CLASSIFY
insmod ipt_length

tc qdisc add dev vlan1 root handle 1:0 htb
tc class add dev vlan1 parent 1:0 classid 1:1 htb rate 800kbit

tc class add dev vlan1 parent 1:1 classid 1:2 htb rate 100kbit ceil 320kbit
tc class add dev vlan1 parent 1:1 classid 1:3 htb rate 600kbit ceil 800kbit
tc class add dev vlan1 parent 1:1 classid 1:4 htb rate 700kbit ceil 800kbit

# this fails
iptables -t mangle -A POSTROUTING -m layer7 --l7dir /opt/etc/l7-protocols 
--l7proto
bittorrent -j CLASSIFY --set-class 1:4

iptables -t mangle -N chktos
# this fails, I've got this far
iptables -t mangle -A chktos -p tcp -m length --length 0:512 -j RETURN
# from this point I've not even tried
iptables -t mangle -A chktos -m limit --limit 2/s --limit-burst 10 -j RETURN
iptables -t mangle -A chktos -j TOS --set-tos Maximize-Throughput
iptables -t mangle -A chktos -j RETURN
iptables -t mangle -A POSTROUTING -p tcp -m tos --tos Minimize-Delay -j chktos

Original comment by ecadd...@gmail.com on 21 May 2009 at 8:43

[GoogleCodeExporter]

Ok, I will try it this evening.

Original comment by lly.dev on 21 May 2009 at 9:20

[GoogleCodeExporter]

In r292 all above completed successfully. But you forgot to load two modules:

insmod ipt_TOS
insmod ipt_tos

Original comment by lly.dev on 21 May 2009 at 3:55

[GoogleCodeExporter]

I've built r292 from extracting source part (just to be on the safe side) and 
loaded
to router.

Looks promising. Now I'll start the real testing. Do you have some release plan 
(so
when I'm supposed to be ready with the testing)?

Original comment by ecadd...@gmail.com on 21 May 2009 at 8:21

[GoogleCodeExporter]

There is no hard deadline, so if it will take no longer than one week, it's 
good.

Moreover, since layer7 is useless without protocol patterns (which can't be 
included
in FW), I have plans to move ipt_layer7.o to external modules archive.

Original comment by lly.dev on 22 May 2009 at 6:53

[GoogleCodeExporter]

Moving out ipt_layer7 or even other modules is quite OK. In fact most people are
better off if something is moved out to external storage than if it's 
completely missing.

These modules are making sense also only with 8MB flash routers not because of 
flash
size but also other routers have too little memory/slow CPU to use most of the
functions anyway.

I was very happy to see that you have also included connbytes/connlimit to
/usr/lib/iptables
but when I tried to insert connbytes this is what I've got:

insmod ipt_connbytes
insmod: cannot insert 'ipt_connbytes.o': Operation not permitted

and then I've noticed that ipt_connbytes exist on USB disk only because it has
remained there from my previous build (this time I've not added any netfilter
modules, I've built just like you specified).

Could this be added as well? (In my view this is also an important module as it
allows reclassifying bulk data from interactive just by seeing the amount of 
data
transferred).
Anyhow this is not a show stopper for my testing as I'll make a new kernel 
config and
firmware.

I'm very thankful to you that actually this is possible.

Original comment by ecadd...@gmail.com on 22 May 2009 at 12:38

[GoogleCodeExporter]

1) connbytes can't work in case of it turned off in kernel .config !

2) busybox's insmod don't search modules on USB disk, only modprobe does. You 
should
define full path, i.e. issue:

insmod /opt/lib/modules/2.4.37.1/kernel/net/ipv4/netfilter/ipt_connbytes.o

3) Connbytes depends from accounting and it adds extra code to conntrack 
counters and
increase ip_conntrack structure size. Since it used rarely (you are the first), 
I'm
not sure that it should be added for all people

Original comment by lly.dev on 22 May 2009 at 1:07

[GoogleCodeExporter]

Sorry insmod was wrong like you mentioned. Everything is OK.

Original comment by ecadd...@gmail.com on 22 May 2009 at 2:13

[GoogleCodeExporter]

The multiport match does not seem to work iptables -m multiport -h gives:
multiport v1.3.8 options:
 --source-ports port[,port,port...]
 --sports ...
                match source port(s)
 --destination-ports port[,port,port...]
 --dports ...
                match destination port(s)
 --ports port[,port,port]
                match both source and destination port(s)
 NOTE: this kernel does not support port ranges in multiport.

Even though lsmod lists it:
lsmod
    Tainted: P  
ipt_multiport            888   0

I could not get it work (commands just for check, not real life examples; first 
3
tested and working in Fedora):
iptables -A INPUT -p tcp -m multiport --dports 20,21 -j ACCEPT
iptables: Invalid argument

iptables -A OUTPUT -p tcp -m multiport --dports 20,21,25,80,443 -j ACCEPT
iptables: Invalid argument

iptables -t mangle -A POSTROUTING -p tcp -m multiport --ports 20,21 -j CLASSIFY
--set-class 1:4
iptables: Invalid argument

# this is wrong, just to check if any change in output
iptables -A POSTROUTING -p tcp -m multiport --ports 80,443,53 -j ACCEPT
iptables: No chain/target/match by that name

Original comment by ecadd...@gmail.com on 24 May 2009 at 8:21

[GoogleCodeExporter]

Seems to be multiport target is broken, thanks for detailed report. It will 
take some
time to repair it.

Original comment by lly.dev on 25 May 2009 at 6:35

[GoogleCodeExporter]

r302 should fix "multiport" match.

Original comment by lly.dev on 25 May 2009 at 3:50

[GoogleCodeExporter]

Thank you for the quick correction. Fix seems to work, I continue my testing 
with
this version (but I've also included connbytes in my version).

Original comment by ecadd...@gmail.com on 26 May 2009 at 9:18

[GoogleCodeExporter]

Continuing my testing I've tried to check matches (as many as possible) that 
exist in
some form in r302 and found the following issues:
iptables -m ttl -h 
iptables v1.3.8: Couldn't load match `ttl':File not found

Try `iptables -h' or 'iptables --help' for more information.

ls -la /usr/lib/iptables does not list libipt_ttl.so
but /2.4.37.1/kernel/net/ipv4/netfilter has 2048 May 25 22:28 ipt_ttl.o

iptables -m helper -h 
iptables v1.3.8: Couldn't load match `helper':File not found

Try `iptables -h' or 'iptables --help' for more information.

No /usr/lib/iptables/libipt_helper.so but /2.4.37.1/kernel/net/ipv4/netfilter 
has
ipt_helper.o

So there seem to be some orphan matches (that could be removed or need some 
additions
to work):

-m ttl, missing library in /usr/lib/iptables but has kernel module
 Would be nice to have it

-m helper, missing library in /usr/lib/iptables but has kernel module
 matches packets related to a specific conntrack-helper, I don't know if needed or not

-m set, has library in /usr/lib/iptables but kernel module is missing (?)
Looks promising for high performance firewalls but the rest of the framework is
missing or maybe I'm missing something...
http://ipset.netfilter.org/tips.html
http://nfws.inl.fr/nfws_userday/Jozsef-Kadlecsik_IPset.pdf

My current lsmod coverage:
  Tainted: P  
ipt_helper               744   0 (unused)
ipt_nth                 1152   1
ipt_condition           1600   1
ipt_random               856   1
ipt_quota                712   1
ipt_TTL                 1112   0 (unused)
ipt_ttl                  664   0 (unused)
ipt_string              3376   2
ipt_multiport           1016   1
ipt_connbytes           1408   1
ipt_TOS                 1144   3
ipt_tos                  472   2
ipt_length               520   3
ipt_CLASSIFY             904   2
ipt_layer7             11016   2
ipt_recent              8424   4

Original comment by ecadd...@gmail.com on 26 May 2009 at 2:56

[GoogleCodeExporter]

1) -m ttl    - library added in r303
2) -m helper - module removed in r303

3) -m set - kernel module exists, but never be tested (at least, they can be
compiled) and it has version 2, not latest 3. You have to 
  a) enable kernel module CONFIG_IP_NF_SET=m and submodules
  b) download & cross compile ipset package:
        I) edit Makefile & replace KERNEL_DIR with proper path
       II) issue "make binaries CC=mipsel-linux-gcc"
      III) copy *.so to /usr/local/lib/ipset on router
       IV) place somewhere ipset binary

P.S. As I can see, ipset is a big package and can't be fit in main FW. Moreover,
kernel part of it should be upgraded to actual 3.0 version. It will take some 
time

Original comment by lly.dev on 26 May 2009 at 4:38

[GoogleCodeExporter]

OK, I'll continue with r303.
In my view ipset is something very promising but at the moment I cannot devote 
the
time that would be needed for a deeper check (maybe after I'm over with the 
current
testing). Let's hope that in the near future it will be better integrated to 
the kernel.

Original comment by ecadd...@gmail.com on 26 May 2009 at 4:46

[GoogleCodeExporter]

Fortunately, ipset has support of 2.4 kernel line & provide automated kernel
patching. So, find new version in r306 :-)

User part of ipset you have compile as in Comment #41
All tests from bundle completed successfully on my router!

Original comment by lly.dev on 26 May 2009 at 5:43

[GoogleCodeExporter]

OK, I'll continue with r306 (build was OK).
Just question: Build has created these libipset files:
  9645 2009-05-26 21:50 libipset_iphash.so
 11040 2009-05-26 21:50 libipset_ipmap.so
 11825 2009-05-26 21:50 libipset_ipporthash.so
 11773 2009-05-26 21:50 libipset_ipportiphash.so
 13086 2009-05-26 21:50 libipset_ipportnethash.so
  9391 2009-05-26 21:50 libipset_iptreemap.so
  9202 2009-05-26 21:50 libipset_iptree.so
 11173 2009-05-26 21:50 libipset_macipmap.so
 10758 2009-05-26 21:50 libipset_nethash.so
  8783 2009-05-26 21:50 libipset_portmap.so
  9231 2009-05-26 21:50 libipset_setlist.so

The sum of these files is > 64K
Is it possible to save it to flash with
flashfs save && flashfs commit && flashfs enable?
Or do I need to copy it every time after boot?

Btw, what points to /usr/local/lib/ipset (directory didn't even exist before, 
so I
had to create it)?

Original comment by ecadd...@gmail.com on 26 May 2009 at 8:01

[GoogleCodeExporter]

As you have WL500gpV1 - limit of flashfs much greater than 64K.

About /usr/local/lib/ipset - or you have to create new directory, or you should 
to
change PREFIX in ipset's Makefile, for example:

 make binaries CC=mipsel-linux-gcc PREFIX=/opt

libraries will be search in /opt/lib/ipset

Original comment by lly.dev on 27 May 2009 at 6:27

• Changed title: Support for layer7,classify, tos, ipset in netfilter/iptables

[GoogleCodeExporter]

OK, thanks. This is very good news.
I've read about this limit in the old Oleg custom firmware page 
(oleg.wl500g.info).
It has just occurred to me that maybe that page could be updated as well to 
point the
new firmware development.

Is there some way to figure out how much space can be used from flash to 
/usr/local
(and what happens if that is tried to be exceeded by mistake)?
In this way some of the modules could also be placed there and the rest would be
linked...

Original comment by ecadd...@gmail.com on 27 May 2009 at 7:05

[GoogleCodeExporter]

About flashfs: 64K was true for an old firmwares. Unfortunately, there is no
user-friendly way to determine free space for flashfs. For gp V1/V2 it is near 
to
3.8Mb. In case of too big image, "flashfs commit" would fail.

Original comment by lly.dev on 27 May 2009 at 7:41

[GoogleCodeExporter]

The reason for my longer than usual silence is that even though trying, I could 
not
find any issues.
In my view iptables/netfilter is in a very good and consistent shape now.

A big thanks for the excellent job you've done.

Of course, I could not do a complete testing but it's running stable on my box
without any glitches so I think it's safe to add it to next release. Also in the
coming 2 days I'm not next to the router so I have to stop testing now.

I've checked in most of the cases with iptables-save -c/usual Linux tools if the
functionality is also OK not just that rules can be added/deleted etc.

My coverage of the modules now (relevant part of the lsmod):
 Tainted: P  
ip_set_ipmap            2716   1
ipt_ttl                  664   1
ipt_tos                  472   2
ipt_string              3424   2
ipt_set                 1116   1
ipt_random               856   1
ipt_quota                712   1
ipt_psd                42928   0 (unused)
ipt_nth                 1152   1
ipt_multiport           1016   1
ipt_length               520   3
ipt_layer7             11016   2
ipt_connbytes           1408   1
ipt_condition           1600   1
ipt_TTL                 1112   1
ipt_TOS                 1144   3
ipt_TARPIT              2424   2
ipt_SET                 1324   1
ipt_MIRROR              1480   0 (unused)
ipt_IMQ                  840   1
ipt_CLASSIFY             904   2
ip_set                 20632   1 [ip_set_ipmap ipt_set ipt_SET]
ipt_recent              8424   5

As a future enhancement (if/when bigger routers can have bigger firmware/more 
complex
features) it would be nice to add connbytes as well.

Original comment by ecadd...@gmail.com on 28 May 2009 at 2:43

[GoogleCodeExporter]

Thank you very much for deep testing.

Original comment by lly.dev on 28 May 2009 at 5:03

• Changed state: Fixed

[GoogleCodeExporter]

Original comment by lly.dev on 14 Sep 2009 at 12:49

• Changed state: Verified