mailing list archives
Re: [NSE] socket:receive_buf(...) broken
From: Patrick Donnelly <batrick () batbytes com>
Date: Thu, 16 Sep 2010 02:45:06 -0400
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
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
Archived at http://seclists.org/nmap-dev/