davidsen@steinmetz.steinmetz.UUCP (William E. Davidsen Jr) (01/23/88)
I have a Xenix/386 (2.2.1) system which is called by an Ultrix 2.0 VAX
for uucp transfer. The connection procedes until the password is
entered from L.sys, then the VAX hangs waiting for Shere. A number of
other systems have no trouble dialing into the system (it's the hub
machine for the *IX user's group), so I don't think uucp logins are
broken.
When Xenix calls Ultrix the connection works correctly.
Any help, ideas, even rude messages telling us to read the manual (as
long as you hint which manual and section). Since this is our net
connection we would like to get it fixed.
Note, the VAX calls other Xenix/286 2.1.3 machines without problems, if
that helps.
--
bill davidsen (wedu@ge-crd.arpa)
{uunet | philabs | seismo}!steinmetz!crdos1!davidsen
"Stupidity, like virtue, is its own reward" -mecarlson@scooter.UUCP (Joe Carlson) (01/23/88)
In article <9303@steinmetz.steinmetz.UUCP> davidsen@steinmetz.steinmetz.UUCP (William E. Davidsen Jr) writes: >I have a Xenix/386 (2.2.1) system which is called by an Ultrix 2.0 VAX >for uucp transfer. The connection procedes until the password is >entered from L.sys, then the VAX hangs waiting for Shere. Try sending a LF (\012) after sending the password. Joe Carlson carlson@scooter.UUCP or uunet!lll-winken!carlson
wswietse@eutrc3.UUCP (Wietse Venema) (01/24/88)
In article <9303@steinmetz.steinmetz.UUCP>, davidsen@steinmetz.steinmetz.UUCP (William E. Davidsen Jr) writes: > I have a Xenix/386 (2.2.1) system which is called by an Ultrix 2.0 VAX > for uucp transfer. The connection procedes until the password is > entered from L.sys, then the VAX hangs waiting for Shere. A number of > other systems have no trouble dialing into the system (it's the hub > machine for the *IX user's group), so I don't think uucp logins are > broken. Check the execute permissions of your /usr/lib/uucico. It should be executable for the (uid,gid) that the Vax logs in with. Wietse
raj@spl1.UUCP (Robert Alan Johnson) (01/25/88)
From article <9303@steinmetz.steinmetz.UUCP>, by davidsen@steinmetz.steinmetz.UUCP (William E. Davidsen Jr): > I have a Xenix/386 (2.2.1) system which is called by an Ultrix 2.0 VAX > for uucp transfer. The connection procedes until the password is > entered from L.sys, then the VAX hangs waiting for Shere. A number of > other systems have no trouble dialing into the system (it's the hub > machine for the *IX user's group), so I don't think uucp logins are > broken. > Hi, we've seen this a lot. The answer is almost always the same. **PARITY** In xenix (starting with 2.2) they went to a no parity default. It seems that most UNIX's in the world are 7 bit even. (BTW: SCO says the no parity 8 bit configuration is to permit support of non-english character sets.) In some uucp's, uucico is sensitive to parity, PARTICULARLY ULTRIX. We feed news to quite a few sites and ALL ULTRIX and ENCORE systems seem to have the problem EXACTLY as you've described it. The solution is simple. Almost all of the uucp's out there permit you to specify parity with sepcial commands in the CHAT script, some use P0 as the specification for no parity. Check with your uucp manual to make sure. Bob Johnson The Software Public Library, Chicago, IL ...ihnp4!spl1!raj ...1-312-248-5777
root@conexch.UUCP (Larry Dighera) (01/28/88)
In article <9303@steinmetz.steinmetz.UUCP> davidsen@steinmetz.steinmetz.UUCP (William E. Davidsen Jr) writes: >I have a Xenix/386 (2.2.1) system which is called by an Ultrix 2.0 VAX >for uucp transfer. The connection procedes until the password is >entered from L.sys, then the VAX hangs waiting for Shere. As I recall, Xenix' stty sane defaults to 8 bit no parity. This causes the Ultrix machine to get a garbled password. Try adding CS7 PARENB to the inital and secondary flags in /etc/gettydefs. It worked for me. Larry Dighera -- USPS: The Consultants' Exchange, PO Box 12100, Santa Ana, CA 92712 TELE: (714) 842-6348: BBS (N81); (714) 842-5851: Xenix guest account (E71) UUCP: conexch Any ACU 2400 17148425851 ogin:-""-ogin:-""-ogin: nuucp UUCP: ...!ucbvax!ucivax!mickey!conexch!root || ...!trwrb!ucla-an!conexch!root
davidsen@steinmetz.steinmetz.UUCP (William E. Davidsen Jr) (02/02/88)
In article <192@conexch.UUCP> root@conexch.UUCP (Larry Dighera) writes: | [... my BSD to Xenix/386 problem ...] | As I recall, Xenix' stty sane defaults to 8 bit no parity. This causes the | Ultrix machine to get a garbled password. Try adding CS7 PARENB to the | inital and secondary flags in /etc/gettydefs. It worked for me. I am willing to believe that there is a parity problem, however I am still looking for a useful solution. If I set default parity to even everything else will go to hell. I can't afford to tie up one more line just to let calls come in from one system. My alternative solution was to have the login call up a program other than uucico which would reset the line parity and exec uucico. This doesn't work, reason unknown. The line reset works, if I fork something other than uucico it runs even parity. If I fork uucico I get no parity again. To test this I put a sleep between the line set and the exec, then looked at the line with stty from another terminal. The line was reset to no parity when uucico started. I then manually used stty to force a console even, and started uucico. When it timed out the parity was off again (it may be resetting to sane). I even tried doing a fork, waiting for uucico to start, *then* setting the line the even. Again it got reset to no parity. I have had three or four people tell me that the parity may be reset in the BSD char script. The sysmgr is willing (eager) to do this, but can't find any documentation on how. Was this deleted from Ultrix? Still looking for any suggestion, and very happy at the support so far. Hopefully I've stated the problem in more detail this time. -- bill davidsen (wedu@ge-crd.arpa) {uunet | philabs | seismo}!steinmetz!crdos1!davidsen "Stupidity, like virtue, is its own reward" -me
raj@spl1.UUCP (Robert Alan Johnson) (02/03/88)
From article <9384@steinmetz.steinmetz.UUCP>, by davidsen@steinmetz.steinmetz.UUCP (William E. Davidsen Jr): > In article <192@conexch.UUCP> root@conexch.UUCP (Larry Dighera) writes: > | [... my BSD to Xenix/386 problem ...] > | As I recall, Xenix' stty sane defaults to 8 bit no parity. This causes the > | Ultrix machine to get a garbled password. Try adding CS7 PARENB to the > | inital and secondary flags in /etc/gettydefs. It worked for me. > > I am willing to believe that there is a parity problem, however I am > still looking for a useful solution. If I set default parity to even > everything else will go to hell. I can't afford to tie up one more line > just to let calls come in from one system. > I don't seem to understand your problem! As I remarked in my previous reply I've seen this problem alot! I also tried to solve it on my end by setting the gettydefs stuff to appropriate values, but it seems to me that you've got it backward. The systems which call you can *EASILY* alter their L.sys chat scripts to call your system in a no parity mode. I feed news to over 15 sites, with the most diverse mix of machines you can imagine (We still have quite a few feed slots available including both Trailblazer and Courrier HST high speed links for anyone interested.) I've seen this parity problem *CONSISTANTLY* on the following: Sun 2 and 3 Encore DEC/ULTRIX It seems to be related to the BSD4.2 uucico! In the systems which call me they simply put either P_0 or P_ZERO in their L.sys (depending on their uucp flavor) entry and the problem is *CURED* simply, quickly with no compromise on my system. Why are you fighting it on your end? Bob Johnson The Software Public Library ...ihnp4!spl1!raj ...1-248-5777