chris@bullwinkle.UUCP (Chris Andersen (The Dangerous Guy)) (04/09/90)
I'm working on a system of a friend of mine who has been having problems
with his UUCP connection. He can get mail and news articles out to his
feed, but the minute uucico turns around and tries reading stuff back
from it, it fails. We've tried switching modems, clearing the batch on the
feed site, different cables, most everything, and we still can't figure out
what is going on (mostly because of the obscure error messages uucico
displays).
As near as I can tell (and I'm not a UUCP guru), we are sending a 'H' (hangup)
command to the remote system, they are responding with an 'HN' (don't hangup
because we've got something for you), we then switch into slave mode, and
then weird things start happening.
Any help in solving this would be appreciated.
Here's the relavent output from a 'uucico -r1 -s<site> -x7' command:
finds called
getto called
call: no. XXXXXXX for sys XXXXXXX Dial XXXXXXX
Using dialer type ACUHAYES
dialing Hayes
0\015ACU write ok
10\015dcr returned as 5
login called
wanted \015got that
send \b\d
BREAK (3 nulls)
ioctl 1 second break
DELAY
wanted in: \012\015\012DYNIX(R) V3.0.17.9 (XXXXXXX)\015\012\015\015\012\015login:got that
send XXXXXX
wanted ssword: \015\012\015\012DYNIX(R) V3.0.17.9 (XXXXXXX)\015\012\015\015\012\015login: \015\012\015\012DYNIX(R) V3.0.17.9 (XXXXXXX)\015\012\015\015\012\015login: Ujli\015\012Password:got that
send XXXXXXX
imsg >\ 15\ 12\ 20<
Shere=XXXXXXX\ 0imsg >\ 12\ 20<
ROK\ 0msg-ROK
Rmtname XXXXXXX, Role MASTER, Ifn - 5, Loginuser - root
rmesg - 'P' imsg >\ 20<
Ptfg\ 0got Ptfg
wmesg 'U'g
send 73
rec h->cntl 77
send 61
state - 1
rec h->cntl 61
send 53
state - 3
rec h->cntl 57
state - 10
Proto started g
protocol g
*** TOP *** - role=1, wmesg 'H'
send 210
rmesg - 'H' rec h->cntl 41
state - 10
rec h->cntl 37777777611
send 41
got HN
PROCESS: msg - HN
HUP:
*** TOP *** - role=0, rmesg - ' (Weirdness begins)
bad header 37777777621,h->ccntl 123
rec h->cntl 37777777662
bad header 37777777621,h->ccntl 123
rec h->cntl 37777777662
bad header 37777777621,h->ccntl 123
rec h->cntl 37777777662
bad header 37777777621,h->ccntl 123
alarm 1
send 41
rec h->cntl 41
state - 30
alarm 2
send 41
alarm 3
send 41
alarm 4
send 41
alarm 5
send 41
alarm 6
send 41
alarm 7
send 41
alarm 8
send 41
alarm 9
send 41
alarm 10
send 41
alarm 11
send 41
tries = 10
got FAIL
send 10
send 10
cntrl - -1
send OO -1,imsg >\ 20<
\ 11"*\ 10\ 11\ 20\ 11"*\ 10\ 11\ 20OOOOOO\ 0imsg >\ 20<
OOOOOO\ 0exit code 0
--
Chris Andersen (..!uunet!sequent!toontown!chris)
"life is like arriving late for a movie, having to figure out what was going
on without bothering everybody with a lot of questions, and then being
unexpectedly called away before you find out how it ends."ericf@montreux (Eric Feigenson) (04/11/90)
I'm having the same problem connecting to a Sun (OS version 4) from a Sequent
running Dynix. Here is the exerpt from my uucico session. So far, no one
I've talked to has a clue as to what is going on. We connect just fine to
a different host, and everything works great when the Sun calls us:
gus XXXXX (4/3-17:18-10897) DEBUG (Local Enabled)
gus XXXXX (4/3-17:18-10897) NO CALL (RETRY TIME NOT REACHED)
RETRY TIME (1800) NOT REACHED
gus XXXXX (4/3-17:18-10897) continuing anyway (debugging)
finds (XXXXX) called
ifadate returns 177
getto: call no. 2713475 for sys XXXXX
Using ACU to call
Dialing 2713475
Using hayestone
dc - /dev/ttyd6
ATV1E0H
OK
OK
GOT: CONNECT 2400hayes ok
login called
wanted """"
got: that
send "\d"
DELAY
wanted "gin:"
XXXXX l
XXXXX login:got: that
send "xxxxx"
wanted "sword:"
xxxxx
Password:got: that
send "xxxxxxx"
gus XXXXX (4/3-17:18-10897) SUCCEEDED (call to XXXXX )
imsg looking for SYNC<
Last login: Tue Apr 3 17:16:21 on tty10
\20>
imsg input<Shere\0
Using \0 as End of message char
>got 5 characters
omsg <Spsc -Q0 -x99>
imsg looking for SYNC<\20>
imsg input<ROK\0>got 3 characters
msg-ROK
Rmtname XXXXX, Role MASTER, Ifn - 6, Loginuser - gus
rmesg - 'P' imsg looking for SYNC<\20>
imsg input<Pg\0>got 2 characters
got Pg
wmesg 'U' g
omsg <Ug>
send 077
rec h->cntl 073
send 061
state - 01
rec h->cntl 061
send 057
state - 03
rec h->cntl 053
state - 010
Proto started g
protocol g
gus XXXXX (4/3-17:18-10897) OK (startup ttyif 2400 baud)
*** TOP *** - role=MASTER
bldflst rejects .
bldflst rejects ..
bldflst rejects C.mit-eddCkdh4
bldflst returns 1
bldflst rejects .
bldflst rejects ..
bldflst rejects C.mit-eddCkdh4
bldflst returns 0
wmesg 'H'
send 0210
rmesg - 'H' rec h->cntl 041
state - 010
rec h->cntl 0211
end pksack 01
PKCGET stall for 0.166600 sec
PKCGET stall for 0.175000 sec
send 041
got HN
PROCESS: msg - HN
HUP:
*** TOP *** - role=SLAVE
rmesg - '
bad header 0221,h->ccntl 0123 <=== Here's where things start failing
pkcget: alarm 4001
send 041
pkcget: alarm 7002
send 041
pkcget: alarm 10003
send 041
rec h->cntl 066
bad header 0221,h->ccntl 0123
rec h->cntl 066
bad header 0221,h->ccntl 0123
rec h->cntl 066
bad header 0221,h->ccntl 0123
rec h->cntl 066
bad header 0221,h->ccntl 0123
rec h->cntl 066
bad header 0221,h->ccntl 0123
rec h->cntl 066
bad header 0221,h->ccntl 0123
rec h->cntl 066
bad header 0221,h->ccntl 0123
rec h->cntl 066
bad header 0221,h->ccntl 0123
rec h->cntl 066
bad header 0221,h->ccntl 0123
rec h->cntl 066
bad header 0221,h->ccntl 0123
got FAIL
gus XXXXX (4/3-17:20-10897) BAD READ (expected ANY got FAIL (25))
send 010
send 010
cntrl - -1
gus XXXXX (4/3-17:20-10897) FAILED (conversation complete)
omsg <OOOOOO>
send OO -1,omsg <OOOOOO>
imsg looking for SYNC< D.pscB023f D.pscB023f root - D.pscB023f 0666\0X\0\2 \4\16R\0\\0\25$\0\2\25\0\20>
imsg input< *! \20>
imsg input< "*\10 \20>
imsg input< "*\10 \20>
imsg input<OOOOOO\0>got 6 characters
Hanging up fd = 6
OK
Any help at all would be greatily appreciated!
Thanks.
Eric R. Feigenson
ericf@zurich.ai.mit.edukevin@perle.UUCP (Kevin Pickard) (03/16/91)
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
--------------------------^^^-----------^^^-----------------------------------