[comp.unix.sysv386] UUCP TIMEOUTS

stlouis@unixg.ubc.ca (Phill St. Louis) (02/23/91)

We are using Hayes V-series Smartmodems 9600.

We have five Interactive Unix 2.2 386 machines that are to send data to a
Sun Sparcstation (SunOs 4.1.1).  Using uucico -r1 -x9 -shostname,
and communicating in both directions with the 3 machines that are more
than 2,000 miles away, I am getting the message:

expect: (CONNECT)
^JATDTphone-number-here^Mtimed out

The following line in the Dialers file gets me very close to a connection,
but does not quite do it.

hayes9600  =,-, "" \dAT\r\c OK\r \EATS37=9DT\T\r\c CONNECT-\c-CONNECT

How do I adjust the Dialers file on these machines to allow more time for
the modem handshaking to take place on these long distance phone calls?

Alternatively, how can the timeout period be adjusted on the Sun
and on Interactive Unix?

Thank you!

vhs@britesun.radig.de (Volker Herminghaus-Shirai) (02/25/91)

stlouis@unixg.ubc.ca (Phill St. Louis) writes:

>We are using Hayes V-series Smartmodems 9600.

>We have five Interactive Unix 2.2 386 machines that are to send data to a
>Sun Sparcstation (SunOs 4.1.1).  Using uucico -r1 -x9 -shostname,
>and communicating in both directions with the 3 machines that are more
>than 2,000 miles away, I am getting the message:

>expect: (CONNECT)
>^JATDTphone-number-here^Mtimed out

>The following line in the Dialers file gets me very close to a connection,
>but does not quite do it.

>hayes9600  =,-, "" \dAT\r\c OK\r \EATS37=9DT\T\r\c CONNECT-\c-CONNECT

>How do I adjust the Dialers file on these machines to allow more time for
>the modem handshaking to take place on these long distance phone calls?

>Alternatively, how can the timeout period be adjusted on the Sun
>and on Interactive Unix?

I had the very same problem with the uucico on my SparcStation 1. In fact
I actually patched the uucico-binary to get a timeout of 64 seconds instead
of the hard-coded(!) 45 seconds. Here is the program I used:
#include <stdio.h>

long offset = 14128l;

/* This is only for SunOS 4.1.1 Sparc */
int value[100];
main()
{
int buff[100];
int i;
FILE *fpin;

	fpin=fopen("uucico.patch","r+");
	fseek(fpin,offset,0);
	fread(buff,25,1,fpin);
	for(i=0;i<25;i++)
		printf("%04x ",buff[i]);
	fseek(fpin,offset,0);
	getchar();
	buff[5]=(unsigned int)0x90102040;
	for(i=0;i<25;i++)
		printf("%04x ",buff[i]);
	getchar();
	fseek(fpin,offset,0);
	fwrite(buff,25,1,fpin);
	getchar();
	fseek(fpin,offset,0);
	fread(buff,25,1,fpin);
	for(i=0;i<25;i++)
		printf("%04x ",buff[i]);
	}
}

It was pretty hard to find the right place in the binary to patch.
Also, if someone knows a good program that does binary patching
on arbitrary files using command line arguments I would be glad
to have it since I don't want to write a C program every time
I patch something :-)

>Thank you!
 Hope I could help.

 Volker

-- 
Volker Herminghaus-Shirai (vhs@britesun.radig.de)
panic: 80x86! Trying to vomit...

igb@fulcrum.bt.co.uk (Ian G Batten) (02/25/91)

In article <1991Feb24.175541.540@britesun.radig.de> vhs@britesun.radig.de (Volker Herminghaus-Shirai) writes:
> I had the very same problem with the uucico on my SparcStation 1. In fact
> I actually patched the uucico-binary to get a timeout of 64 seconds instead
> of the hard-coded(!) 45 seconds. Here is the program I used:

If this is a joke, it's a very subtle one.  You've not had to do this to
get extra timeouts for long call set ups with UKUUCP, V7 UUCP, SVR2
UUCP, SVR[34] UUCP (ie Honeydanber), SunOS {3.5,4.0} (ie BSD) or SunOS
4.1 (ie HDB + hacks).  They all provide some moral equivalent of
changing CONNECT-\n-CONNECT to CONNECT-\c-CONNECT-\c-CONNECT and so on.
There may be some elderly cases where each sub-timeout generates a
superfluous carriage return, but unless you have some brain-dead modem
that stops handshaking on any character from the DTE (I've seen 'em)
this will have little effect.

> /* This is only for SunOS 4.1.1 Sparc */

Right.  For ANY CASE of waiting for xxx, you can double the wait period
by writing xxx-\c-xxx, triple it with xxx-\c-xxx-\c-xxx and so on.
Anyone who makes binary patches to binary the source to which they do
not have needs a better reason than this, I'd say.

rodney@tyrell.gtc.de (Rodney Volz) (02/26/91)

In article <1991Feb22.203123.10333@unixg.ubc.ca> stlouis@unixg.ubc.ca (Phill St. Louis) writes:
>
>hayes9600  =,-, "" \dAT\r\c OK\r \EATS37=9DT\T\r\c CONNECT-\c-CONNECT
>
>How do I adjust the Dialers file on these machines to allow more time for
>the modem handshaking to take place on these long distance phone calls?

First possibility: Recompile the source. Complicated.
Second possibility: Add some '\d' to the end of your dial-string.
The dial part in your example should read "\eats37=9DT\T\T\r\c\d\d\d"
then. System-independent, simple, fast. -

How about stopping uucico from trying every system-line twice,
when it failed? I had to recompile the stuff... Any other suggestions?

-Rodney
-- 
                     Rodney Volz - 7000 Stuttgart 1 - FRG
 ============> ...uunet!mcsun!unido!gtc!aragon!tyrell!rodney <=============
  rodney@tyrell.gtc.de * rodney@delos.stgt.sub.org * rodney@mcshh.hanse.de 
  \_____________ May your children and mine live in peace. ______________/

brian@motcsd.csd.mot.com (Brian Smithson) (02/26/91)

igb@fulcrum.bt.co.uk (Ian G Batten) writes:

>In article <1991Feb24.175541.540@britesun.radig.de> vhs@britesun.radig.de (Volker Herminghaus-Shirai) writes:
>> I had the very same problem with the uucico on my SparcStation 1. In fact
>> I actually patched the uucico-binary to get a timeout of 64 seconds instead
>> of the hard-coded(!) 45 seconds. Here is the program I used:

>For ANY CASE of waiting for xxx, you can double the wait period
>by writing xxx-\c-xxx, triple it with xxx-\c-xxx-\c-xxx and so on.

Alternatively, you can insert delays before you starting the "expect".
For example (in HDB),

  ... "" \d\d\d\d\d\c CONNECT ...

will expect nothing, delay about 10 seconds, and then expect CONNECT.

-- 
-Brian Smithson
 Motorola Inc., Computer Group, Commercial Systems Division
 10700 N. De Anza Boulevard, Cupertino, CA 95014 USA, (408)366-4104
 brian@csd.mot.com, {apple | pyramid}!motcsd!brian