Re: Ncat bug report

[David Fifield <david () bamsoftware com>]

On Sun, Nov 15, 2009 at 03:03:10PM +0000, Hamish Milne wrote:
> I am using Ncat that comes with Nmap v5.00 on Windows XP SP2, but am
> having some problems with inputs.
>
> Basically, I use the command 'ncat -Clkt -e %cd%\loop.bat %ip% %port%'
> to listen for a connection then call the batch file. Included in that
> file is the command 'set /p input='. The user input is recorded then
> passed to a PHP file, which echoes an output. With Netcat I needed to
> do two of these, since for some reason just one wouldn't record the
> input. It worked, but then I realised that Netcat doesn't accept
> multiple connections, so I switched to Ncat.
>
> Now the problem is that the 'set /p input=' command only works for one
> character, as for some reason a new line is sent after each character
> when I telnet into it. I used exactly the same batch file with Netcat
> and had no problems.
>
> Is this a bug? If so, I would really appreciate it to be fixed in the
> next release. If not, what am I doing wrong?

I don't think this is a bug, but rather a strange interaction between
the Windows shell and Windows telnet. I can reproduce it, but only when
I connect using Windows telnet, not with Linux telnet or with Ncat.

The issue is that Windows telnet immediately sends each character you
type, and doesn't buffer a line on the client. It is not sending a
newline character after the first byte, it is sending a packet with a
payload of one byte. Ncat sends that one byte to the subcommand as soon
as it is received. For some reason, the set command quits after it has
read one byte, not even waiting to read a newline. It probably does a
read system call and returns as soon as it has anything.

I can't tell you why your version of Netcat doesn't work this way. (Do
you have a link to the source code?) It must be buffering a line before
sending it to the subprocess. Ncat doesn't do that; it tries to relay
data as soon as it's available.

David Fifield
_______________________________________________
Sent through the nmap-dev mailing list
http://cgi.insecure.org/mailman/listinfo/nmap-dev
Archived at http://seclists.org/nmap-dev/