Bug 1192143
Summary: | nc(1) performs IPv6 connect but doesn't try IPv4 as well | ||
---|---|---|---|
Product: | Red Hat Enterprise Linux 7 | Reporter: | Robert Scheck <redhat-bugzilla> |
Component: | nmap | Assignee: | Michal Hlavinka <mhlavink> |
Status: | CLOSED ERRATA | QA Contact: | Jaroslav Aster <jaster> |
Severity: | medium | Docs Contact: | |
Priority: | medium | ||
Version: | 7.0 | CC: | aiyengar, andrey.ivanov, codong, fred.passos, jaster, mhlavink, ovasik, phil, quanah, robert.scheck, tzheng |
Target Milestone: | rc | ||
Target Release: | --- | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | |||
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.
|
Story Points: | --- |
Clone Of: | Environment: | ||
Last Closed: | 2015-11-19 12:49:15 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: | 1133060, 1205796 |
Description
Robert Scheck
2015-02-12 16:55:54 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). Cross-filed case 01359428 on the Red Hat customer portal. 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. See also the thread (and patches) here: http://seclists.org/nmap-dev/2013/q4/269 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. 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. Updated patch here: http://seclists.org/nmap-dev/2015/q2/92 I know, that is my email. I updated that patch :) *** Bug 1035209 has been marked as a duplicate of this bug. *** 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 |