APLawrence.com -  Resources for Unix and Linux Systems, Bloggers and the self-employed

netcat timeout

© December 2004 (various authors)

What is this stuff?

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. 

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);
        if(debugl) fprintf(stderr,"write()=%d\n",bufw);
        if(bufr != bufw) {
            if(debugl) fprintf(stderr,"short write!\n");

And change 'em as follows :

while((bufr=read(0,buf,sizeof(buf)))>0) {
        if(debugl) fprintf(stderr,"read()=%d\n",bufr);
        if(debugl) fprintf(stderr,"write()=%d\n",bufw);
        if(bufr != bufw) {
            if(debugl) fprintf(stderr,"short write!\n");
        (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)

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

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 !


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)

Got something to add? Send me email.

(OLDER)    <- More Stuff -> (NEWER)    (NEWEST)   

Printer Friendly Version

-> netcat timeout ––>Re: Netcat doesn't work on WAN

Inexpensive and informative Apple related e-books:

Take Control of Preview

Photos for Mac: A Take Control Crash Course

iOS 10: A Take Control Crash Course

Take control of Apple TV, Second Edition

Take Control of Apple Mail, Third Edition

Printer Friendly Version

Have you tried Searching this site?

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.

Contact us

Printer Friendly Version

Perl is designed to give you several ways to do anything, so consider picking the most readable one. (Larry Wall)

Linux posts

Troubleshooting posts

This post tagged:


Unix/Linux Consultants

Skills Tests

Unix/Linux Book Reviews

My Unix/Linux Troubleshooting Book

This site runs on Linode

SCO Unix Sales, Support, & Service

Phone:  707-SCO-UNIX (707-726-8649Toll Free: 833-SCO-UNIX (833-726-8649)