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.
Description of problem:
When nc receives ICMP type 12 (any code) as a result of a connection attempt, it aborts with
$ nc 1.2.3.4 1234
Strange connect error from 1.2.3.4 (71): Protocol errornc: nsock_core.c:368: handle_connect_result: Assertion `0' failed.
Aborted
Reproducer:
On a remote machine (server), not loopback, may be network namespace:
-----------------------8<-------------------------
#!/usr/bin/python
from scapy.all import *
iface = "eth0"
def callback(p):
if not p.haslayer(Ether):
return
r = Ether(src=p[Ether].dst,dst=p[Ether].src)/IP(dst=p[IP].src)/ICMP(type=12,code=1)/p[IP]
sendp(r, iface=iface)
sniff(prn=callback, iface=iface, filter="tcp dst port 1234", store=0)
-----------------------8<-------------------------
and try connecting from the local machine as shown above.
Version-Release number of selected component (if applicable):
nmap-ncat-6.40-7.el7.x86_64
How reproducible:
always
Actual results:
nc aborts with Assertion failed
Expected results:
nc reports a connection error without abort
Additional info:
This seems to be fixed on my nmap-ncat-6.47-2.fc22.x86_64:
$ nc 1.2.3.4 1234
Strange connect error from 1.2.3.4 (71): Protocol error
Forgot to mention - the remote machine must ignore the TCP SYN and let the scapy script reply, something like
iptables -I INPUT -p tcp -m tcp --dport 1234 -j DROP
should be sufficient.
This is a bug in the underlying Nsock library (same codebase), so it also affects Nmap and possibly Nping. The immediate fix is easy: add EPROTO to the list of errors handled. But I'm soliciting comments on potentially treating all non-success cases the same, eliminating this problem in the future, should some other platform or kernel version choose to return yet another error number. Discussion thread: http://seclists.org/nmap-dev/2017/q1/216
Regardless of approach, this will be fixed in the next upstream Ncat release. Here's the quick patch that solves this particular issue if Red Hat needs it sooner:
diff --git a/nsock/src/nsock_core.c b/nsock/src/nsock_core.c
index b8aa352..567f1e9 100644
--- a/nsock/src/nsock_core.c
+++ b/nsock/src/nsock_core.c
@@ -359,6 +359,7 @@ void handle_connect_result(struct npool *ms, struct nevent *nse, enum nse_status
case ETIMEDOUT:
case EHOSTDOWN:
case ECONNRESET:
+ case EPROTO:
#ifdef WIN32
case WSAEADDRINUSE:
case WSAEADDRNOTAVAIL:
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://access.redhat.com/errata/RHBA-2018:0661
Description of problem: When nc receives ICMP type 12 (any code) as a result of a connection attempt, it aborts with $ nc 1.2.3.4 1234 Strange connect error from 1.2.3.4 (71): Protocol errornc: nsock_core.c:368: handle_connect_result: Assertion `0' failed. Aborted Reproducer: On a remote machine (server), not loopback, may be network namespace: -----------------------8<------------------------- #!/usr/bin/python from scapy.all import * iface = "eth0" def callback(p): if not p.haslayer(Ether): return r = Ether(src=p[Ether].dst,dst=p[Ether].src)/IP(dst=p[IP].src)/ICMP(type=12,code=1)/p[IP] sendp(r, iface=iface) sniff(prn=callback, iface=iface, filter="tcp dst port 1234", store=0) -----------------------8<------------------------- and try connecting from the local machine as shown above. Version-Release number of selected component (if applicable): nmap-ncat-6.40-7.el7.x86_64 How reproducible: always Actual results: nc aborts with Assertion failed Expected results: nc reports a connection error without abort Additional info: This seems to be fixed on my nmap-ncat-6.47-2.fc22.x86_64: $ nc 1.2.3.4 1234 Strange connect error from 1.2.3.4 (71): Protocol error