Problem with uucico

Kevin Pickard kevin at perle.UUCP
Sat Mar 16 07:43:53 AEST 1991


Pyramid 98XE (DualPort OSx 4.4)

     We have been having some problems with  uucico  on  our
system for almost a year and a half now.  Pyramid has failed
to find any solution to the problem and refuses to  look  at
it any further.

     Over this time they have passed us from  one  technical
support  person  to another--each time with the same result.
We have upgraded our OS, put in debug versions of  the  code
and  provided  reams  of  line traces and debug output.  The
problem persists.

     Unfortunately our support with Pyramid  was  through  a
third-party  vendor  and  they no longer exist.  Pyramid now
feels they no longer need to  provide  a  solution  for  the
problem.  Hence we are appealing to the collective knowledge
of the net for some help.

     What happens is that during a UUCP session with another
host  uucico gets confused and does not respond to a message
during a file transfer.  It goes into a  recovery  mode  and
gets really messed up and eventually the other host gives up
on us and drops the line.  When the connection is later  re-
established  things  continue  normally with the failed file
for a while only to eventually fail again (sometimes on  the
same file, sometimes on a following one).  This repeats over
and over again.  All data is eventually transferred  but  it
takes  many  connections, a lot of errors and a lot of time.
This obviously lowers the throughput.

     The problem occurs regardless of the type of other host
(NCR,  Bell,  PC  and  recently  AT&T).   The problem occurs
regardless of the modem type (Hayes, Telebit and  US  Robot-
ics)  although  it  is  more  pronounced  with  higher speed
modems.  The  problem  is  also  more  pronounced  when  the
Pyramid system is under load.

     Through the addition of debug statements in the  kernel
and uucico it has been shown that when the connection fails,
the message that was not replied to by uucico  was  received
by  uucico  fully intact.  The message was traced coming out
of the modem by using a Data Line  Monitor  and  uucico  was
modified  to  print  out all received messages.  The message
output matched and the message content itself was  confirmed
to be correct.

     The  failure  usually  starts  with  uucico  indicating
'pkcget: alarm 4001' just after it gets the last byte of the
message.  It does not recover from this and continues to get
further  such  alarms  (ie.  'pkcget:  alarm 7002', 'pkcget:
alarm 10003', etc.) Pyramid has indicated that this is  some
kind of timeout condition.  But the message has been read in
completely when this occurs and there is no idle time on the
line.   And  uucico  on the Pyramid does not see the message
when it is then resent a number of times.

     I recently described this problem to someone I know  at
a  neighbouring  site  (hi  Ron!).  He said that this looked
just like a problem he saw on his  Pyramid  system  back  in
1986.  Fortunately he had a source licence for the UUCP code
and he hacked a line out of the code and  the  problem  went
away.   Unfortunately he no longer has the Pyramid so we can
not get a copy of the hacked binary from him.  To add insult
to  injury,  Pyramid  has  also refused to make the one line
change to a version of the code  for  us  (we  do  not  have
source).

     The change itself is  in  the  file  pk0.c  and  simply
involves  the  removal  of  a single line of code.  When Ron
made this change he said he did not understand why it worked
in  his case, only that it did work.  The change was made in
code he had on August 22, 1986 and was around  line  393  in
pk0.c.  The affected code is as follows (the removed line is
marked <==):

        if (pk->p_state&RXMIT)  {
                pk->p_nxtps = next[pk->p_rpr];         <==
        }
        x = pk->p_nxtps;
        bstate = pk->p_os[x];

     This change may or may not work in our case but I  have
no idea.

     If anyone recognizes this problem or has any idea as to
how  we  can fix it we would greatly appreciate hearing from
you.  We are currently at a dead end.

     Thanks.

--
------------------------------ ~~~~~~~ ---------------------------------------
                              | o   o |     Kevin Pickard
                              |   .   |     UUCP: ...!uunet!mnetor!perle!kevin
--------------------------^^^-----------^^^-----------------------------------



More information about the Comp.unix.questions mailing list