Re: Piping files to ncat under MacOS/BSD

[David Fifield <david () bamsoftware com>]

On Thu, Nov 08, 2012 at 11:03:37AM +0100, Henri Doreau wrote:
> 2012/11/8 David Fifield <david () bamsoftware com>:
> > Is this something that should be handled in Nsock (when at EOF, make the
> > iod readable, so that the reading callback can notice the EOF), or in
> > some code that is specific to Ncat and kqueue?
>
> I'm not sure how to do this best. I'd like nsock to handle it, so that
> the exposed API is totally engine-agnostic. OTOH I don't want to have
> something too intrusive as this is related to a very specific use of
> nsock...
>
>
> Here's what happens:
>
> 1) kevent() detects the read condition on stdin and triggers the event.
>    Bytes left before EOF are given by kevent().
>
> 2) ncat reads data (let's say the entire file) and schedule a new read.
>
> 3) kevent() then won't mark the event as ready anymore (neither
>    readable nor EOF).
>
> It's up to the caller to see that he's dealing with a regular file, then
> compare how much is still to be read (this is given by the first call to
> kevent()).
>
> nsock could flag its IODs according to their kind (would be useful to
> know whether to call recvfrom() or read() for instance). I'm not sure
> how to proceed once we have it (I lacked time to seriously work on it).
>
> I was also thinking of always using the fallback engine for ncat, and
> focus on handling sockets in nsock (which might sound reasonable). But
> I'd prefer to avoid this if possible.

Let's do this: Add a test for this behavior of reading from files, with
a comment pointing to this thread saying that it doesn't work for
kqueue. Then force a fallback engine for Ncat.

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