Downloading http://downloads.openwrt.org/whiterussian/packages/iptables-utils_1.3.3-2_mipsel.ipk ...
Connecting to downloads.openwrt.org (195.56.146.238:80)
Done.
Unpacking iptables-utils...Done.
Configuring iptables-utils...Done.
root@WAN:~# iptables-save
# Generated by iptables-save v1.3.3 on Thu May 15 00:00:13 2008
*nat
:PREROUTING ACCEPT [10099:1475430]
:POSTROUTING ACCEPT [515:89227]
:OUTPUT ACCEPT [1230:225485]
Can't find library for match `tcp'
-A PREROUTING -d 85.191.0.241 -p tcp root@WAN:~#
_________________ Asus RT16N + OTRW
Kingston 4GB USB-disk 128 MB swap + 1.4GB ext3 on /opt + 2 GB ext3 on /mnt
Copperjet 1616 modem in ZipB-config
Asterisk, pixelserv & Pound running on router
Another Asus RT16N as WDS-bridge
This shows a change to get iptables-save/restore working - pointing to /usr/sbin
And lo, if you look in /usr/sbin you can find iptables-restore, but not iptables-save. However, the iptables-restore is just a symblink to iptables - so did this :
cd /jffs/usr/bin
ln -s /jffs/usr/sbin/iptables ./iptables-save
./iptables-save
...and lo, output! :)
Not sure why the symblink isn't present in the final release, but it's working if you do the above :)
I can also confirm iptables-restore appears to do nothing for the mega build 13525 (on a WRT54GSv1).
That's unfortunate because it means iptables added via the web GUI to {Administration / Commands, Save Firewall} must work with existing rules and deleting rules by line number is dicey due to later releases or the use of GUI actions that have iptables side-effects.
((I found this out after I wrote a startup script to save and restore a compressed, uuencoded fw rules in nvram. Ironic that the working variant is the one that has a missing link.))
Unrelated to save/restore, after some hair pulling, I found that:
iptables produces NO ERROR Messages, you must check ret code status to see if it did not like your arguments!
It must be checked with "echo $?" on the command line:
good show
Thanks for this investigative work...
I suspected there was something like an iptables-save as the file /tmp/.ipt is in that format. But that could have been for other reasons....
I just don't understand the post about iptables-restore not working. I'm already using it in my asiablock.
There was however a problem (which is fixed now) with the .prewall / rc_firewall / .if-up rules running simultaneously. This means the iptables-restore runs into an error whilst some other program (iptables) is managing the tables.
Could it be that problem? _________________ Asus RT16N + OTRW
Kingston 4GB USB-disk 128 MB swap + 1.4GB ext3 on /opt + 2 GB ext3 on /mnt
Copperjet 1616 modem in ZipB-config
Asterisk, pixelserv & Pound running on router
Another Asus RT16N as WDS-bridge
The iptables-restore worked, except for square-backeted counter values (I copied text to emacs buffers and used it to diff buffers).
A few comments:
* 'iptables-save -c' does not clear the square-backeted counters (non-zero [999,999]
* echo $? after iptables-restore was 255, but it seemed to work correctly. _________________ a trio of WRT54GSv1
I found that the bug (iptables-restore returns error 255) is still here (tested on DD-WRT 15452M NEWD-2 K2.6 Eko).
In my case, I have problems with "TRIGGER"-lines, wich are produced by iptables-save:
-A PREROUTING -d 111.222.33.44 -j TRIGGER --trigger-proto --trigger-match 0-0 --trigger-relate 0-0
Shoud be:
-A PREROUTING -d 111.222.33.44 -j TRIGGER
I think error 255 is because of the current version of ipt_TRIGGER, wich is unable to parse arguments (--trigger-proto --trigger-match 0-0 --trigger-relate 0-0).
I use this command to save iptables instead of iptables-save:
Code:
iptables-save | sed 's/--trigger-match 0-0//g' | sed 's/--trigger-relate 0-0//g' | sed 's/--trigger-proto\s*//g' > /tmp/fw_state