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

[Patrick Donnelly <batrick () batbytes com>]

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. 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).

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