Bug 1262826 - ncat: Assertion `0' failed. on ICMP type 12 (Parameter problem)
ncat: Assertion `0' failed. on ICMP type 12 (Parameter problem)
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: nmap (Show other bugs)
Unspecified Linux
medium Severity medium
: rc
: ---
Assigned To: Pavel Zhukov
Jiri Jaburek
: EasyFix, FastFix, Patch
Depends On:
  Show dependency treegraph
Reported: 2015-09-14 08:27 EDT by Jiri Jaburek
Modified: 2017-09-27 23:24 EDT (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of:
Last Closed:
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Jiri Jaburek 2015-09-14 08:27:04 EDT
Description of problem:

When nc receives ICMP type 12 (any code) as a result of a connection attempt, it aborts with

$ nc 1234
Strange connect error from (71): Protocol errornc: nsock_core.c:368: handle_connect_result: Assertion `0' failed.


On a remote machine (server), not loopback, may be network namespace:


from scapy.all import *

iface = "eth0"

def callback(p):
    if not p.haslayer(Ether):
    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)

and try connecting from the local machine as shown above.

Version-Release number of selected component (if applicable):

How reproducible:

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 1234
Strange connect error from (71): Protocol error
Comment 1 Jiri Jaburek 2015-09-14 12:02:14 EDT
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.
Comment 2 Daniel Miller 2017-03-17 16:35:25 EDT
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:
Comment 3 Daniel Miller 2017-03-20 13:22:36 EDT
Complete error handling was added in upstream r36653.

Note You need to log in before you can comment on or make changes to this bug.