Bug 1679228

Summary: [s390x] arptables not reporting src/dst ip addresses
Product: Red Hat Enterprise Linux 8 Reporter: Tomas Dolezal <todoleza>
Component: iptablesAssignee: Phil Sutter <psutter>
Status: CLOSED ERRATA QA Contact: Tomas Dolezal <todoleza>
Severity: high Docs Contact:
Priority: high    
Version: 8.1CC: iptables-maint-list, todoleza
Target Milestone: rcFlags: pm-rhel: mirror+
Target Release: ---   
Hardware: s390x   
OS: Unspecified   
Whiteboard:
Fixed In Version: iptables-1.8.2-10.el8 Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2019-11-05 22:17:45 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: 1682316    
Bug Blocks: 1689408, 1701002    

Description Tomas Dolezal 2019-02-20 16:17:12 UTC
Description of problem:
source and destination address is omited in arptables -L and arptables-save commands.
nft ruleset is identical to one produced on x86_64 so it seems to be just presentation issue (and save issue as well)

Version-Release number of selected component (if applicable):
iptables-arptables-1.8.2-8.el8.s390x
kernel-4.18.0-67.el8.s390x

How reproducible:
always

Steps to Reproduce:
[root@ibm-z-118 arptables-smoketest]# arptables -N mychain
[root@ibm-z-118 arptables-smoketest]# arptables -A mychain -s 1.2.3.4 -j ACCEPT
[root@ibm-z-118 arptables-smoketest]# arptables -A mychain -s 1.2.3.4 -d 255.255.255.255 -j ACCEPT
[root@ibm-z-118 arptables-smoketest]# arptables -A mychain -s 1.2.3.4 -d 255.255.255.255/25 -j ACCEPT
[root@ibm-z-118 arptables-smoketest]# echo $?
0
[root@ibm-z-118 arptables-smoketest]# nft list ruleset
table arp filter {
	chain INPUT {
		type filter hook input priority 0; policy accept;
	}

	chain OUTPUT {
		type filter hook output priority 0; policy accept;
	}

	chain mychain {
		arp htype 1 arp hlen 6 arp plen 4 @nh,112,32 16909060 counter packets 0 bytes 0 accept
		arp htype 1 arp hlen 6 arp plen 4 @nh,112,32 16909060 @nh,192,32 4294967295 counter packets 0 bytes 0 accept
		arp htype 1 arp hlen 6 arp plen 4 @nh,112,32 16909060 @nh,192,32 & 4294967168 == 4294967168 counter packets 0 bytes 0 accept
	}
}
[root@ibm-z-118 arptables-smoketest]# arptables -L -v
Chain INPUT (policy ACCEPT 0 packets, 0 bytes)

Chain OUTPUT (policy ACCEPT 0 packets, 0 bytes)

Chain mychain (0 references)
-j ACCEPT -i any -o any --h-length 0, pcnt=0 -- bcnt=0 
-j ACCEPT -i any -o any --h-length 0, pcnt=0 -- bcnt=0 
-j ACCEPT -i any -o any --h-length 0, pcnt=0 -- bcnt=0 

[root@ibm-z-118 arptables-smoketest]# arptables-save
*filter
:INPUT ACCEPT
:OUTPUT ACCEPT
:mychain -
-A mychain -j ACCEPT --h-length 0
-A mychain -j ACCEPT --h-length 0
-A mychain -j ACCEPT --h-length 0

Actual results:
-s IP -d IP are missing in rules

Expected results:
# arptables-save
*filter
:INPUT ACCEPT
:OUTPUT ACCEPT
:mychain -
-A mychain -j ACCEPT -s 1.2.3.4
-A mychain -j ACCEPT -s 1.2.3.4 -d 255.255.255.255
-A mychain -j ACCEPT -s 1.2.3.4 -d 255.255.255.128/25

Additional info:

Comment 1 Phil Sutter 2019-02-26 18:49:07 UTC
Upstream commit to backport:

commit d68672a641439b72bccfcb39d50f26fe3f915c19
Author: Florian Westphal <fw>
Date:   Fri Feb 22 13:26:05 2019 +0100

    arptables-nft: fix decoding of hlen on bigendian platforms
    
    The existing test fail with:
    extensions/libarpt_standard.t: ERROR: line 2 (cannot find: arptables -I INPUT -s 192.168.0.1)
    
    ... because hlen is 0 instead of expected "6".
    The rule is correct, i.e. this is a decode/display bug: arp_hlen is
    specified as 'unsigned short' instead of uint8_t.
    
    On LSB systems, this doesn't matter but on MSB the value then is '0x600'
    instead of '0x006' which becomes 0 when assignment to the u8 header field.
    
    Signed-off-by: Florian Westphal <fw>
    Acked-by: Phil Sutter <phil>

Comment 7 errata-xmlrpc 2019-11-05 22:17:45 UTC
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHEA-2019:3573