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

[Kris Katterjohn <katterjohn () gmail com>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 09/15/2010 10:00 PM, David Fifield 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.
>
> 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.

This involves changing the behavior of existing functions but I think is a
better solution (or at least the beginning of one):

receive(): Give me whatever is available

receive_bytes(n): Give me exactly n bytes or fail somehow (maybe returning an
error but with the available bytes, or whatever is decided)

receive_lines(n): Give me exactly n lines or fail like receive_bytes()

Then change the scripts accordingly.

It seems like with the names of these function, they should have always been
this way.  Specifying a precise amount should give you that and only that, and
asking for possibly more than that should be the special case.

Adding new functions (or optional arguments or whatever) for the behavior of
these current ones seems more appropriate to me, especially for the long run.

Or really, how would the current receive_bytes() even differ from the
receive() other than specifying a minimum?  Since specifying "at least this
much" is a special case vs just getting everything (like the receive_bytes(1)
does now), new functions may be overkill when checking the return length of
receive() may accomplish this.  I haven't thought about this aspect in much
detail yet, so I may have overlooked something here so far.  It'd be cool though.

Then again, this does mean changing existing functions/scripts so that could
kill this right now.

> David Fifield

Cheers,
Kris Katterjohn

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQIcBAEBAgAGBQJMkY7tAAoJEEQxgFs5kUfuyxAP/3Zp4mHWTf4kP1zgWsGG5MBb
rj8cZfQwL60JK8ADzS713VJ/bq1kQvWXk9LBsrXYoBay6ms5PxrvvgAiqSNkPOzR
SbdSHFlK9D2r/UkVTElyNHaLzC8MbdejpZXs5MM8DHZbRWV9DZOLgIygln/szw3W
S426pVhhNjbW13GSmzPjOGbiAT2yCRNtBtyNmoyIQp0ZiHdo75a/YN9JwsB+wSuX
5fj+V5uXUPvlgcuJ9P4qy2U2drY95P8Hr81KCJ2ukrGXBbuRD/kmKb6T/DuV80/W
AlMjiB+bebwyKCK39tZV9WbIZi+tvgwgGHd2mtPr75XP4GV8Veezz5J+ze5LXjhs
mi+mhko5tkINsryWHPpH15aNKpbsW/XiqdUgXGHD2FkTS623aB/GHhbj94hprQO/
I69NmNaZlgvHRAX2A+hxb8yTlcbLBrPa2aKJP1JzuDktx2Q6kBIXg0ov2j2TcOt9
AFuklyKobQPsyn2Dx/8uMA6ahjIzTmXFYiPFISgjDjM4N5zVWqg8GKGc9hymflQq
BxqH34KPgod8ZU+Vb5T9XXByyazzTk9YAXLvFTom7B3yu3rzS9VG4pgNGRWJpTWz
QgXKiQPIgTu/M8Nd/IoDnon3zCFN8R58qCI8XFVGdK91mIhtkbVgTE/ppMo9E/9Y
34HsA+4XeJ+vxa1spPev
=lMyi
-----END PGP SIGNATURE-----
_______________________________________________
Sent through the nmap-dev mailing list
http://cgi.insecure.org/mailman/listinfo/nmap-dev
Archived at http://seclists.org/nmap-dev/