russ@bbx.basis.com (Russ Kepler) (01/04/91)
I've got an interesting (in the Chinese curse sense) problem. A site that I provide a newsfeed and mailfeed to just upgraded his Sun 4 to 4.1 and his call in to my system now fails consistently. My system is running XENIX 2.3.3 with TCP installed. I suspected that his new uucp was sending the login data in even parity and not in 8 data, no parity. In checking the tty parms for the tty I've noticed that ISTRIP isn't being enable as the gettydefs documentation says it will. In forcing ISTRIP in the particular gettydefs entry it doesn't seem to show up. Anyway, it looks right now that that's probably the problem. Anyone encounter this before? Any solutions? -- Russ Kepler - Basis Int'l SNAIL: 5901 Jefferson NE, Albuquerque, NM 87109 UUCP: bbx.basis.com!russ PHONE: 505-345-5232
paulz@sco.COM (W. Paul Zola) (01/05/91)
In article <1173@bbx.basis.com> russ@bbx.basis.com (Russ Kepler) writes:
[ wants to set up his system to use 7-bits even parity for login ]
You can't just modify the stock gettydefs and have it work. This is
because the stock gettydefs entries use 'compound' settings such as
'sane'. To have users log in with 7-bits even parity create a
gettydefs entry containing the following settings:
z # B2400 OPOST ONLCR TAB3 BRKINT IGNPAR IXON IXANY PARENB ISTRIP
ECHO ECHOE ECHOK ICANON ISIG CS7 CREAD
# B2400 OPOST ONLCR TAB3 BRKINT IGNPAR IXON IXANY PARENB ISTRIP
ECHO ECHOE ECHOK ICANON ISIG CS7 CREAD # \r\n@!login: # z
Make sure that the 'z' at the beginning of the entry is the first
character on the line. Change your /etc/ttys file so that 'z' is the
index character. (In other words, change the line in /etc/ttys to read
0ztty1A - or whatever is appropriate for your system.) You should now be
able to log in at 2400 baud using 7-bits and even parity.
If desired, you can create additional entries for other baud rates, and
connect them in a group, similar to the 3-2-1 group in the stock
/etc/gettydefs file.
Of course, once you do this, no-one can log in on that line using
8-bits/no parity.
-
Paul Zola Software Support Engineer
paulz@sco.COM
Gotta tend the earth to grow a rose. - Emily Saliers
DISCLAIMER: I speak for myself, and not for SCO.edhew@xenitec.on.ca (Ed Hew) (01/05/91)
In article <13176@scorn.sco.COM> paulz@sco.COM (W. Paul Zola) writes: > [....] >Make sure that the 'z' at the beginning of the entry is the first >character on the line. Change your /etc/ttys file so that 'z' is the >index character. (In other words, change the line in /etc/ttys to read >0ztty1A - or whatever is appropriate for your system.) You should now be >able to log in at 2400 baud using 7-bits and even parity. > >If desired, you can create additional entries for other baud rates, and >connect them in a group, similar to the 3-2-1 group in the stock >/etc/gettydefs file. > >Of course, once you do this, no-one can log in on that line using >8-bits/no parity. While I've never had a need to do this, is there any reason why someone couldn't lengthen the cycling to include the currently gettydefs entries in the cycle? Of course, they'd want to notify their existing uucp callers to lengthen their chat scripts to include a few more "ogin:-\K-ogin:-\K-ogin:" sequences if they currently expect getty to use one of the standard entries, especially if things are suddenly set to start at the new "z" entry you mention. That's one of the nice things about /etc/gettydefs and /etc/ttys (or inittab under UNIX). You can mix and match and be creative if you have to. :-) >- >Paul Zola Software Support Engineer > paulz@sco.COM -- Ed. A. Hew <edhew@xenitec.on.ca>, XeniTec Consulting Services or if you're really stuck: ..!{watmath|lsuc}!xenitec!eah
root@crash.cts.com (Bill Blue) (01/06/91)
In <1173@bbx.basis.com> russ@bbx.basis.com (Russ Kepler) writes: }I suspected that his new uucp was sending the login data in even }parity and not in 8 data, no parity. In checking the tty parms }for the tty I've noticed that ISTRIP isn't being enable as the }gettydefs documentation says it will. In forcing ISTRIP in the }particular gettydefs entry it doesn't seem to show up. }Anyway, it looks right now that that's probably the problem. }Anyone encounter this before? Any solutions? Why not just have the BSD system add to the beginning of its expect-send sequence the following: "" P_ZERO. That sets the BSD uucp to 8N1 and should work just fine logging into Xenix. --Bill
russ@bbx.basis.com (Russ Kepler) (01/08/91)
In article <13176@scorn.sco.COM> paulz@sco.COM (W. Paul Zola) writes: > >In article <1173@bbx.basis.com> russ@bbx.basis.com (Russ Kepler) writes: >[ wants to set up his system to use 7-bits even parity for login ] Uhhh - no, I don't. I just want getty to work as it's documented. The documentation specifies that the 'SANE' mode enables some tty flags. In examining the flags set while getty/login is executing (ie, at all stages) I find that either the documentation is in error or that getty/login is failing. I don't want 7 data bits, even parity, even though that might enable a Sun4 to login, I want 8 data bits, no parity, high bit stripped. Just like the documentation say it's running. That's all. Try looking at the status of ISTRIP, read the gettydefs documentation and tell me that getty is working correctly. Then try to add ISTRIP to the gettydefs and see if there's a change. Then fix getty. >Paul Zola Software Support Engineer > paulz@sco.COM -- Russ Kepler - Basis Int'l SNAIL: 5901 Jefferson NE, Albuquerque, NM 87109 UUCP: bbx.basis.com!russ PHONE: 505-345-5232
russ@bbx.basis.com (Russ Kepler) (01/08/91)
In article <6738@crash.cts.com> root@crash.cts.com (Bill Blue) writes: >}Anyone encounter this before? Any solutions? > >Why not just have the BSD system add to the beginning of its >expect-send sequence the following: "" P_ZERO. That sets the BSD uucp >to 8N1 and should work just fine logging into Xenix. You're right, that will work (and has been suggested by a few others in email. I'm just annoyed that getty and gettydefs in SCO XENIX won't work - and all the suggestions from SCO are to screwup the login so that only certain systems can login. I thought that my post was reasonable, the it is reasonable to expect that the code should work as documented. -- Russ Kepler - Basis Int'l SNAIL: 5901 Jefferson NE, Albuquerque, NM 87109 UUCP: bbx.basis.com!russ PHONE: 505-345-5232
root@crash.cts.com (Bill Blue) (01/10/91)
In <1181@bbx.basis.com> russ@bbx.basis.com (Russ Kepler) writes: (stuff about P_ZERO deleted) }You're right, that will work (and has been suggested by a few others }in email. I'm just annoyed that getty and gettydefs in SCO XENIX }won't work - and all the suggestions from SCO are to screwup the login }so that only certain systems can login. }I thought that my post was reasonable, the it is reasonable to expect }that the code should work as documented. You're right, it should, but doesn't. I've spent much time trying to find a combination of flags that will, in effect, enable 8 bit no parity with the high bit stipped. That should let it work correctly with a 7E1 caller. However, the problem, like you said, is that getty is broken. It doesn't respond to flags the same in the first group (prior to the first #) as it does to the same settings in the second group. The second group works correctly. This behavior can be seen by running the test gettydefs file through getty -c and looking at the ioctl values produced. Very enlightening. --Bill
jfh@rpp386.cactus.org (John F Haugh II) (01/10/91)
In article <1180@bbx.basis.com> russ@bbx.basis.com (Russ Kepler) writes: >The documentation specifies that the 'SANE' mode enables some tty >flags. In examining the flags set while getty/login is executing >(ie, at all stages) I find that either the documentation is in >error or that getty/login is failing. I've had good success with listing out the modes that I want rather than just relying on 'SANE' in the past. However, I now just use the following and it works fine as far as I can tell. v # B2400 CS8 ISTRIP HUPCL BRKINT SANE -CLOCAL HUPCL # B2400 CS8 ISTRIP SANE HUPCL IXANY -CLOCAL #River Parishes Programming, Austin, TX\r\nlogin: # u The only thing I've changed in 3 years has been the login prompt to include various threats of prosecution against wayward hackers. I've had contact with quite a few BSD and Sun machines in the past and presently see several calls a day from the Dallas Sun office. -- John F. Haugh II UUCP: ...!cs.utexas.edu!rpp386!jfh Ma Bell: (512) 832-8832 Domain: jfh@rpp386.cactus.org "While you are here, your wives and girlfriends are dating handsome American movie and TV stars. Stars like Tom Selleck, Bruce Willis, and Bart Simpson."
pgd@bbt.se (01/11/91)
In article <1180@bbx.basis.com> russ@bbx.basis.com (Russ Kepler) writes: >Just like the documentation say it's running. That's all. Try >looking at the status of ISTRIP, read the gettydefs documentation >and tell me that getty is working correctly. Then try to add >ISTRIP to the gettydefs and see if there's a change. > >Then fix getty. > I agree fully. According to my experience, getty refuses to set ISTRIP for the settings it issues before the prompt. For the after-prompt settings it works. If you have a terminal which always sets the high-bit, you are finished. You can never come past the first prompt, to set ISTRIP at the second setting. I can't remember what I did to finally get it working, but looking in the /etc/gettydefs, the terminal setting for that terminal brand is: ... CS7 # SANE CS8 ISTRIP ... If you tell getty it is a 7-bit line, it will ignore the 8th bit. You can always use the AUTO setting, to skip the first tty setting from getty. But then you get some other problems with the login program..... P. Garbha