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

[Jacek Wielemborek <wielemborekj1 () gmail com>]

2013/8/15 David Fifield <david () bamsoftware com>:
> On Thu, Aug 15, 2013 at 12:46:49AM +0200, Jacek Wielemborek wrote:
> > 2013/8/15 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)
> > >         }
> > > }
> >
> > ...and replace ncat_recv calls with something that understands it?
>
> Yes. Feel free to introduce new abstractions.
>
> David Fifield

Right now it doesn't feel like adding abstractions, but replacing
interfaces - an alternative to ncat_recv that takes int *size, returns
a buffer which is allowed to be NULL to signal "not error, just an
empty string, come back to select()". It will affect a lot of code
too.
_______________________________________________
Sent through the dev mailing list
http://nmap.org/mailman/listinfo/dev
Archived at http://seclists.org/nmap-dev/