todd@ivucsb.sba.ca.us (Todd Day) (10/14/89)
I am running 3.5, using the old (non-HDB) uucico. If my uucico is
sending out a packet, and the packet fails, it notes the failure
in the LOGFILE, but it ALSO DELETES THE PACKET! Why????
Here's some chunks from a recent session:
anise!todd (10/14-2:29:40) (X,9331,0) XQT QUE'D (rmail apple.com!cpdaux!steve )
>This is the packet that gets eaten later.
anise!uucp (10/14-2:45:43) (C,9339,0) OK (DIAL tty001 Pxxx-xxxx< 33)
anise!uucp (10/14-2:45:49) (C,9339,0) SUCCEEDED (call to anise )
anise!uucp (10/14-2:46:00) (C,9339,0) OK (startup)
anise!todd (10/14-2:46:02) (C,9339,0) REQUEST (S D.aniseBC5662 D.aniseBC5662 todd)
anise!todd (10/14-2:48:25) (C,9339,1) BAD READ (expected 'C' got FAIL)
anise!todd (10/14-2:48:25) (C,9339,1) FAILED (conversation complete)
Here, we get a normal logon, but anise is grinding under a heavy load
(often does that at night), so uucico decides to call it a day after
waiting too long.
anise!uucp (10/14-3:24:30) (C,9271,0) OK (startup)
anise!uucp (10/14-3:24:31) (C,9271,0) REQUESTED (S D.aniseBimh2 D.aniseSimh2 news)
anise!news (10/14-3:28:00) (C,9271,1) COPY (SUCCEEDED)
anise!uucp (10/14-3:28:02) (C,9271,1) REQUESTED (S D.aniseXimh0 X.anisedimh3 news)
anise!news (10/14-3:28:03) (C,9271,2) COPY (SUCCEEDED)
anise!todd (10/14-3:28:05) (C,9271,2) REQUEST (S D.aniseBC5662 D.aniseBC5662 todd)
anise!todd (10/14-3:28:05) (C,9271,2) FAILED (CAN'T READ D.aniseBC5662 2)
Now here, anise is sending me files. They get here okay, but now uucico can't
find the old file that failed above! It has eaten it.
Now, why does the UNIXPC uucico delete files on failure? Is there anything
I can do to prevent this?
--
Todd Day | todd@ivucsb.sba.ca.us | ivucsb!todd@anise.acc.com
Giants or A's in *seven*!pjh@mccc.uucp (Pete Holsberg) (10/17/89)
In article <1989Oct14.105712.9505@ivucsb.sba.ca.us> todd@ivucsb.sba.ca.us (Todd Day) writes:
=I am running 3.5, using the old (non-HDB) uucico. If my uucico is
=sending out a packet, and the packet fails, it notes the failure
=in the LOGFILE, but it ALSO DELETES THE PACKET! Why????
=
=Here's some chunks from a recent session:
=
=
=anise!todd (10/14-2:46:02) (C,9339,0) REQUEST (S D.aniseBC5662 D.aniseBC5662 todd)
=anise!todd (10/14-2:48:25) (C,9339,1) BAD READ (expected 'C' got FAIL)
=anise!todd (10/14-2:48:25) (C,9339,1) FAILED (conversation complete)
What causes the "BAD READ (expected 'C' got FAIL)"??
--
Pete Holsberg UUCP: {...!rutgers!}princeton!mccc!pjh
Mercer College CompuServe: 70240,334
1200 Old Trenton Road GEnie: PJHOLSBERG
Trenton, NJ 08690 Voice: 1-609-586-4800erict@flatline.UUCP (J. Eric Townsend) (10/17/89)
In article <1989Oct16.181609.14182@mccc.uucp> pjh@mccc.UUCP (Pete Holsberg) writes: |In article <1989Oct14.105712.9505@ivucsb.sba.ca.us> todd@ivucsb.sba.ca.us (Todd Day) writes: |=Here's some chunks from a recent session: |=anise!todd (10/14-2:46:02) (C,9339,0) REQUEST (S D.aniseBC5662 D.aniseBC5662 todd) |=anise!todd (10/14-2:48:25) (C,9339,1) BAD READ (expected 'C' got FAIL) |=anise!todd (10/14-2:48:25) (C,9339,1) FAILED (conversation complete) | |What causes the "BAD READ (expected 'C' got FAIL)"?? I get the exact same thing when I talk to *SOME* TB+ modems. It depends on how the TB+ operator has set up their modem... I wish I knew enough about TB+ modems to figure out the problems, but I don't. -- "You have absolutely no idea what you're talking about, do you realise that?" -- Peter Da Silva (sugar!peter) J. Eric Townsend uunet!sugar!flatline!erict com6@uhnix1.uh.edu EastEnders Mailing list: eastender@flatline.UUCP
pjh@mccc.uucp (Pete Holsberg) (10/19/89)
In article <2479@flatline.UUCP> erict@flatline.UUCP (J. Eric Townsend) writes: =In article <1989Oct16.181609.14182@mccc.uucp> pjh@mccc.UUCP (Pete Holsberg) writes: =|In article <1989Oct14.105712.9505@ivucsb.sba.ca.us> todd@ivucsb.sba.ca.us (Todd Day) writes: =|=Here's some chunks from a recent session: =|=anise!todd (10/14-2:46:02) (C,9339,0) REQUEST (S D.aniseBC5662 D.aniseBC5662 todd) =|=anise!todd (10/14-2:48:25) (C,9339,1) BAD READ (expected 'C' got FAIL) =|=anise!todd (10/14-2:48:25) (C,9339,1) FAILED (conversation complete) =| =|What causes the "BAD READ (expected 'C' got FAIL)"?? = =I get the exact same thing when I talk to *SOME* TB+ modems. It depends =on how the TB+ operator has set up their modem... Me, too! =I wish I knew enough about TB+ modems to figure out the problems, but =I don't. Me, too!! :-) -- Pete Holsberg UUCP: {...!rutgers!}princeton!mccc!pjh Mercer College CompuServe: 70240,334 1200 Old Trenton Road GEnie: PJHOLSBERG Trenton, NJ 08690 Voice: 1-609-586-4800
lenny@icus.islp.ny.us (Lenny Tropiano) (10/19/89)
In article <1989Oct16.181609.14182@mccc.uucp> pjh@mccc.UUCP (Pete Holsberg) writes: |>In article <1989Oct14.105712.9505@ivucsb.sba.ca.us> todd@ivucsb.sba.ca.us (Todd Day) writes: ... |>=anise!todd (10/14-2:46:02) (C,9339,0) REQUEST (S D.aniseBC5662 D.aniseBC5662 todd) |>=anise!todd (10/14-2:48:25) (C,9339,1) BAD READ (expected 'C' got FAIL) |>=anise!todd (10/14-2:48:25) (C,9339,1) FAILED (conversation complete) |> |>What causes the "BAD READ (expected 'C' got FAIL)"?? Basically when uucico is going through it's handshaking to coordinate between the different files to send the ("D.*" and "X.*" files), uucico will stop after each file and wait for an <ACK>nowledgement from the other site. *** TOP *** - role=1, setline - X Request: icus!D.icus1eac709 --> att!D.icus1eac709 (lenny) setline - S wrktype - S wmesg 'S' D.icus1eac709 D.icus1eac709 lenny - D.icus1eac709 0666 lenny rmesg - 'S' got SY PROCESS: msg - SY SNDFILE: -> 1683 / 1.416 = 1188.5 rmesg - 'C' got CY PROCESS: msg - CY ... ^^ If for some reason the remote site doesn't send back anything, or gets out of sync, or there is noise on the line... several (10 I think) alarm() calls will happen. and eventually it will timeout with the message. BAD READ (expected 'C' got FAIL) -Lenny -- | Lenny Tropiano ICUS Software Systems [w] +1 (516) 589-7930 | | lenny@icus.islp.ny.us Telex; 154232428 ICUS [h] +1 (516) 968-8576 | | {ames,pacbell,decuac,hombre,sbcs,attctc}!icus!lenny attmail!icus!lenny | +------- ICUS Software Systems -- PO Box 1; Islip Terrace, NY 11752 -------+
todd@ivucsb.sba.ca.us (Todd Day) (10/19/89)
pjh@mccc.uucp (Pete Holsberg) writes: `In article <1989Oct14.105712.9505@ivucsb.sba.ca.us> todd@ivucsb.sba.ca.us (Todd Day) writes: `= `=anise!todd (10/14-2:46:02) (C,9339,0) REQUEST (S D.aniseBC5662 D.aniseBC5662 todd) `=anise!todd (10/14-2:48:25) (C,9339,1) BAD READ (expected 'C' got FAIL) `=anise!todd (10/14-2:48:25) (C,9339,1) FAILED (conversation complete) `What causes the "BAD READ (expected 'C' got FAIL)"?? Usually, what happens is that my machine took a LONG time between packets, and anise got impatient. If anise sends out what I call a BLIP packet (blip, cause it blips the RD light on my modem) (this packet means, "Where the hell are you?", I think), my UNIXPC sometimes can't resync with anise (although, sometimes it does, magically), and I get the FAIL. -- Todd Day | todd@ivucsb.sba.ca.us | ivucsb!todd@anise.acc.com "But a machine that was powerful enough to accelerate particles to the grand unification energy would have to be as big as the Solar System -- and would be unlikely to be funded in the present economic climate." -- Stephen Hawking
doug@marque.mu.edu (10/20/89)
As lenny indicates, the "expected C" message describes an occurence during part of the uucp protocol transaction related to file copy. We have found that the "Bad Read" error in this phase is most often related to flow control settings - somehow an XON or XOFF gets through to uucp, which is not expecting such a thing and rejects it. Think of this advice as the doctor moving from saying "You are sick" to saying "You have a cold", a MUCH more specific diagnosis :-). This doctor does not know the cure.
pjh@mccc.uucp (Pete Holsberg) (10/21/89)
In article <989@icus.islp.ny.us> lenny@icus.islp.ny.us (Lenny Tropiano) writes: =In article <1989Oct16.181609.14182@mccc.uucp> pjh@mccc.UUCP (Pete Holsberg) =writes: =|>What causes the "BAD READ (expected 'C' got FAIL)"?? = =Basically when uucico is going through it's handshaking to coordinate between =the different files to send the ("D.*" and "X.*" files), uucico will stop =after each file and wait for an <ACK>nowledgement from the other site. = =*** TOP *** - role=1, setline - X =Request: icus!D.icus1eac709 --> att!D.icus1eac709 (lenny) =setline - S =wrktype - S = wmesg 'S' D.icus1eac709 D.icus1eac709 lenny - D.icus1eac709 0666 lenny =rmesg - 'S' got SY = PROCESS: msg - SY =SNDFILE: =-> 1683 / 1.416 = 1188.5 =rmesg - 'C' got CY = PROCESS: msg - CY =... = = ^^ If for some reason the remote site doesn't send back = anything, or gets out of sync, or there is noise on the = line... several (10 I think) alarm() calls will happen. = and eventually it will timeout with the message. = BAD READ (expected 'C' got FAIL) = Now the question is, what would cause the remote to sedn nothing or get out of sync consistently??? -- Pete Holsberg UUCP: {...!rutgers!}princeton!mccc!pjh Mercer College CompuServe: 70240,334 1200 Old Trenton Road GEnie: PJHOLSBERG Trenton, NJ 08690 Voice: 1-609-586-4800
david@ms.uky.edu (David Herron -- One of the vertebrae) (10/21/89)
It's a failure in the protocol -- probably flow control causing packets
to be dropped.
At some moderately high level of the UUCP protocol it's sending commands
back and forth, like the "S" command is to send a file across. The
C command is something else. (Sorry, I don't know what).
One side is doing a read(2) which is failing. er.. I'd have to check in
the source, but I believe the "FAIL" means that the read returned <= 0
meaning an actual failure. For instance, the line might have dropped.
Either that or it simply timed out.
Well, I just glanced into the source and unfortunately the answer didn't
leap out at me. However ... The only place I could find that message being
printed is, as I say, at the level above the line protocol. It is waiting
to read a message from the remote side. The FAIL message is caused when
the read() doesn't return the correct number of characters -- like I said
above, <= 0 characters.
--
<- David Herron; an MMDF guy <david@ms.uky.edu>
<- ska: David le casse\*' {rutgers,uunet}!ukma!david, david@UKMA.BITNET
<-
<- New official address: attmail!sparsdev!dsh@attunix.att.comtodd@ivucsb.sba.ca.us (Todd Day) (10/21/89)
david@ms.uky.edu (David Herron -- One of the vertebrae) writes:
`Well, I just glanced into the source and unfortunately the answer didn't
`leap out at me. However ... The only place I could find that message being
`printed is, as I say, at the level above the line protocol. It is waiting
`to read a message from the remote side. The FAIL message is caused when
`the read() doesn't return the correct number of characters -- like I said
`above, <= 0 characters.
What I want to know it, since it did fail, why does it remove the file it
was trying to send? I don't think the program realizes that it removed
the file, because it does try to send it. Then I get a mail message from
uucp that a uucp transfer failed because it couldn't find the file.
--
Todd Day | todd@ivucsb.sba.ca.us | ivucsb!todd@anise.acc.com
"But a machine that was powerful enough to accelerate particles to the grand
unification energy would have to be as big as the Solar System -- and would
be unlikely to be funded in the present economic climate." -- Stephen Hawkingpjh@mccc.uucp (Pete Holsberg) (10/21/89)
In article <9588@marque.mu.edu> doug@marque.mu.edu (Douglas Harris) writes:
=As lenny indicates, the "expected C" message describes an occurence
=during part of the uucp protocol transaction related to file copy.
=We have found that the "Bad Read" error in this phase is most often
=related to flow control settings - somehow an XON or XOFF gets
=through to uucp, which is not expecting such a thing and rejects it.
=
=Think of this advice as the doctor moving from saying "You are sick"
=to saying "You have a cold", a MUCH more specific diagnosis :-).
=This doctor does not know the cure.
Thank you, doctor. :-) But I seem to have a cold all the time. Isn't
there something you can do? And when I get rid of this cold, is there
something I can do to avoid catching another?
--
Pete Holsberg UUCP: {...!rutgers!}princeton!mccc!pjh
Mercer College CompuServe: 70240,334
1200 Old Trenton Road GEnie: PJHOLSBERG
Trenton, NJ 08690 Voice: 1-609-586-4800res@cbnews.ATT.COM (Robert E. Stampfli) (10/21/89)
In article <9588@marque.mu.edu> doug@marque.mu.edu (Douglas Harris) writes: >the "Bad Read" error in this phase is most often >related to flow control settings - somehow an XON or XOFF gets >through to uucp, which is not expecting such a thing and rejects it. This is so common over networks. Isn't there some uucp protocol that will allow the use of XON and XOFF? Rob Stampfli att!cbnews!res (work) osu-cis.cis.ohio-state.edu!n8emr!kd8wk!res (home)
les@chinet.chi.il.us (Leslie Mikesell) (10/27/89)
In article <1989Oct20.202445.3048@mccc.uucp> pjh@mccc.UUCP (Pete Holsberg) >Now the question is, what would cause the remote to sedn nothing or get out of >sync consistently??? One possibility is that the transmission includes the "escape" sequence for a smartmodem. Hayes types are generally set for 3 plus characters (I won't include them literally because somehow, somewhere it will cause someone's line to drop...). A certain amount of idle time is required to preceed the sequence, but that can always happen by accident under unix. Les Mikesell