Re: ncat behavior

[Daniel Miller <bonsaiviking () gmail com>]

Michal,

Is this the same as the issue described in #142, which may have a
workaround in #151?

I thought we had handled all these issues once before, but did we not? Some
references:

* Enumeration of all interactions of -l, --send-only, and --recv-only, with
links to previous discussions: http://seclists.org/nmap-dev/2013/q1/200
* Long discussion on the topic of EOF handling:
http://seclists.org/nmap-dev/2009/q2/151

Dan

#142: http://issues.nmap.org/142
#151: http://issues.nmap.org/151

On Thu, Jun 25, 2015 at 9:06 AM, Michal Hlavinka <mhlavink () redhat com>
wrote:

> Hi,
> I'm thinking if ncat's client behavior, when it closes stdout, instead of
> terminating, when server closed the socket, is the best option. In theory
> it looks good, to be still able to send data (half-closed socket), but the
> problem is that ncat is not getting all information about socket in that
> case. When server half-closes the socket and then exits, the client is not
> notified until it sends data twice(it takes two socket writes for the
> information to be propagated from kernel to client). This leads to client
> hang.
>
> The same thing (client hangs) happens if server terminates, because it
> can't distinguish what exactly happened on the other side. As the need for
> this (send data after server half-closed socket) is quite rare use case,
> but terminating server is more usual, I think it's not worth it the ill
> side effects and should be probably changed to client termination when it
> reads eof. What is your opinion on this?
>
> Regards,
> Michal Hlavinka
> _______________________________________________
> Sent through the dev mailing list
> https://nmap.org/mailman/listinfo/dev
> Archived at http://seclists.org/nmap-dev/
_______________________________________________
Sent through the dev mailing list
https://nmap.org/mailman/listinfo/dev
Archived at http://seclists.org/nmap-dev/