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 listener with UDP doesn't work when data cames from STDIN #1029

Open
wofwofwof opened this Issue Oct 9, 2017 · 2 comments

Comments

Projects
None yet
2 participants
@wofwofwof

wofwofwof commented Oct 9, 2017

Hello,
when using ncat with the following command
echo testdata | ncat -u -l -p 5555

and connect against it with
echo otherdata | ncat -u localhost 5555

I get the answer:
Ncat: Connection refused.

With netcat connecting against the ncat server
nc -u localhost 5555
it works.

If I use netcat as server with
echo testdata | nc -u -l -p 5555
echo otherdata | ncat -u localhost 5555
the ncat client doesn't show anything, on the netcat server, otherdata is visible.

Thanks very much for this great tool.

cheers
wof

@dmiller-nmap

This comment has been minimized.

Show comment
Hide comment
@dmiller-nmap

dmiller-nmap Oct 9, 2017

What version of Ncat are you using? (Run ncat --version)

Ncat in some cases may close upon receiving End Of File (EOF) on STDIN. We have documented most of these on SecWiki.org, but UDP mode works differently. Because UDP doesn't have the concept of a "connection," each end of the pairing (server & client) cannot know if the other end intends to send something more. So the only signal it has to stop and exit is EOF on STDIN.

One other complication is that Ncat uses "connected UDP," which means that once one client has connected, others cannot connect to the same listener. This makes it similar enough to TCP that most of the options "just work," though if you want to accept incoming packets from multiple sources, you should use the -k "keep open" option.

It appears there are a few things we might be able to do to make UDP mode more usable:

  • Do any final socket reads and print to STDOUT before exiting. It looks like Ncat Server receives the UDP datagram from the Client, then tries to write its own data (from STDIN) to the client. The client has already quit, due to its own EOF on STDIN, so the server gets Connection Refused. At this point, the server should have received the client data, but it quits without printing it.
  • Document how the -i, -d, and -w timeout options work with UDP in client and server mode. One of these ought to make sense as a "wait for a reply" option for the client, though it doesn't appear that they currently do so.

dmiller-nmap commented Oct 9, 2017

What version of Ncat are you using? (Run ncat --version)

Ncat in some cases may close upon receiving End Of File (EOF) on STDIN. We have documented most of these on SecWiki.org, but UDP mode works differently. Because UDP doesn't have the concept of a "connection," each end of the pairing (server & client) cannot know if the other end intends to send something more. So the only signal it has to stop and exit is EOF on STDIN.

One other complication is that Ncat uses "connected UDP," which means that once one client has connected, others cannot connect to the same listener. This makes it similar enough to TCP that most of the options "just work," though if you want to accept incoming packets from multiple sources, you should use the -k "keep open" option.

It appears there are a few things we might be able to do to make UDP mode more usable:

  • Do any final socket reads and print to STDOUT before exiting. It looks like Ncat Server receives the UDP datagram from the Client, then tries to write its own data (from STDIN) to the client. The client has already quit, due to its own EOF on STDIN, so the server gets Connection Refused. At this point, the server should have received the client data, but it quits without printing it.
  • Document how the -i, -d, and -w timeout options work with UDP in client and server mode. One of these ought to make sense as a "wait for a reply" option for the client, though it doesn't appear that they currently do so.
@wofwofwof

This comment has been minimized.

Show comment
Hide comment
@wofwofwof

wofwofwof Oct 10, 2017

wofwofwof commented Oct 10, 2017

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