Hi, all.
I have fixed my strange UUCP problem that I reported last Friday night.
Fortunately, this happened before my Sunday afternoon deadline, when
one of the machines was due to go back to Lake Tahoe.
Thanks to:
----------
Celeste Stokely <celeste@xs.com>
Tim Pointing <tim@ben.dciem.dnd.ca>
Two people suggested solutions that were helpful. Tim was right on the
money, and his solution was very similar to the way I had just finished
solved the problem at my client's site. Celeste had some excellent
suggestions that pointed me in the right direction as well as pointed
out some errors in my uucp files setup.
The following is the summary description I had originally posted (the
full post is at the bottom of this message for archiving purposes):
Summary Description:
--------------------
If I use a password with a uucp connection account for dialing in, the
UUCP session appears to hang, and then timeout, after sending the
password during the UUCP initial chat.
Whereas, if I remove the password for the *same* uucp account in the
local system in /etc/passwd, and also remove the password chat field in
/etc/uucp/Systems in the other system (doing the dialing), the UUCP
session proceeds totally normally!
This has been repeated *many* times today, on two different systems
dialing into a third one, *and* dialing out from the third system to
one of the other ones. Identical results each time!
Connecting with a "cu" to a normal user account works totally and
completely normally. However, "tip" fails to work with the same port
and modem, claiming to be unable to "synchronize with hayes".
The Fix:
--------
I had set the serial line up for no parity. Turns out that the UUCP
operations attempt to use even parity by default. Most modems will
handle this properly, but the US Robotics Courier is sensitive to this
issue, and will not allow the UUCP protocols to cleanly handshake -
despite setting up the modem characteristics (I found a valid modem
manual!) to not use parity.
So, you have to force the issue for UUCP with this modem. This can be
done by modifying the /etc/uucp/Dialers entry. Here is a BEFORE:
hayes =,-, "" \dA\pTE1V1X1Q0S2=255S12=255\r\c OK\r \EATDT\T\r\c CONNECT
and AFTER:
hayes =,-, "" P_ZERO "" \dA\pTE1V1X1Q0S2=255S12=255\r\c OK\r \EATDT\T\r\c CONNECT
showing the differences.
Specifically, the sequence P_ZERO forces no parity, and causes the UUCP
transmission to successfully handshake.
Frankly, this is the first time I have had to use this (but it also the
first time I have used US Robotics modems). I still do not totally
understand why it worked *without* a password before (since I would
expect the handshaking to fail there too), but this seems to solve the
problem cleanly!
Tim recommended modifying the /etc/uucp/Systems entry as follows:
redwood Any ACU Any XXXXXXX "" P_ZERO "" \r in:--in: Umenlo word: XXXXXXX
and this should also work, but I did not test it per se, since his
message arrived after I had returned from the client's site.
Other Comments:
---------------
A. Two entries
--------------
Celeste pointed out that I did not need to have two entries for each
site in the /etc/uucp/Permissions file as I had done (one shown here):
MACHINE=redwood MYNAME=menlo COMMANDS=ALL REQUEST=yes SENDFILES=yes READ=/var/spool/uucppublic WRITE=/var/spool/uucppublic
LOGNAME=Uredwood MYNAME=menlo MACHINE=redwood COMMANDS=ALL REQUEST=yes SENDFILES=yes READ=/var/spool/uucppublic WRITE=/var/spool/uucppublic
That is correct. Originally, I had started out with just a LOGNAME
entry and added the other one to see if I was doing something wrong. I
was groping for a solution really.
The MACHINE entry is normally used for connecting OUT to the remote
site, and the LOGNAME entry is used for the remote site to dial IN. If
the options specified for these are the same (as in the case above),
the entry *can* easily be simplified to just the LOGNAME entry shown.
The reason having two entries can be useful is if the options are
different. For example, you may want one site to be able to execute
programs at the other, but not vice-versa.
B. Potential Security Problem
-----------------------------
Celeste also pointed out that the option "COMMANDS=ALL" can be a major
security problem. I agree - I say the same thing in my modem
document. I used this open setup to do my testing, and also because
the client wanted to be able to do everything. I have since changed
this to read "COMMANDS=rmail:uucp" as this is going to be the primary
use of this uucp link. My clients can change this later if they want.
C. Transmission Rate Ambiguous
------------------------------
I noted one other problem in the /etc/uucp/Systems file. I specified a
connection to be as follows (phone and password hidden):
redwood Any ACU Any XXXXXXX "" \r in:--in: Umenlo word: XXXXXXX
Well, this usually works, but if the corresponding entry in the
/etc/uucp/Devices file is:
ACU cua0 - Any hayes
then the connection uses the last port rate the line was left at, since
I effectively left the transmission rate to be used, fairly ambiguous.
For uucp, this will then default to 9600. This works fine, but it does
not optimize usage of the v.32bis modem.
So I changed the entries in /etc/uucp/Systems to look like:
redwood Any ACU 38400 XXXXXXX "" \r in:--in: Umenlo word: XXXXXXX
and things are now running at 38400 bps cleanly.
Z
-------------------------------------------------------------------------
| Syed Zaeem Hosain P. O. Box 610097 (408) 441-7021 |
| Z Consulting Group San Jose, CA 95161 szh@zcon.com |
-------------------------------------------------------------------------
For reference, here is a copy of the original post:
> Hi, all!
>
> Introduction:
> -------------
>
> Although I have done *many* successful UUCP installations, I have
> finally come up against a strange difficulty with a UUCP setup that I
> *just* do not understand the reason for, and am hoping that someone
> can instantly see something I am overlooking. Please! :-)
>
> There is a little bit of an urgency with this - I am working on one
> system here that will be going to another site in Lake Tahoe on
> Sunday, so I hope to cure the problem by tomorrow (this is being sent
> out on Friday night).
>
> Please pardon the lengthy post - I like to make sure that I have
> provided enough information here, in the hope that this will help
> somebody provide me with the right answer!
>
> Summary Description:
> --------------------
>
> If I use a password with a uucp connection account for dialing in, the
> UUCP session appears to hang, and then timeout, after sending the
> password during the UUCP initial chat.
>
> Whereas, if I remove the password for the *same* uucp account in the
> local system in /etc/passwd, and also remove the password chat field
> in /etc/uucp/Systems in the other system (doing the dialing), the UUCP
> session proceeds totally normally!
>
> This has been repeated *many* times today, on two different systems
> dialing into a third one, *and* dialing out from the third system to
> one of the other ones. Identical results each time!
>
> Connecting with a "cu" to a normal user account works totally and
> completely normally. However, "tip" fails to work with the same port
> and modem, claiming to be unable to "synchronize with hayes".
>
> Hardware:
> ---------
>
> System 1 : Sun ELC
> OS : SunOS 4.1.3
> Patches : 100513-04 (tty jumbo patch)
> Name : redwood
> Modem : US Robotics Courier V.32bis
>
> System 2 : Sun Sparc 5
> OS : SunOS 4.1.3_U1B
> Patches : 101621-02 (tty jumbo patch)
> Name : tahoe
> Modem : US Robotics Courier V.32bis
>
> System 3 : Sun Sparc IPX
> OS : SunOS 4.1.3
> Patches : 100513-04 (tty jumbo patch)
> Name : menlo
> Modem : US Robotics HST Dual Standard
>
> UUCP Files:
> -----------
>
> On "menlo":
> -----------
>
> I created two accounts and assigned them passwords (not shown here):
>
> Uredwood:XXXXXXX:4:8::/var/spool/uucppublic:/usr/lib/uucp/uucico
> Utahoe:XXXXXXX:4:8::/var/spool/uucppublic:/usr/lib/uucp/uucico
>
> In /etc/uucp/Permissions, I added the following:
>
> MACHINE=redwood MYNAME=menlo COMMANDS=ALL REQUEST=yes SENDFILES=yes READ=/var/spool/uucppublic WRITE=/var/spool/uucppublic
> MACHINE=tahoe MYNAME=menlo COMMANDS=ALL REQUEST=yes SENDFILES=yes READ=/var/spool/uucppublic WRITE=/var/spool/uucppublic
> LOGNAME=Uredwood MYNAME=menlo MACHINE=redwood COMMANDS=ALL REQUEST=yes SENDFILES=yes READ=/var/spool/uucppublic WRITE=/var/spool/uucppublic
> LOGNAME=Utahoe MYNAME=menlo MACHINE=tahoe COMMANDS=ALL REQUEST=yes SENDFILES=yes READ=/var/spool/uucppublic WRITE=/var/spool/uucppublic
>
> In /etc/uucp/Systems, I added the following (phone number and password
> is not shown, and yes, I have verified that all the passwords are
> correct on all systems!):
>
> direct Any Direct Any
> redwood Any ACU Any XXXXXXX "" \r in:--in: Umenlo word: XXXXXXX
> tahoe Any ACU Any XXXXXXX "" \r in:--in: Umenlo word: XXXXXXX
>
> On "redwood":
> -------------
>
> I created two accounts and assigned them passwords (not shown here):
>
> Umenlo:XXXXXXX:4:8::/var/spool/uucppublic:/usr/lib/uucp/uucico
> Utahoe:XXXXXXX:4:8::/var/spool/uucppublic:/usr/lib/uucp/uucico
>
> I created the following entries in /etc/uucp/Permissions:
>
> MACHINE=menlo MYNAME=redwood COMMANDS=ALL REQUEST=yes SENDFILES=yes READ=/var/spool/uucppublic WRITE=/var/spool/uucppublic
> MACHINE=tahoe MYNAME=redwood COMMANDS=ALL REQUEST=yes SENDFILES=yes READ=/var/spool/uucppublic WRITE=/var/spool/uucppublic
> LOGNAME=Umenlo MYNAME=redwood MACHINE=menlo COMMANDS=ALL REQUEST=yes SENDFILES=yes READ=/var/spool/uucppublic WRITE=/var/spool/uucppublic
> LOGNAME=Utahoe MYNAME=redwood MACHINE=tahoe COMMANDS=ALL REQUEST=yes SENDFILES=yes READ=/var/spool/uucppublic WRITE=/var/spool/uucppublic
>
> In /etc/uucp/Systems, I added the following (phone number and password
> is not shown):
>
> direct Any Direct Any
> menlo Any ACU Any XXXXXXX "" \r in:--in: Uredwood word: XXXXXXX
> tahoe Any ACU Any XXXXXXX "" \r in:--in: Uredwood word: XXXXXXX
>
> On "tahoe:
> ----------
>
> I created two accounts and assigned them passwords (not shown here):
>
> Umenlo:XXXXXXX:4:8::/var/spool/uucppublic:/usr/lib/uucp/uucico
> Uredwood:XXXXXXX:4:8::/var/spool/uucppublic:/usr/lib/uucp/uucico
>
> I created the following entries in /etc/uucp/Permissions:
>
> MACHINE=menlo MYNAME=tahoe COMMANDS=ALL REQUEST=yes SENDFILES=yes READ=/var/spool/uucppublic WRITE=/var/spool/uucppublic
> MACHINE=redwood MYNAME=tahoe COMMANDS=ALL REQUEST=yes SENDFILES=yes READ=/var/spool/uucppublic WRITE=/var/spool/uucppublic
> LOGNAME=Umenlo MYNAME=tahoe MACHINE=menlo COMMANDS=ALL REQUEST=yes SENDFILES=yes READ=/var/spool/uucppublic WRITE=/var/spool/uucppublic
> LOGNAME=Uredwood MYNAME=tahoe MACHINE=redwood COMMANDS=ALL REQUEST=yes SENDFILES=yes READ=/var/spool/uucppublic WRITE=/var/spool/uucppublic
>
> In /etc/uucp/Systems, I added the following (phone number and password
> is not shown):
>
> direct Any Direct Any
> menlo Any ACU Any XXXXXXX "" \r in:--in: Utahoe word: XXXXXXX
> redwood Any ACU Any XXXXXXX "" \r in:--in: Utahoe word: XXXXXXX
>
> Common to all:
> --------------
>
> On all three systems, I added the following to the /etc/uucp/Devices
> file:
>
> Direct cua0 - Any direct
> ACU cua0 - Any hayes
>
> The /etc/uucp/Dialers file was not modified. So its entry for the Hayes
> modem is still:
>
> hayes =,-, "" \dA\pTE1V1X1Q0S2=255S12=255\r\c OK\r \EATDT\T\r\c CONNECT
>
> The /etc/gettytab fields are all pretty normal, with a selection of
> 38400 baud for the communication, with "p8" specified in the device
> types (was tried without "p8" as well - no luck).
>
> The /etc/ttytab fields are also normal, without "SECURE" in the line
> (prevents root login).
>
> The hardware handshaking on all lines concerned was properly set up as
> per my modem setup document which many of you may have seen.
>
> Modems:
> -------
>
> All three modems have the factory defaults except for turning on the
> hardware handshaking and various modem features such as no-autobaud,
> proper handling of DTR, etc.. This means that the modems were set for:
>
> &F0 &C1 &D2 &H1 &R2 &B1 E0 V0 &W
>
> as far as I can remember now away from the client site (One modem is
> an older model, and does not have multiple factory NVRAM settings so
> it was done with a "&F" rather than "&F0"), and the other options
> (unfortunately, I am not at the client site to report exactly what the
> modem options were!) were pretty much left untouched.
>
> In any case, it looks like all the modem options were correct, since
> "cu" is working totally normally as far as I can tell (an interesting
> side-effect, though, is still a problem ... "tip" failed with an error
> message of "Cannot synchronize with hayes" for the correct baud rate
> and correct setup of the port!).
>
> I tried "E1 V1" as well, thinking that the lack of verbose result
> codes was causing "tip" to mess up - no luck! And, yes, I did save the
> configuration to the modem after I changed values at any time and
> tried power-cycles of the modem as well!
>
> Problem Symptoms:
> -----------------
>
> 1. "cu" between all systems (with normal user accounts) is working
> totally normally with the above file configurations, as well as when
> the various "U*" accounts have no passwords. Since the UUCP accounts
> do not normally matter in this situation, this is not surprising.
>
> 2. When "cu" is used to connect to a uucp account, with passwords, I
> get the following (sample) response:
>
> menlo login: Uredwood
> Password: XXXXXXX
> Shere=menlo
>
> which indicates that the password is correct and the system is doing
> the right thing!
>
> When "cu" is used to connect to a uucp account, WITHOUT passwords in
> place, I get the following (sample) response:
>
> menlo login: Uredwood
> Shere=menlo
>
> which again indicates that things are probably okay! This worked on
> menlo for all the passwords that I tried from the other two machines.
>
> 3. However, when the password is in place, the /usr/lib/uucp/uucico
> program (via /usr/lib/uucp/Uutry or manually entered with the
> appropriate params: -r1 -smenlo -x5) fails! I see a final "Sent
> password ..." message and nothing else happens, and the uucico
> eventually times out!
>
> But without the passwords, everything is totally normal, and the Uutry
> and uucico sessions work perfectly normally! In addition, the system
> also cleanly dials in with the /etc/uucp/uudemon.hour script and
> performs all needed operations!
>
> 4. "tip" appears to fail consistently no matter what, with a "cannot
> synchronize with hayes" error message.
>
> Other:
> ------
>
> 1. I have tried using the "g" protocol for UUCP by modifying the ACU
> field. No difference in operation.
>
> 2. I have tried short account names (thinking that Uredwood may have
> been too long). No difference.
>
> 3. I have tried short passwords (since anything over 8 is ignored
> anyway). No difference.
>
> The Question(s):
> ----------------
>
> 1. First of all, is the US Robotics sufficiently close to a Hayes
> modem that the default "hayes" entries in the /etc/uucp/Dialers file
> ought to work? If not, what are better values to use? My take of the
> manual seems to imply that this should have worked, but I am not
> familiar enough with the USR to be confident of this.
>
> 2. Why does "tip" not "synchronize with hayes"? To me this is normally
> an indication that the modems are not really Hayes compatible, but
> they seems to work with "cu" pretty well! Confusing!
>
> 3. Can anybody hazard some suggestions as to why the addition of the
> password causes the UUCP session to hang like that?
>
> 4. Any other things that I could look at?
>
> Thanks for your help!
>
> Z
>
This archive was generated by hypermail 2.1.2 : Fri Sep 28 2001 - 23:09:10 CDT