Bug 2166177

Summary: nmap much slower after bz1596834 got fixed in libpcap [rhel7]
Product: Red Hat Enterprise Linux 7 Reporter: Christian Horn <chorn>
Component: nmapAssignee: Martin Osvald 🛹 <mosvald>
Status: CLOSED WONTFIX QA Contact: František Hrdina <fhrdina>
Severity: medium Docs Contact:
Priority: unspecified    
Version: 7.9CC: fhrdina, gdelross
Target Milestone: rcKeywords: Triaged
Target Release: ---Flags: mruprich: needinfo? (gdelross)
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of:
: 2166178 (view as bug list) Environment:
Last Closed: 2023-09-20 07:30:21 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: 2166178    
Bug Blocks:    

Description Christian Horn 2023-02-01 04:50:36 UTC 
Description of problem:
nmap much slower after bz1596834 got fixed in libpcap

Version-Release number of selected component (if applicable):
libpcap-1.5.3-13.el7_9 (last rhel7 version)
Also seen on rhel8, i.e.
libpcap-1.9.1-5.el8

How reproducible:
always

Steps to Reproduce:
1. install rhel7 with libpcap-1.5.3-12.el7 or later, and nmap (any version)
2. while :; do time nmap -n -r -p 1-65535 127.0.0.1 >/dev/null; done

Actual results:
real    0m6.259s
user    0m1.078s
sys     0m0.879s

real    0m6.254s
user    0m1.098s
sys     0m0.863s

Expected results:
real    0m1.150s
user    0m0.176s
sys     0m0.972s

real    0m1.129s
user    0m0.138s
sys     0m0.990s

Additional info:
- This seems to be a regression after implementing bz1596834.
  I recompiled libpcap-1.5.3-13.el7_9 (last rhel7 libpcap) with this change
  in the specfile:
  < export CFLAGS="$RPM_OPT_FLAGS -fno-strict-aliasing"
  > export CFLAGS="$RPM_OPT_FLAGS -fno-strict-aliasing -DHAVE_TPACKET3"
  With that change, the old (desired, low latency) behaviour is restored.
- rhel8.2/8.4/8.6 are also affected (did not test the other versions), above test 
  case takes ~6sec there.
- rhel9 is not affected, ~1sec for the test case
Comment 6 Christian Horn 2023-02-02 00:43:02 UTC 
Right, things seem different here on rhel8.  Recompiling with HAVE_TPACKET3 
does not restore the desired behaviour:

### pristine/unmodified libpcap

[root@rhel8u7a ~]# rpm -q libpcap
libpcap-1.9.1-5.el8.x86_64
[root@rhel8u7a ~]# while :; do time nmap -n -r -p 1-65535 127.0.0.1 >/dev/null; done

real    0m6.179s
user    0m1.037s
sys     0m0.527s

real    0m6.156s
user    0m0.990s
sys     0m0.558s

### Installing custom compiled libpcap

[root@rhel8u7a ~]# rpm -e --nodeps libpcap
[root@rhel8u7a ~]# rpm -i /root/rpmbuild/RPMS/x86_64/libpcap-1.9.1-5.el8_HAVE_TPACKET3.x86_64.rpm
[root@rhel8u7a ~]# while :; do time nmap -n -r -p 1-65535 127.0.0.1 >/dev/null; done

real    0m6.084s
user    0m0.967s
sys     0m0.513s

real    0m6.182s
user    0m1.024s
sys     0m0.532s

[root@rhel8u7a ~]# diff /root/rpmbuild/SPECS/libpcap.spec.org /root/rpmbuild/SPECS/libpcap.spec
4c4
< Release:  5%{?dist}
---
> Release:  5%{?dist}_HAVE_TPACKET3
60c60
< export CFLAGS="$RPM_OPT_FLAGS -fno-strict-aliasing"
---
> export CFLAGS="$RPM_OPT_FLAGS -fno-strict-aliasing -DHAVE_TPACKET3"
[root@rhel8u7a ~]#
Comment 7 Christian Horn 2023-02-28 00:23:14 UTC 
On rhel8, this issue was found due to 2 commits missing from nmap:
https://github.com/nmap/nmap/commit/e48361523b18596c023f565053e56d934fff70bd
https://github.com/nmap/nmap/commit/7e644b391ea16f74dd57f5865be545d514de540d
(details: https://bugzilla.redhat.com/show_bug.cgi?id=2166178#c7 )

Changing component to nmap, assuming this also applies here.

At the moment, it looks like we did not get reports for this issue with
high enough criticality to warrant z-stream fixes, so this one might
stay unfixed in the rhel7 stream.
Comment 10 Martin Osvald 🛹 2023-09-20 07:30:21 UTC 
Given the current stage of RHEL7 and the higher possibility of introducing regression, I am closing this as WONTFIX.