Re: [NSE] socket:receive_buf(...) broken

[Patrik Karlsson <patrik () cqure net>]

On 16 sep 2010, at 08.45, Patrick Donnelly wrote:

> On Wed, Sep 15, 2010 at 11:00 PM, David Fifield <david () bamsoftware com> wrote:
> > I would like to eventually remove receive_buf completely. I believe that
> > such a function should be built into Nsock itself. There should be a
> > buffer associated with each iod so that you can ask for a certain number
> > of bytes (or lines, etc.) and get exactly that many, no more, with those
> > left over remaining in the buffer. The ssh pattern would be
> >
> > packet_size = socket:receive_exactly(4)
> > -- Unpack size.
> > packet = socket:receive_exactly(packet_size)
> >
> > It would be an error if either call failed; they would return an error
> > if they can't supply enough bytes. There would also be a call to return
> > everything available on the socket, clearing the buffer. There is such a
> > socket buffer (not using Nsock) in ncat/http.c.
>
> I agree with you. The current design of getting more bytes/data then
> you asked for is puzzling when Lua could properly handle this.

I agree that the current design is puzzling and in most cases neither what you expect or want.
I've included/duplicated a small socket class into most of my latest libraries in order to be able to read the exact 
amount of bytes I specify.
This class currently reduces complexity and the need to buffer data in several different places in the same way as it 
would if receive_bytes returned the exact amount of bytes specified.
It would obviously be better if this functionality was provided by the API instead of my wrapper class.

> Still,
> it was too big an undertaking along with my original goals for this
> branch to consider changing the API in such a fundamental way. Fixing
> all the scripts alone would be a huge headache.
>
> I would also like to see real errors added to the socket functions as
> well. In Lua 5.2, it will be possible to yield across C functions
> (pcall) so scripts can properly catch them.
>
> > The main implementation difficulty that I have considered is that you
> > can't just use the select function to detect when an iod has input
> > pending, you also have to check if there is anything in the buffer. We
> > would also need new name for the new "exact" functions. There are a lot
> > of script that use receive_bytes(1) that expect to get as many bytes as
> > are available.
>
> I think just changing the current functionality would be the way to go
> and fixing scripts that are using the API improperly (e.g. calling
> receive_bytes(1) and expecting Nmap to return more than one byte).

I agree!

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


//Patrik
--
Patrik Karlsson
http://www.cqure.net
http://www.twitter.com/nevdull77





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