PATCH: nsock_core.c / do_actual_read() / recv vs. read

[" mixter () gmail com" <mixter () gmail com>]

Please find a proposed patch below, which will enable nsock to handle
non-network socket data. I've tested extensively with ncat, nmap and
the now-working nsock_telnet.c tool, everything seems to be working,
and (most importantly) nmap scan results are the same.

I would like to incorporate it soon. I've kept it minimal, and I also had to
watch out to keep the errno as it is in the loop (otherwise it seems,
state information from previous read()s may be destroyed, leading
to a block in select()). So this is the safe variant. Please give me a go,
or better, scream within the next 2-3 days, otherwise I'll commit it. ;)

Mixter

Index: nsock_core.c
===================================================================
--- nsock_core.c        (Revision 7540)
+++ nsock_core.c        (Arbeitskopie)
@@ -475,6 +475,8 @@
     /* Traditional read() - no SSL - using recv() because that works
better on Windows */
     do {
       buflen = recv(iod->sd, buf, sizeof(buf), 0);
+      /* In case, retry this with a read() - since we may have a
non-network socket here! */
+      if (buflen == -1 && socket_errno() == ENOTSOCK) buflen =
read(iod->sd, buf, sizeof(buf));
       if (buflen == -1) err = socket_errno();
       if (buflen > 0) {
        if (fscat(&nse->iobuf, buf, buflen) == -1) {


Fyodor wrote:
<<
Good find.  If nsock is not currently able to handle these different
types of descriptors transparently, I think it should be improved to
do so.  The application calling Nsock shouldn't have to set a special
flag.  I'm not sure of the best way to do this though.  One option
would be that if recv() gives an ENOTSOCK error on a particular
socket, try again with read() and set a flag to do read in the future.
> >

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