New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

ncat not closing connection after remote end does.. #1413

Open
anotherlink opened this Issue Dec 14, 2018 · 3 comments

Comments

Projects
None yet
2 participants
@anotherlink
Copy link

anotherlink commented Dec 14, 2018

hi there,

ncat keeps the connection open after the remote end closes it... ( tested: TCP and unix connections )

i have just compiled the current verison from git (dd75a8f) on debian sid to verify that the issue still exists, and it does.. TCP/IP example:

shell-1 ~> nc -l -p 1342
foo
^C⏎

shell-2 ~> nc local 1342
foo

^-- stays open..

unix domain socket example:

photon@w520 ~> nc -U /tmp/.n/s/53BNMpXBtETx_5xqiZcwlQ
>:]
close
ACK connection closed

^-- should have been closed now, stays open as well..

socat and the 'original' netcat behave as expected in all those cases, example:

photon@w520 ~> socat - tcp:127.0.0.1:242
>:]
close
ACK connection closed
photon@w520 ~>

^-- closed as expected..

..greetinx and thanks for the great work! : )
--photon

@dmiller-nmap

This comment has been minimized.

Copy link

dmiller-nmap commented Dec 17, 2018

It's hard to say what is "correct" in many of these cases, though we strive for compatibility with traditional and OpenBSD netcats. Here's some documentation of known cases that may help you out: Ncat/EOF behavior on SecWiki.

I'm not closing this yet, though: I want to investigate whether this really is a bug first, and at least be able to tell you exactly why Ncat acts this way.

@dmiller-nmap dmiller-nmap added the Ncat label Dec 17, 2018

@anotherlink

This comment has been minimized.

Copy link

anotherlink commented Dec 18, 2018

I understand.. yet the current behavior is that it will exit with 'broken pipe' if you try to send further bytes on such a closed connection, but only then.
personally i would have to stop using it and switch to the old one or socat because for development i really need to see timeouts and stuff like that immediately, which i'd find sad because i really love ncat! ( cats in general >; ] )

greetings,
photon

@anotherlink

This comment has been minimized.

Copy link

anotherlink commented Dec 18, 2018

btw, just to be clear on this: this is no half-open connection, i had changed my code to call shutdown(2) before the close, so that it is explicit.. in such a case writing to that remote would have been impossible, (beyond the IP stack discarding it after close()) ... so i think it really is an actual bug, even with the desire of half closed connections in mind, since there is nothing the cat could ever do from this point on than to exit..

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment