Hi
On Mon, Dec 17, 2018 at 10:01:10PM +0100, Nico Haase wrote:
Hi Gustavo,
I'm sorry, but I still don't get it completely.
Am 16.12.2018 um 02:31 schrieb gustavo panizzo:
Is not a parsing problem, the CHAINs do not exists.
You need to check your setup. Check where the ip6*tables* symlinks
points to and make it consistent.
ip6tables-save points to /usr/sbin/ip6tables-nft-save, the version
string is ip6tables-save v1.8.2 (nf_tables). ip6tables-restore points
to /usr/sbin/ip6tables-nft-restore, which is of the same version
v1.8.2. I've never touched these symlinks on my own.
Also remove the legacy rules before applying new rules.
if ip{,6}tables-save and ip{,6}tables-restore dont work in your system,
netfilter-persistent won't work either (is just a wrapper around them to
start the firewall at boot time)
Yeah, and that is still my point of asking here: how can it be
possible that dumping the rules and importing with tools from the same
package with the same version throws an error? Shouldn't the process
to write the rules generate a file that is sound and can be restored?
as an iptables user i know the process to save and restore is sound, but
the runtime environment (ipsets, dns resolution, kernel modules) may not
be the same when rules are saved and restored, making the restore to fail.
This doesn't sound like your case (you are saving and loading
the rules right after) but is worth mentioning.
Is it possible that there are incompatibilities with other parts? For
example, I'm running the kernel version 4.4.134.
I can reproduce your issues with a 4.4 kernel, but not with 4.1[8-9]
kernel.
root@testing-vm:~# ip6tables-restore < /etc/iptables/rules.v6
ip6tables-restore v1.8.2 (nf_tables):
line 3: CHAIN_UPDATE failed (No such file or directory): chain
PREROUTING
line 4: CHAIN_UPDATE failed (No such file or directory): chain INPUT
line 5: CHAIN_UPDATE failed (No such file or directory): chain OUTPUT
line 6: CHAIN_UPDATE failed (No such file or directory): chain
POSTROUTING
root@testing-vm:~# cat /etc/iptables/rules.v6
# Generated by ip6tables-save v1.6.2 on Wed Oct 24 06:16:46 2018
*nat
:PREROUTING ACCEPT [0:0]
:INPUT ACCEPT [0:0]
:OUTPUT ACCEPT [0:0]
:POSTROUTING ACCEPT [0:0]
COMMIT
# Completed on Wed Oct 24 06:16:46 2018
# Generated by ip6tables-save v1.6.2 on Wed Oct 24 06:16:46 2018
*filter
:INPUT ACCEPT [0:0]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [0:0]
COMMIT
# Completed on Wed Oct 24 06:16:46 2018
root@testing-vm:~# uname -a
Linux testing-vm 4.4.0-1-amd64 #1 SMP Debian 4.4.6-1 (2016-03-17) x86_64
GNU/Linux
root@testing-vm:~# dpkg -l iptables
Desired=Unknown/Install/Remove/Purge/Hold
|
Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend
|/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad)
||/ Name Version Architecture Description
+++-==============-============-============-=================================================
ii iptables 1.8.2-2 amd64 administration tools for
packet filtering and NAT
maybe iptables is missing a Breaks between its current version
and kernels < 4.18 but other iptables functions appear to work fine, if
you think a Breaks is required, please reassign this bug to iptables.
This is not something I can fix or workaround in netfilter-persistent.
I'm sorry to keep asking questions rather than providing a solution on
my own, but I'm not that experienced with iptables. I've seen it
apologies if this comes out being rude (is not my intention), but if you are
not experienced with iptables perhaps you'd be better served by a higher
level tool.
If you intend to learn iptables :) discard my previous comment but learn
nftables instead.
throwing an error during an update and this looks like a bug to me.
if you are tracking testing or unstable the update probably updated
more packages at the same time, check dpkg logs (/var/log/dpkg.log*)
I'd be very happy if you could guide me to the neccessary steps of
providing more information to inspect this.
I imagine you are stuck in an old kernel because hw support, if that's
the case I'd not recommend to track testing/unstable on that machine but
stable.
but this is just personal opinion outside my maintainer duties
try to upgrade the kernel or downgrade iptables to stable's version.
Regards
Nico
--
IRC: gfa
GPG: 0X44BB1BA79F6C6333
