tanner@ki4pv.UUCP (Tanner Andrews) (01/03/86)
If you are using UUCP with xenix 3.0(up through 3.0b at least) you will probably encounter this when someone is trying to UUCP to your site for the first time. Repeat by: Set up a correct system entry to call someone running xenix uucp. Pick a line and condition it for output as required. Use the command uucico -r1 -Ssysname -X9 This should provide debugging information. Problem is that the "-X9" information is passed along to the called system. If the called system is a xenix system, it will start the remote uucico with the debug flag, and the remote system will mix the diagnostics with the uucp handshake and such. Horrible confusion is a result, which is why I like the helpful diag msg in the remote (xenix) system's logfile: uucp xsys (mm/dd-hh:mm) CAUGHT (SIGNAL 1) Where "uucp" = uucp login, "xsys" = name of xenix system, and date-time are within the parens. This is particularly pernicious, because it appears when you most need for things to work right: when you are setting up and testing a connection for the first time! Fix: Determine whether any system to which you are about to establish a link is a xenix system. If you are a xenix system to which someone is trying to establish a link, warn them. If uucico is invoked without the debugging (no -Xn), it works OK. If this problem has appeared elsewhere, I would be interested in hearing of it by mail please. -- <std dsclm, copies upon request> Tanner Andrews, KI4PV uucp: ...!decvax!ucf-cs!ki4pv!tanner
grr@unirot.UUCP (George Robbins) (01/04/86)
Summary: Expires: References: <7024@ki4pv.UUCP> Sender: Reply-To: grr@unirot.UUCP (George Robbins) Followup-To: Distribution: Organization: The Soup Kitchen, Piscataway NJ Keywords: xenix In article <7024@ki4pv.UUCP> tanner@ki4pv.UUCP (Tanner Andrews) writes: >If you are using UUCP with xenix 3.0(up through 3.0b at least) you will >probably encounter this when someone is trying to UUCP to your site for >the first time. > > Problem is that the "-X9" >information is passed along to the called system. If the called system >is a xenix system, it will start the remote uucico with the debug flag, >and the remote system will mix the diagnostics with the uucp handshake >and such. > Tanner Andrews, KI4PV I have also seen this problem when calling Xenix running on a PC/AT. Please note that it is supposed to pass on the -x switch. This is intended to cause debugging information to be written to the AUDIT file on the called System. Unfortunately, someone at Microsoft screwed something up, and the information is written out over the wire. This will cause unreal pain and confusion unless you happen to have a line monitor lying around. I have no idea whether anyone has reported or discussed this problem with the vendor. -- George Robbins uucp: ...!ihnp4!tapa!grr P.O. Box 177 ...!caip!unirot!grr Lincoln U, PA 19352 [Any ideas herein are not responsible for themselves!]
csg@pyramid.UUCP (Carl S. Gutekunst) (01/07/86)
In article <7024@ki4pv.UUCP> tanner@ki4pv.UUCP (Tanner Andrews) writes: > ... >This should provide debugging information. Problem is that the "-X9" >information is passed along to the called system. If the called system >is a xenix system, it will start the remote uucico with the debug flag, >and the remote system will mix the diagnostics with the uucp handshake >and such. This will happen on any UUCP when the /usr/spool/uucp/AUDIT file is unwritable. The -x9 flag is supposed to be passed along. In slave role cico.c freopen()'s stderr to AUDIT (that is, it closes and reopens on the stderr file pointer). But the operation isn't error checked, so if it fails all the debugging output gets poured into the modem. Quick fix is to try rm'ing /usr/spool/uucp/AUDIT; after that uucico should take care of itself since it is suid to UUCP, and has write permission to the spool directory. If that doesn't fix it, then Microsoft has somehow managed to break UUCP even worse than it was. This bug has been fixed in 4.3bsd, BTW. It also makes AUDIT a directory, with one log file per site.... -- Carl S. Gutekunst {allegra,cmcl2,decwrl,hplabs,topaz,ut-sally}!pyramid!csg Pyramid Technology Corp, Mountain View, CA +1 415 965 7200 Look, Ma, no graphics!
tanner@ki4pv.UUCP (Tanner Andrews) (01/07/86)
] csg@pyramid.UUCP writes that one should try rm'ing "AUDIT" so that ] a freopen() will work. Sad to say, at least on this system, the "AUDIT" file doesn't exist. The freopen() call [if such is the mechanism] does not seem to work. I will, however, try leaving around an existing, writable "AUDIT" file for the future; report on results sometime later this week (when I get a customer system here in DLD running and communicating). -- <std dsclm, copies upon request> Tanner Andrews, KI4PV uucp: ...!decvax!ucf-cs!ki4pv!tanner
cspencer@bbncc5.UUCP (Clifford Spencer) (01/08/86)
> This will happen on any UUCP when the /usr/spool/uucp/AUDIT file is unwritable. > The -x9 flag is supposed to be passed along. In slave role cico.c freopen()'s > stderr to AUDIT (that is, it closes and reopens on the stderr file pointer). > But the operation isn't error checked, so if it fails all the debugging output another manifestation of this type of bug is to get the debugging output in LOGFILE. This can occur running 4.3 uucico on 4.2 /usr/spool/uucp where (AUDIT != directory) or vice versa. -cliff -- cliff spencer {harvard, ihnp4, decvax}!bbnccv!cspencer cspencer@bbncc5.arpa
tanner@ki4pv.UUCP (Tanner Andrews) (01/13/86)
] unwritable "AUDIT" file can cause some wicked problems... Even a writable "AUDIT" file under xenix may not work. The moral is to be careful about using the debug flag to talk to new sites. Try it without this flag and see if it works. You may not need to debug. -- <std dsclm, copies upon request> Tanner Andrews, KI4PV uucp: ...!decvax!ucf-cs!ki4pv!tanner