Package: iptables
Version: 1.8.3-2
Followup-For: Bug #914694
I've found that iptables 1.8.3-2 fixed #914694 on my systems. I assume
it was an oversight that the bug wasn't marked as fixed yet, so I'm
doing so now.
-- System Information:
Debian Release: 9.9
APT prefers oldstabl
Control: tags -1 upstream
Good and bad news.
The good news is that Florian Westphal from the Netfilter project helped me with
bisecting the git tree to discover which concrete patch fixes the issue, and he
found it:
https://git.netfilter.org/iptables/commit/?id=947c51c95edbbf08d6b3c105177ac5cfa2
On 6/28/19 11:56 AM, Rhonda D'Vine wrote:
> Please don't abuse backports for bugfixes that belong in stable. This
> won't solve the issues for users of stable. Backports is for newer
> features in software, not for offering bugfixes for stable.
>
Perhaps you didn't read my next point? "For imp
On 6/26/19 2:59 PM, Arturo Borrero Gonzalez wrote:
> On 6/26/19 2:28 PM, Thomas Lamprecht wrote:
>> Hmm, but that's a grave issue which may just render the firewall void
>> for _any_ intermediate chain and produces segmentation faults errors.
>>
> The issue you found is not a general-case issue.
>
Control: severity -1 important
On 6/26/19 2:28 PM, Thomas Lamprecht wrote:
>
> Hmm, but that's a grave issue which may just render the firewall void
> for _any_ intermediate chain and produces segmentation faults errors.
>
The issue you found is not a general-case issue.
The segfault is only pr
On 6/26/19 2:14 PM, Arturo Borrero Gonzalez wrote:
> On 6/25/19 10:25 AM, Thomas Lamprecht wrote:
>> Don't want to nag to much but is there any news regarding this?
>> Buster is planned to release pretty soon (<2 weeks) and iptables
>> is quite a important package, IMO. Maybe it went under my radar
On 6/25/19 10:25 AM, Thomas Lamprecht wrote:
> Don't want to nag to much but is there any news regarding this?
> Buster is planned to release pretty soon (<2 weeks) and iptables
> is quite a important package, IMO. Maybe it went under my radar
> but I saw no unblock request on d.o release list.
>
Don't want to nag to much but is there any news regarding this?
Buster is planned to release pretty soon (<2 weeks) and iptables
is quite a important package, IMO. Maybe it went under my radar
but I saw no unblock request on d.o release list.
For now I just used update-alternative to use the legac
iptables 1.8.3-1~exp1 is already uploaded, currently waiting in the NEW queue.
The upload is for experimental, since the build depends on a newer release of
libnftnl (already in experimental), and we are at a point of the Buster freeze
that I would like to make extra sure I'm allowed to push such a
Hi,
Ran into this bug on a custom compiled 5.1.5 kernel.
iptables upstream released version 1.8.3 last week,
which includes the fix mentioned in the previous comment.
Please consider updating the package.
ChenYu
Control: tags -1 pending upstream patch
This seems fixed by this upstream commit:
https://git.netfilter.org/iptables/commit/?id=947c51c95edbbf08d6b3c105177ac5cfa238aade
On Mon, Dec 31, 2018 at 12:31:11PM -0800, Sunil Mohan Adapa wrote:
> On Tue, 27 Nov 2018 14:29:40 -0500 Eric Garver wrote:
> [...]
> > That makes it smell like an iptables-restore issue in the nftables
> > backed version of iptables. It would be great if we could reproduce
> > without firewalld us
On Tue, 27 Nov 2018 14:29:40 -0500 Eric Garver wrote:
[...]
> That makes it smell like an iptables-restore issue in the nftables
> backed version of iptables. It would be great if we could reproduce
> without firewalld using iptables-restore.
A much simpler way I reproduced the problem with iptab
Hi,
Thank you for investigating the bug. I have more information:
firewalld
=
After firewalld's rules are loaded for the first time, flushing them
fails. This happens during shutdown or during startup if the rules are
already present due to unclean shutdown. Output of `firewalld --nofork
ernal via the direct/passthrough interface (e.g. docker, libvirt).
>
> I collected some more info here:
>
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=914694#10
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=914694#15
>
> In short, these take docker and libvir
more info here:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=914694#10
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=914694#15
In short, these take docker and libvirt out of the game, it happens with pure
kernel 4.18 (same version works on Fedora, fails on Debian) + iptables-nft
1.8.2 (F29
On Mon, Nov 26, 2018 at 03:49:36PM +0100, Michael Biebl wrote:
> Hi Eric,
>
> I recently switched firewalld back to iptables given the feedback in
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=909574
>
> This seems to have caused a regression.
> Does this specific problem ring a bell?
No.
Hi Eric,
I recently switched firewalld back to iptables given the feedback in
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=909574
This seems to have caused a regression.
Does this specific problem ring a bell?
Regards,
Michael
Am 26.11.18 um 12:30 schrieb Martin Pitt:
> Package: firewalld
Hello again,
another observation: In Fedora 29, firewalld also defaults to the iptables
backend, and I get the same error noise in "systemctl status firewalld". But
"--reload" works.
The main differences that I can see is:
* kernel: 4.18 on Debian unstable, 4.19.2 on Fedora 29
* iptables: 1.8.
Hello again,
I now downloaded our previous debian-testing image, where the failure does not
happen. This has the same kernel, docker, and libvirt version, and firewalld
0.6.3-1. Upgrading just firewalld to 0.6.3-3 introduces this regression.
Presumably upstream now only tests with nftables, and th
Package: firewalld
Version: 0.6.3-3
Severity: important
A recent regression in Debian testing broke firewalld. This is on a stock
Debian-testing system, without a custom kernel, custom firewall configs, etc.
-- just a plain "apt install firewalld". However, it does have libvirt and
docker.io insta
21 matches
Mail list logo
