Re: [nmap-svn] r31823 - nmap-exp/d33tah/ncat-lua-callbacks/ncat

[David Fifield <david () bamsoftware com>]

On Thu, Aug 15, 2013 at 12:36:27AM +0200, Jacek Wielemborek wrote:
> 2013/8/15 David Fifield <david () bamsoftware com>:
> > You should try inverting your abstractions. If ncat_recv returns the
> > string result of possibly many layers of Lua filters, that indeed makes
> > it hard to test whether the socket is closed. So don't do that. When you
> > find that a socket is closed (through a zero-byte read), all you need to
> > do is report it to the next layer up, and only in that one place. The
> > Lua code in the next layer is now responsible for doing something
> > intelligent with the error. You should read about how sockets work in
> > NSE:
> >         http://nmap.org/book/nse-api.html#nse-api-networkio-connect
> >         http://nmap.org/nsedoc/lib/nmap.html#receive_bytes
> > When a socket read fails, you want to return (nil, err) to the caller.
> > You are almost certainly going to have to define a new function at the
> > top level that understands those Lua return values and transforms them
> > into something useful for the C caller. You probably will not be able to
> > use a zero-byte string as a close signal at this level.
> >
> > In other words, you might want to have ncat_recv at the bottom of your
> > abstraction layers, not at the top.
>
> It's actually both at the top and at the bottom. I still have no idea
> how to solve the problem of empty strings - I want to let the bottom
> know: "there's nothing there, but don't quit, don't loop over, just
> fall back to select". Not sure how to handle it yet.

Just something like

char *magic_recv(size_t *len)
{
        data, err = call_lua_filter_recv()
        if (data == nil) {
                return NULL
        } else {
                *len = lua_strlen(data)
                return lua_strdup(data)
        }
}

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