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. 

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)

Jump to Comments

Many of the products and books I review are things I purchased for my own use. Some were given to me specifically for the purpose of reviewing them. I resell or can earn commissions from the sale of some of these items. Links within these pages may be affiliate links that pay me for referring you to them. That's mostly insignificant amounts of money; whenever it is not I have made my relationship plain. I also may own stock in companies mentioned here. If you have any question, please do feel free to contact me.

Specific links that take you to pages that allow you to purchase the item I reviewed are very likely to pay me a commission. Many of the books I review were given to me by the publishers specifically for the purpose of writing a review. These gifts and referral fees do not affect my opinions; I often give bad reviews anyway.

We use Google third-party advertising companies to serve ads when you visit our website. These companies may use information (not including your name, address, email address, or telephone number) about your visits to this and other websites in order to provide advertisements about goods and services of interest to you. If you would like more information about this practice and to know your choices about not having this information used by these companies, click here.