Bug 2036873

Summary:	cki test fail: DNAT unknown option "--to-destination"
Product:	[Fedora] Fedora	Reporter:	yiche <yiche>
Component:	iptables	Assignee:	Phil Sutter <psutter>
Status:	CLOSED RAWHIDE	QA Contact:	Fedora Extras Quality Assurance <extras-qa>
Severity:	high	Docs Contact:
Priority:	unspecified
Version:	36	CC:	kevin, psutter
Target Milestone:	---
Target Release:	---
Hardware:	Unspecified
OS:	Unspecified
Whiteboard:
Fixed In Version:	iptables-1.8.7-16.fc37	Doc Type:	If docs needed, set a value
Doc Text:		Story Points:	---
Clone Of:
Clones:	2060408 (view as bug list)		Environment:
Last Closed:	2022-03-03 13:19:44 UTC	Type:	Bug
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:
Bug Depends On:
Bug Blocks:	2060408, 2060459, 2103988

Comment 6 Ben Cotton 2022-02-08 21:16:31 UTC

This bug appears to have been reported against 'rawhide' during the Fedora 36 development cycle.
Changing version to 36.

Comment 10 Phil Sutter 2022-02-18 15:23:57 UTC

Patches to backport:

commit 6dafb6c2d207321ec9dd7901afbdd3eead5783a0
Author: Phil Sutter <phil>
Date:   Fri Feb 11 17:39:24 2022 +0100

    libxtables: Register only the highest revision extension
    
    When fully registering extensions, ignore all consecutive ones with same
    name and family value. Since commit b3ac87038f4e4 ("libxtables: Make
    sure extensions register in revision order"), one may safely assume the
    list of pending extensions has highest revision numbers first. Since
    iptables is only interested in the highest revision the kernel supports,
    registration and compatibility checks may be skipped once the first
    matching extension in pending list has validated.

commit 8c2c8d2121a9f173efc935713c22081804fd506a (HEAD -> upstream)
Author: Phil Sutter <phil>
Date:   Fri Feb 11 17:47:22 2022 +0100

    Improve error messages for unsupported extensions
    
    If a given extension was not supported by the kernel, iptables would
    print a rather confusing error message if extension parameters were
    given:
    
    | # rm /lib/modules/$(uname -r)/kernel/net/netfilter/xt_LOG.ko
    | # iptables -A FORWARD -j LOG --log-prefix foo
    | iptables v1.8.7 (legacy): unknown option "--log-prefix"
    
    Avoid this by pretending extension revision 0 is always supported. It is
    the same hack as used to successfully print extension help texts as
    unprivileged user, extended to all error codes to serve privileged ones
    as well.
    
    In addition, print a warning if kernel rejected revision 0 and it's not
    a permissions problem. This helps users find out which extension in a
    rule the kernel didn't like.
    
    Finally, the above commands result in these messages:
    
    | Warning: Extension LOG revision 0 not supported, missing kernel module?
    | iptables: No chain/target/match by that name.
    
    Or, for iptables-nft:
    
    | Warning: Extension LOG revision 0 not supported, missing kernel module?
    | iptables v1.8.7 (nf_tables):  RULE_APPEND failed (No such file or directory): rule in chain FORWARD

Comment 11 Phil Sutter 2022-03-03 11:15:02 UTC

(In reply to Phil Sutter from comment #10)
> Patches to backport:

I was a bit too quick there. The actual upstream commits are:

2dbb49d15fb44 ("libxtables: Register only the highest revision extension")
17534cb18ed0a ("Improve error messages for unsupported extensions")