A.P. Lawrence

netcat timeout

If this isn't exactly what you wanted, please try our Search (there's a LOT of techy and non-techy stuff here about Linux, Unix, Mac OS X and just computers in general!):

From: Roberto Zini <fred@strhold.it>
Subject: Re: Netcat doesn't work on WAN
Date: Thu, 25 Jan 2001 09:52:59 +0100 References: <3A6FAC83.31585C35@bigfoot.com>

Chen Coulter wrote:
> 
> Hi all!
> 
> I've been a fan of this newsgroup for some time and have been
> very grateful to Jeff for his posting(s) about netcat and how
> to interface it to various print servers.  I have used the
> SCO binary version successfully for quite some time on printers
> that are on the local network (192.168.4.x).
> 
> However, recently I ran into a problem when I tried to convert
> a client's printers that I had running (successfully) as remote
> printers to netcat printers so that I would see them as local
> devices and would have options to install print servers that
> could use more than one parallel port.
> 
> When I configured the printers as netcat devices, I would get
> errors on the printers that seemed to indicate a buffer overrun.
> The printers were configured identically in Printer Manager to
> other netcat printers on the local network that work fine.  We
> continued to get errors on the printers until I switched them
> back to remore printers at which time the printers started working
> correctly.
> 
> We are running OpenServer 5.0.5 with rs505a and OSS497c.  The
> local system is connected to a remote site via a Cisco router
> talking to a frame relay line.  The printer at the remote site
> was a Lexmark Optra R+ that I configured to print via port 9100
> using netcat.  The local system was configured as 192.168.4.x
> while the remote site was configured as 192.168.1.x.  All
> devices could be pinged via IP and by name and the printers
> actually printed 5 or 6 pages before erroring.
> 
> Does anyone know why netcat would have this problem?  Do I
> need to change something and recompile it (and not use the
> precompiled binary)?
> 
> Please respond with suggestions.
> 
> Thanks for your valuable time,
> 
> Chen Coulter
> software_sourcery@bigfoot.com

Hi !

Far from me from being an expert network programmer but
the "netcat" should work quite well even on your 
network; in fact, by taking a quick look at the file
I can see that the O_SYNC flag is set just before
starting to write to the remote printer. This should
mean that the write(S) system call (the one that
actually takes care of writing your data to the
remote device) __should__ not return until the
outgoing data have actually been written. 

So, even if the underlying network is slow, netcat 
_should_ not force a remote printer overrun condition; 
also, a check is performed just after the "write" syscall
to actually check if the amount of data written is
the expected one (this in order to avoid "short writes").

However, I must tell that all the references I've been
able to read concerning the O_SYNC flag only refere
to disk files so I'm not sure about its behaviour
on sockets. 

My Unix and Linux Troubleshooting E-Book will show you how to
solve tough system problems!

A couple of suggestions :

a) try by reducing the size of the I/O buffer; locate the
following line which should be at the top of netcat.c :

char        buf[1024];

Once you've got it, change it as follows :

char        buf[512];

Next, recompile the source and give it another try; if
the above trick does not work, try by adding a short
pause just after the write syscall. I'm unable to
check it now (I'm presently operating under UnixWare 7)
but I do think that the OpenServer 5 DevKit comes with
the nap(S) syscall which allows you to suspend a 
program execution for a given amount of milliseconds;
this period should allow the remote device to recover
from a potential overrun condition, thus avoiding
the problems you're facing.

Locate the following chunk of lines :

while((bufr=read(0,buf,sizeof(buf)))>0) {
        if(debugl) fprintf(stderr,"read()=%d\n",bufr);
        bufw=write(s,buf,bufr);
        if(debugl) fprintf(stderr,"write()=%d\n",bufw);
        if(bufr != bufw) {
            if(debugl) fprintf(stderr,"short write!\n");
            eret=2;
            break;
        }
    }

And change 'em as follows :

while((bufr=read(0,buf,sizeof(buf)))>0) {
        if(debugl) fprintf(stderr,"read()=%d\n",bufr);
        bufw=write(s,buf,bufr);
        if(debugl) fprintf(stderr,"write()=%d\n",bufw);
        if(bufr != bufw) {
            if(debugl) fprintf(stderr,"short write!\n");
            eret=2;
            break;
        }
        (void) nap(number);
    }

I think you'll have to perform some tests in order
to find the correct value for number; start by using
100 (0.1 sec) and raise it until problems (hopefully)
disappear. 

Of course you'll have to recompile netcat for the above to work
(and remember to compile it every time you change the "number"
value).

Perhaps the author (or you) could change the source to allow
the user to specify an amount of time to wait between each
write operation by adding a specific command line flag ...

Hope this helps !

Best,
Roberto

-- 
---------------------------------------------------------------------
Roberto Zini                                  email : fred@strhold.it
Technical Support Manager -- Strhold Sistemi EDP Reggio Emilia(ITALY)
---------------------------------------------------------------------
"Has anybody around here seen an aircraft carrier?"                
        (Pete "Maverick" Mitchell - Top Gun)

Enter your email address for automatic notification of new posts here
(be sure to whitelist 'feedburner.com' if you use spam filtering)

My Working for yourself E-Book will show you how to break free
from the 9 to 5 grind.

/Bofcusm/975.html copyright 1997-2004 (various authors) All Rights Reserved

Have you tried Searching this site?

Unix/Linux/Mac OS X support by phone, email or on-site: Support Rates

This is a Unix/Linux resource website. It contains technical articles about Unix, Linux and general computing related subjects, opinion, news, help files, how-to's, tutorials and more. We appreciate comments and article submissions.

Publishing your articles here