RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Bug 1192143 - nc(1) performs IPv6 connect but doesn't try IPv4 as well
Summary: nc(1) performs IPv6 connect but doesn't try IPv4 as well
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: nmap
Version: 7.0
Hardware: All
OS: Linux
medium
medium
Target Milestone: rc
: ---
Assignee: Michal Hlavinka
QA Contact: Jaroslav Aster
URL:
Whiteboard:
: 1035209 (view as bug list)
Depends On:
Blocks: 1133060 1205796
TreeView+ depends on / blocked
 
Reported: 2015-02-12 16:55 UTC by Robert Scheck
Modified: 2019-08-15 04:15 UTC (History)
11 users (show)

Fixed In Version: nmap-6.40-5.el7
Doc Type: Bug Fix
Doc Text:
Cause: ncat tried to connect only to first address obtained by host name resolution Consequence: if a host had both ipv4 and ipv6 address, ncat would not try the other one when the first one was unreachable Fix: ncat connection code was updated to try all addresses obtained by host name resolution, when some is unreachable Result: ncat is able to connect to a host if some of hosts addresses are unreachable.
Clone Of:
Environment:
Last Closed: 2015-11-19 12:49:15 UTC
Target Upstream Version:
Embargoed:

Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Red Hat Product Errata RHBA-2015:2137 0 normal SHIPPED_LIVE nmap bug fix update 2015-11-19 11:13:18 UTC

Description Robert Scheck 2015-02-12 16:55:54 UTC 
Description of problem:
nc(1) performs IPv6 connect but doesn't try IPv4 as well:

$ cat /etc/hosts
127.0.0.1   localhost localhost.localdomain localhost4 localhost4.localdomain4
::1         localhost localhost.localdomain localhost6 localhost6.localdomain6
$ 

Running "echo STATUS | strace -f nc -w 15 localhost 7071" leads to:

[...]
connect(3, {sa_family=AF_INET6, sin6_port=htons(7071), inet_pton(AF_INET6, "::1", &sin6_addr), sin6_flowinfo=0, sin6_scope_id=0}, 28) = -1 EINPROGRESS (Operation now in progress)
[...]
write(2, "Connection refused.\n", 20Connection refused.
[...]

Without strace(1) it looks like this:

$ echo STATUS | nc -w 15 localhost 7071
Ncat: Connection refused.
$ 

From my point of view that behaviour is wrong, if IPv6 fails an IPv4 connect
should be tried.

Version-Release number of selected component (if applicable):
nmap-ncat-6.40-4.el7.x86_64

How reproducible:
Always, see above and below.

Actual results:
nc(1) performs IPv6 connect but doesn't try IPv4 as well

Expected results:
nc(1) tries IPv4 if IPv6 connection fails with EINPROGRESS.
Comment 1 Robert Scheck 2015-02-12 16:58:19 UTC 
I treat this behaviour as a bug, because nc-1.84-24.el6.x86_64 behaves as
expected (localhost -> ::1 being unavailable leads to 127.0.0.1).
Comment 2 Robert Scheck 2015-02-12 16:59:20 UTC 
Cross-filed case 01359428 on the Red Hat customer portal.
Comment 4 Quanah Gibson-Mount 2015-02-12 17:08:19 UTC 
Specifically, this was caused by RHEL switching out which nc it ships between RHEL6 and RHEL7.  The upstream nmap authors have agreed this is a serious bug (and an oversight on their part) and intend to fix it in a future nc release.  It would be extremely helpful if the fix was backported to RHEL7 once it was available, so that nc will behave correctly, as was the case with the RHEL6 and earlier RHEL releases.
Comment 5 Quanah Gibson-Mount 2015-02-12 21:24:59 UTC 
See also the thread (and patches) here: 

http://seclists.org/nmap-dev/2013/q4/269
Comment 12 Robert Scheck 2015-04-17 10:07:14 UTC 
May somebody let me know the current (technical) status? From what I get
from the support team, there are some issues? Is the issue what I found in
bug #978964 comment #14 (upstream did not reply so far)?
Comment 14 Michal Hlavinka 2015-06-08 15:29:21 UTC 
I still got no answer from upstream, but as upstream agreed with the change (just not the way it was implemented), I think it is just a matter of time before we get some conclusion and a patch in ncat.
Comment 15 Quanah Gibson-Mount 2015-06-08 17:57:06 UTC 
Your faith in their willingness to fix this far exceeds mine.  It appears to have dropped entirely off their radar.  Since RH failed to open an issue upstream, I've gone ahead and done so:

https://github.com/nmap/nmap/issues/157
Comment 16 Robert Scheck 2015-06-08 19:11:12 UTC 
Michal, I think it was really a bad decision (whoever was in charge for that)
to ship the broken nc from nmap in RHEL rather the old OpenBSD port. Why did
this happen at all? And when will this going to be fixed? Support just points
to this RHBZ - and I would like to see this fixed. One might indeed argue that
the old OpenBSD port is not perfect as well, but at least it was working here
at such a basic thing...
Comment 17 Michal Hlavinka 2015-06-10 08:57:20 UTC 
Robert: It happened because it was clear that nmap will stay and it seemed unnecessary to have two netcats. I agree, that old nc would be better suited for needs, use cases and expectations of our users. I can say that if anyone wants old nc back, (s)he should fill standard support request, so management can see that customers want it back. Right now, we are staying with ncat and we will fix some rough edges we find (and upstream agrees with the changes as most of the "fixes" we need are in fact changes of ncat behaviour), but ncat will never be drop in replacement and won't behave the same.
Comment 20 Quanah Gibson-Mount 2015-06-16 16:03:22 UTC 
Updated patch here: http://seclists.org/nmap-dev/2015/q2/92
Comment 21 Michal Hlavinka 2015-06-16 16:39:48 UTC 
I know, that is my email. I updated that patch :)
Comment 23 Michal Hlavinka 2015-07-22 12:50:28 UTC 
*** Bug 1035209 has been marked as a duplicate of this bug. ***
Comment 25 errata-xmlrpc 2015-11-19 12:49:15 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://rhn.redhat.com/errata/RHBA-2015-2137.html
Note You need to log in before you can comment on or make changes to this bug.