Bug 2166178
| Summary: | nmap much slower after bz1596834 got fixed in libpcap [rhel8] | ||
|---|---|---|---|
| Product: | Red Hat Enterprise Linux 8 | Reporter: | Christian Horn <chorn> |
| Component: | nmap | Assignee: | Martin Osvald 🛹 <mosvald> |
| Status: | CLOSED ERRATA | QA Contact: | František Hrdina <fhrdina> |
| Severity: | medium | Docs Contact: | |
| Priority: | unspecified | ||
| Version: | 8.2 | CC: | fhrdina, mosvald, mruprich, rhel-cs-infra-services-qe |
| Target Milestone: | rc | Keywords: | AutoVerified, Triaged |
| Target Release: | --- | Flags: | pm-rhel:
mirror+
|
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Fixed In Version: | nmap-7.92-1.el8 | Doc Type: | If docs needed, set a value |
| Doc Text: | Story Points: | --- | |
| Clone Of: | 2166177 | Environment: | |
| Last Closed: | 2023-11-14 15:25:49 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: | 2166177 | ||
|
Description
Christian Horn
2023-02-01 04:56:26 UTC
Issue verified to be on rhel8.2/8.4/8.6, probably all rhel8 affected. Issue does not exist on rhel9. Removing regression keyword, as it seems like it had this behaviour all along inside rhel8 (just inside rhel7 it got slower). So I am still trying to figure out why nmap is slower but seems to me like TPACKET_V3 is not the one to blame. Just checking this with gdb on RHEL-8.8.0: # dnf debuginfo-install libpcap nmap ... # gdb nmap ... 1. I test it with a breakpoint on pcap_read_linux_mmap_v2 from libpcap: (gdb) b pcap_read_linux_mmap_v2 Function "pcap_read_linux_mmap_v2" not defined. Make breakpoint pending on future shared library load? (y or [n]) y Breakpoint 1 (pcap_read_linux_mmap_v2) pending. (gdb) run -n -r -p 1-65535 127.0.0.1 Starting program: /usr/bin/nmap -n -r -p 1-65535 127.0.0.1 [Thread debugging using libthread_db enabled] Using host libthread_db library "/lib64/libthread_db.so.1". Starting Nmap 7.70 ( https://nmap.org ) at 2023-02-23 10:11 EST Nmap scan report for 127.0.0.1 Host is up (0.0000020s latency). Not shown: 65532 closed ports PORT STATE SERVICE 22/tcp open ssh 111/tcp open rpcbind 8081/tcp open blackice-icecap Nmap done: 1 IP address (1 host up) scanned in 5.04 seconds [Inferior 1 (process 5963) exited normally] 2. add a breakpoint for pcap_read_linux_mmap_v3: (gdb) b pcap_read_linux_mmap_v3 Breakpoint 2 at 0x7ffff791e120: file ./pcap-linux.c, line 5566. (gdb) info b Num Type Disp Enb Address What 1 breakpoint keep y 0x00007ffff791e410 in pcap_read_linux_mmap_v2 at ./pcap-linux.c:5480 2 breakpoint keep y 0x00007ffff791e120 in pcap_read_linux_mmap_v3 at ./pcap-linux.c:5566 (gdb) run -n -r -p 1-65535 127.0.0.1 Starting program: /usr/bin/nmap -n -r -p 1-65535 127.0.0.1 [Thread debugging using libthread_db enabled] Using host libthread_db library "/lib64/libthread_db.so.1". Starting Nmap 7.70 ( https://nmap.org ) at 2023-02-23 10:13 EST Breakpoint 2, pcap_read_linux_mmap_v3 (handle=0x555555fc0900, max_packets=1, callback=0x7ffff7918f00 <pcap_oneshot_mmap>, user=0x7fffffffc8b0 "@\311\377\377\377\177") at ./pcap-linux.c:5566 5566 { So libpcap IS using TPACKET_V3, otherwise the call for mmap_v3 would not be available. Just tested nmap-7.91 on RHEL8 and look at the results: Starting Nmap 7.91 ( https://nmap.org ) at 2023-02-23 11:07 EST Nmap scan report for 127.0.0.1 Host is up (0.0000020s latency). Not shown: 65532 closed ports PORT STATE SERVICE 22/tcp open ssh 111/tcp open rpcbind 8081/tcp open blackice-icecap Nmap done: 1 IP address (1 host up) scanned in 0.47 seconds <----------- I will discuss this with my colleague who owns nmap and see what we can do here. It doesn't look like libpcap problem. Perf tool does show very low cpu time usage for libpcap.so.1.9.1 routines. I built upstream nmap 9.80 and the problem isn't there (RHEL9 has nmap 7.91): ~~~ [root@ci-vm nmap-7.80]# time ./nmap -n -r -p 1-65535 127.0.0.1 >/dev/null real 0m0.404s user 0m0.111s sys 0m0.179s [root@ci-vm nmap-7.80]# ~~~ Therefore switching this to nmap component. (In reply to Martin Osvald 🛹 from comment #4) ... > usage for libpcap.so.1.9.1 routines. I built upstream nmap 9.80 and the made a typo - 7.80 instead of 9.80 These changes should be fixing the issue: o [GH#1291][GH#34][GH#1339] Use pcap_create instead of pcap_live_open in Nmap, and set immediate mode on the pcap descriptor. This solves packet loss problems on Linux and may improve performance on other platforms. [Daniel Cater, Mike Pontillo, Daniel Miller] Manually checked out&built&tested that with the below upstream commit the issue is gone: https://github.com/nmap/nmap/commit/e48361523b18596c023f565053e56d934fff70bd The below commit is also needed: https://github.com/nmap/nmap/commit/7e644b391ea16f74dd57f5865be545d514de540d mosvald++ Based on criticality this was so far reported via support, I think for rhel8 a fix in an upcoming minor release seems to be sufficient. full list of patches needed to fix this: https://github.com/nmap/nmap/commit/7f1485f56d30572e59eb3a7dd345c38226d221f8 https://github.com/nmap/nmap/commit/7e644b391ea16f74dd57f5865be545d514de540d https://github.com/nmap/nmap/commit/d6a04c465e536623598e980c6771c1dd9f8c7f95 https://github.com/nmap/nmap/commit/e48361523b18596c023f565053e56d934fff70bd clean backport, CI tests passed so granting devel_ack. 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 (nmap bug fix and enhancement update), 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/RHBA-2023:6913 |