Posted: Sun Mar 08, 2015 21:48 Post subject: ipset working on r7000
Hello,
I managed to get ipset/iptables working on the r7000 kong builds with kernel 3.10.
The attached file contains the needed iptables v1.4.16.3 libraries, application, and xt_set module.
It also contains the ipset v6.21.1 application and libmnl v1.0.3 library.
The only module needed is xt_set since all needed kernel parts for ipset and iptables are already built-in.
To test, extract the tar in /jffs/usr, then
Code:
insmod /jffs/usr/lib/modules/xt_set.ko
ipset -N IPTEST hash:ip
ipset -A IPTEST 8.8.8.8
ipset -A IPTEST 8.8.4.4
ipset -N NETTEST hash:net
ipset -A NETTEST 4.2.2.0/24
Check that the new sets are correct with
Code:
ipset -L
then
Code:
cd /jffs/usr/sbin
./iptables -A OUTPUT -m set --match-set IPTEST dst -j DROP
./iptables -A OUTPUT -m set --match-set NETTEST dst -j DROP
Any attempts to ping
8.8.8.8
8.8.4.4
4.2.2.1 ... 4.2.2.4
should fail
nahdude,
if you make important changes or updates would you mind updating your original post?
That way when someone comes along to research/follow you, he/she wont have to read through pages of updates.
Thank you
Mike _________________ Router currently owned:
Netgear R7800 - Router
Netgear R7000 - AP mode
awesome thanks. Was hoping ipset would have been added to the base distro. Was looking at entware but ipset was missing from package list.
*edit All that was missing were a few symlinks for ip6tables, save & restore. Don't know if you could update tar for other future users
I set it up off of /jffs/usr and works very well so far in testing.
JAMESMTL,
Thanks for the feedback.
The attachment now includes the ipv6 symlinks.
Also, the iptables-xml symlink now points to /jffs/usr and I updated the original post to use /jffs/usr instead of /jffs/opt.
I'm guessing from your sig that you had a chance to test ipv6 sets. Do you know if both ipv6 net and ip sets are working? I currently don't have ipv6 set up to test.
If they do, I would like to update the original post with ipv6 instructions.
nahdude,
if you make important changes or updates would you mind updating your original post?
That way when someone comes along to research/follow you, he/she wont have to read through pages of updates.
Thank you
Mike
Mike,
No problem and thanks for adding it to the sticky.
Hopefully soon I will update the post to include an expanded tutorial for those who aren't familiar with powerful ipset!
Joined: 13 Mar 2014 Posts: 856 Location: Montreal, QC
Posted: Mon Mar 09, 2015 20:28 Post subject:
@ nahdude
IPv6 net and ip sets work just fine. Been running my geoblock overnight using ipset with no issues.
The only issue I ran into in testing was not ipset related but rather iptables related, specifically iptables-save/restore. ddwrt's included iptables supports certain netfilter functions not available in the updated iptables.
Ex
# iptables-save > /tmp/iptables.test
Can't find library for target `TRIGGER'
For this reason you may want to think about removing the iptables-save/restore symlinks or adding a warning in original post to avoid user issues.
Also users using ipset should be aware that listing iptables rules using the built in iptables will see unknown match set for ipset rules created with the updated iptables
Ex. UNKNOWN match `set'
this also applies to listing base rules using the updated iptables
Ex. [16 bytes of unknown target data]
Neither of these issues affects ipset functionality but is just visiually inconsistent when running both versions of iptables.
Hopefully one day BS will update iptables to a current release.
IPv6 net and ip sets work just fine. Been running my geoblock overnight using ipset with no issues.
The only issue I ran into in testing was not ipset related but rather iptables related, specifically iptables-save/restore. ddwrt's included iptables supports certain netfilter functions not available in the updated iptables.
Ex
# iptables-save > /tmp/iptables.test
Can't find library for target `TRIGGER'
For this reason you may want to think about removing the iptables-save/restore symlinks or adding a warning in original post to avoid user issues.
Also users using ipset should be aware that listing iptables rules using the built in iptables will see unknown match set for ipset rules created with the updated iptables
Ex. UNKNOWN match `set'
this also applies to listing base rules using the updated iptables
Ex. [16 bytes of unknown target data]
Neither of these issues affects ipset functionality but is just visiually inconsistent when running both versions of iptables.
JAMESMTL,
I managed to compile iptables v1.4.16.3 with the TRIGGER target. As far as I can tell, this is the last version that's able to be patched with it.
Besides TRIGGER, the previous version I posted was also missing the 'recent' match which is now working.
Joined: 13 Mar 2014 Posts: 856 Location: Montreal, QC
Posted: Tue Mar 10, 2015 8:52 Post subject:
Did a quick test with latest iptables build and recent & trigger showing but conntrack state seems to be missing from iptables view. Iptables-save errors end out with IMQ module on the test router. I'll try and do deeper testing tomorrow.
Honestly though I'm not too concerned about iptables-save as it's not part of base distro anyways. What's important for anyone going this route is ipset functionality.
Did a quick test with latest iptables build and recent & trigger showing but conntrack state seems to be missing from iptables view. Iptables-save errors end out with IMQ module on the test router. I'll try and do deeper testing tomorrow.
Honestly though I'm not too concerned about iptables-save as it's not part of base distro anyways. What's important for anyone going this route is ipset functionality.
JAMESMTL,
I finally have iptables v1.4.16.3 working with all the extensions needed for dd-wrt, save/restore is also working.
The built in iptables v1.3.7 uses the obsolete 'state' match and not conntrack, that's why they weren't displaying correctly.
Fortunately v1.4.16.3 can still take a deprecated command like
-I INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
On boot, the built in version will always restore from /tmp/.ipt, which uses -m state --state. Therefore when using the newer version to list/save/restore, those rules using -m state will be jacked up unless the newer version is used during boot up.
Another big difference between the versions is 1.3.7 uses intrapositioned negation ( -i ! vlan2) as opposed to extrapositioned ( ! -i vlan2). v1.4.16.3 is strict about this.
I made an image from kongs r26450 r7000 firmware that has 1.4.16.3 as the built in version. I had to patch the file responsible for creating /tmp/.ipt (firewall.c) so it uses the correct negation. It includes ipset and working save/restore. Minidlna was removed.
Posted: Fri Jun 03, 2016 4:07 Post subject: Any updates to this?
I've literally spent all day reading every thread containing IPSET with hopes of finding one like this.
There's some code that's supposed to build a portal for Netflix to use so no more proxy/vpn errors.... But it takes IPSET support. I have an R7000 with DD-WRT v3.0-r29580M kongac. After a 2 hour chat session with Netflix, they were less than helpful in providing me with the necessary information to create the portal on my router.
Soooo.... I'm hoping this module might work, cuz my router is running great and I don't want to go the Tomato route.
IPv6 net and ip sets work just fine. Been running my geoblock overnight using ipset with no issues.
The only issue I ran into in testing was not ipset related but rather iptables related, specifically iptables-save/restore. ddwrt's included iptables supports certain netfilter functions not available in the updated iptables.
Ex
# iptables-save > /tmp/iptables.test
Can't find library for target `TRIGGER'
For this reason you may want to think about removing the iptables-save/restore symlinks or adding a warning in original post to avoid user issues.
Also users using ipset should be aware that listing iptables rules using the built in iptables will see unknown match set for ipset rules created with the updated iptables
Ex. UNKNOWN match `set'
this also applies to listing base rules using the updated iptables
Ex. [16 bytes of unknown target data]
Neither of these issues affects ipset functionality but is just visiually inconsistent when running both versions of iptables.
JAMESMTL,
I managed to compile iptables v1.4.16.3 with the TRIGGER target. As far as I can tell, this is the last version that's able to be patched with it.
Besides TRIGGER, the previous version I posted was also missing the 'recent' match which is now working.
Using save/restore should now be clean.
Hello there! I do not know how you include `TRIGGER target` this module?
Posted: Sat Jun 18, 2016 22:46 Post subject: Re: Any updates to this?
SmallvilleLA wrote:
I've literally spent all day reading every thread containing IPSET with hopes of finding one like this.
There's some code that's supposed to build a portal for Netflix to use so no more proxy/vpn errors.... But it takes IPSET support. I have an R7000 with DD-WRT v3.0-r29580M kongac. After a 2 hour chat session with Netflix, they were less than helpful in providing me with the necessary information to create the portal on my router.
Soooo.... I'm hoping this module might work, cuz my router is running great and I don't want to go the Tomato route.
Posted: Sun Nov 13, 2016 17:36 Post subject: Compatibility?
Hey, whenever I try to load the xt_set.ko module (insmod /jffs/usr/lib/modules/xt_set.ko) i'm getting a 'Segmentation fault' response. Is that a compatibility issue with my router?
Router: Linksys WRT1200AC
Build: v3.0-r30805 (10/27/16)
Kernel: Linux 3.18.42 #102 SMP Fri Oct 14 01:08:44 CEST 2016 armv7l
Posted: Sun Dec 11, 2016 23:09 Post subject: xt_set.ko compatible with Linux 4.4.36 kernel?
Hi,
I have been using ipset but when I recently upgraded to DD-WRT v3.0-r30910M kongac (12/02/16), I found that the xt_set.ko module is incompatible. This version of dd-wrt runs Linux 4.4.36 (armv7l). Does anyone have a version of the module that is compatible with this kernel?
