Note: This bug is displayed in read-only format because
the product is no longer active in Red Hat Bugzilla.
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.
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.
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.
Cross-filed case 01359428 on the Red Hat customer portal.
Comment 4Quanah 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 5Quanah Gibson-Mount
2015-02-12 21:24:59 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)?
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 15Quanah 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
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...
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 20Quanah Gibson-Mount
2015-06-16 16:03:22 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
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.