stever@tree.UUCP (Steve Rudek) (11/01/88)
We're running Micrport System V/AT release 2.4 and need to change the tty default for incoming modem calls from the default (7 data bits even parity) to 8 data bits no parity to better accomodate new callers. About 6 months ago, under 2.2, I spent quite a bit of time experimenting with the gettydefs file. As I recall, I tried changing the standard entry: 1200# B1200 HUPCL PARENB CS7 CLOCAL OPOST ONLCR # B1200 HUPCL SANE IXANY TAB3 #login: #1200 to: 1200# B1200 HUPCL CS8 CLOCAL OPOST ONLCR # B1200 HUPCL SANE IXANY TAB3 #login: #1200 but it didn't make any significant difference. Why not? Why does UNIX default to 7 data bits/even parity, anyway? UUCP appears to configure the line before calling out (once again, I'm drawing on some fuzzy memories of experiments I ran long ago). While I understand the (intended) value of parity when doing file transfers, for interactive use it seems generally ignored. If I succeed in switching to 8 data bits will there be any unwanted side effects I should beware of? I was told by one of the tech support folks at microport that the "#" in the center of the gettydefs record delimits line condition BEFORE login from line condition AFTER login. Is this correct? In general, I'd be fascinated to hear the full story of what is really going on in a gettydefs entry. While I can look up the supposed definition of some of these field mnemonics (e.g., "PARENB" or "CS7") I feel that the UNIX documentation is extremely inadequate in describing the available options and interactions in line control settings.
logan@vsedev.VSE.COM (James Logan III) (11/02/88)
In article <130@tree.UUCP> stever@tree.UUCP (Steve Rudek) writes: >We're running Micrport System V/AT release 2.4 and need to change the tty >default for incoming modem calls from the default (7 data bits even parity) >to 8 data bits no parity to better accomodate new callers. About 6 >months ago, under 2.2, I spent quite a bit of time experimenting with the >gettydefs file. As I recall, I tried changing the standard entry: > >1200# B1200 HUPCL PARENB CS7 CLOCAL OPOST ONLCR # B1200 HUPCL SANE IXANY TAB3 #login: #1200 > >to: > >1200# B1200 HUPCL CS8 CLOCAL OPOST ONLCR # B1200 HUPCL SANE IXANY TAB3 #login: #1200 > >but it didn't make any significant difference. Why not? > Getty sets your line to seven data bits after you type in a login name if you don't tell it specifically how many data bits you want. (It has default settings so that the line is reasonable when you don't tell it specifically what to use.) Put CS8 after the second pound-sign (#) like this: | V 1200# B1200 HUPCL CS8 CLOCAL OPOST ONLCR # B1200 HUPCL CS8 SANE IXANY TAB3 #login: #1200 >...I'd be fascinated >to hear the full story of what is really going on in a gettydefs entry. It's pretty simple. There is a line in /etc/inittab that causes the init(1m) process to invoke getty(1m) with the specified arguments. One of the arguments is the "label" of a line in the file /etc/gettydefs. (By the way -- numbers in parenthesis refer to UNIX manual section numbers; e.g. init(1m) refers to section 1M of the UNIX manuals entitled "System Administration Reference Guide".) The lines in gettydefs(4) have the following format: label#tty settings before#tty settings after#login prompt text#next label (I'm doing this from memory, so please excuse me if I left out a field...) The "tty settings before" field contains settings that are put into effect by calling ioctl(2) the first time the caller types his/her login name. As soon as the user presses return, the "tty settings after" are set for the tty port and login(1) is exec(2)ed, replacing the getty(1m) process. Login(1) is called with the login name as its first parameter and prompts the user for his/her password. When the password is incorrect, login continues prompting for the login-name/password until a correct password is entered or its timeout value is reached. If The user presses ^D or login times out, login dies and init(1m) starts another getty process. Getty uses the "next label" field of the line when the calling user presses the BREAK key. When the BREAK key is pressed, getty uses the line with "next label" in its "label" field and changes the line settings to the new specification. Usually, the lines in gettydefs(4) form a circular linked list from a high baud rate (like 9600) to the next lowest baud rate, down to the lowest baud rate (like 300 baud) and back around to the highest baud rate again. This allows the caller to press BREAK until getty matches the caller's baud rate. The "login prompt text" field is the login message that getty gives the caller. You may change this to whatever you want, but after login is called it uses its own "login:" prompt. -- Jim Logan logan@vsedev.vse.com (703) 892-0002 uucp: ..!uunet!vsedev!logan inet: logan%vsedev.vse.com@uunet.uu.net
guy@auspex.UUCP (Guy Harris) (11/02/88)
>As I recall, I tried changing the standard entry: > >1200# B1200 HUPCL PARENB CS7 CLOCAL OPOST ONLCR # B1200 HUPCL SANE IXANY TAB3 #login: #1200 > >to: > >1200# B1200 HUPCL CS8 CLOCAL OPOST ONLCR # B1200 HUPCL SANE IXANY TAB3 #login: #1200 > >but it didn't make any significant difference. Why not? Because SANE means "7 bits plus even parity". Not necessarily my definition of "sane", but what the hell.... >Why does UNIX default to 7 data bits/even parity, anyway? Historical reasons, I presume. >UUCP appears to configure the line before calling out (once again, I'm >drawing on some fuzzy memories of experiments I ran long ago). It has to, when using the "g" protocol; that requires an 8-bit data path. >While I understand the (intended) value of parity when doing file >transfers, Actually, some file transfer protocols use an 8-bit data path, and use their own checksumming (the "g" protocol mentioned above, for one). >for interactive use it seems generally ignored. If I succeed in >switching to 8 data bits will there be any unwanted side effects >I should beware of? If you set all your terminals, including dial-ups if any, to 8 bits + no parity, there shouldn't be a problem - unless other computers dialing in (e.g., for UUCP) are sending with parity enabled, in which case they may have trouble logging in. ("getty" strips the 8th bit itself, but "getpass", used by "login", doesn't.) >I was told by one of the tech support folks at microport that the "#" in the >center of the gettydefs record delimits line condition BEFORE login from >line condition AFTER login. Is this correct? Yes. That's why the SANE in the "after" settings is undoing the work you went through to set the character size to 8 bits. Try replacing SANE with: BRKINT ICRNL IXON OPOST ONLCR CS8 ISIG ICANON ECHO ECHOK in the "after" settings. >In general, I'd be fascinated to hear the full story of what is really >going on in a gettydefs entry. I got this from prowling the source code; you might try the "getty" and "gettydefs" man pages, but they may not tell you enough. >While I can look up the supposed definition of some of these field mnemonics >(e.g., "PARENB" or "CS7") I feel that the UNIX documentation is extremely >inadequate in describing the available options and interactions in line >control settings. UNIX documentation is often inadequate.
det@hawkmoon.MN.ORG (Derek E. Terveer) (11/03/88)
In article <130@tree.UUCP>, stever@tree.UUCP (Steve Rudek) writes: > I was told by one of the tech support folks at microport that the "#" in the > center of the gettydefs record delimits line condition BEFORE login from > line condition AFTER login. Is this correct? As i understand it, "yes, this is true." -- Derek Terveer det@hawkmoon.MN.ORG w(612)681-6986 h(612)688-0667 "A proper king is crowned" -- Thomas B. Costain
jfh@rpp386.Dallas.TX.US (John F. Haugh II) (11/04/88)
In article <130@tree.UUCP> stever@tree.UUCP (Steve Rudek) writes: >We're running Micrport System V/AT release 2.4 and need to change the tty >default for incoming modem calls from the default (7 data bits even parity) >to 8 data bits no parity to better accomodate new callers. About 6 >months ago, under 2.2, I spent quite a bit of time experimenting with the >gettydefs file. As I recall, I tried changing the standard entry: > >1200# B1200 HUPCL PARENB CS7 CLOCAL OPOST ONLCR # B1200 HUPCL SANE IXANY TAB3 #login: #1200 > >to: > >1200# B1200 HUPCL CS8 CLOCAL OPOST ONLCR # B1200 HUPCL SANE IXANY TAB3 #login: #1200 SANE is biting you. SANE contains all manner of bits you may not need. Try not using SANE but listing the modes individually. The System V we have here does not all you to remove modes with -CLOCAL [ a problem with SANE is that it may turn off modem control for modems or turn it on for hardwired terminals ] so we list the flags out the long way. Once you have written a new gettydef you will need to see if you are getting the correct flags by compiling the gettydefs file. Use the '-c' option to getty to check the flags which are going to be used. This will save you the effort of calling yourself on the phone. -- John F. Haugh II +----Make believe quote of the week---- VoiceNet: (214) 250-3311 Data: -6272 | Nancy Reagan on Richard Stallman: InterNet: jfh@rpp386.Dallas.TX.US | "Just say `Gno'" UucpNet : <backbone>!killer!rpp386!jfh +--------------------------------------
mann@intacc.uucp (Jeff Mann) (11/04/88)
In article <130@tree.UUCP> stever@tree.UUCP (Steve Rudek) writes: >We're running Micrport System V/AT release 2.4 and need to change the tty >default for incoming modem calls from the default (7 data bits even parity) >to 8 data bits no parity to better accomodate new callers. About 6 >months ago, under 2.2, I spent quite a bit of time experimenting with the >gettydefs file. As I recall, I tried changing the standard entry: > >1200# B1200 HUPCL PARENB CS7 CLOCAL OPOST ONLCR # B1200 HUPCL SANE IXANY TAB3 #login: #1200 > >to: > >1200# B1200 HUPCL CS8 CLOCAL OPOST ONLCR # B1200 HUPCL SANE IXANY TAB3 #login: #1200 > >but it didn't make any significant difference. Why not? > >I was told by one of the tech support folks at microport that the "#" in the >center of the gettydefs record delimits line condition BEFORE login from >line condition AFTER login. Is this correct? In general, I'd be fascinated Yes, the first part of the line is the settings that getty uses before executing /bin/login. It starts off in "raw" mode so that it can "adapt the system to the speed and type of terminal being used." However, Microport says that "Data terminals using 8-bit protocols are not supported through gettydefs (#316, ver 1.3, known limitation)". That means that the change you made above won't work, because the "autoconfigure" feature of getty can't handle 8 bits. This one had me stumped until I tried: 1200#B1200 OPOST ONLCR HUPCL# CS8 BRKINT ISTRIP ICRNL IXON IXOFF TAB3 OPOST ONLCR B1200 CREAD ISIG ICANON ECHO ECHOE ECHOK IXANY HUPCL#\nLog in as 'newuser' if you are one\nlogin: #300 That is, force CS8 to be used AFTER the login name has been received. This means that ANYONE logging in will be set to 8 bits, which is probably what you want. The login prompt is sent with no parity, because no data format is specified in the initial settings. I don't claim to be a wizard or anything ( I'm sure a few people will have a good laugh at my gettydef line ) but it works! -- | Jeff Mann - Inter/Access Videotex, Toronto ...uunet!mnetor!intacc!mann | | "A picture is worth 256 thousand words" {utzoo, utgpu}!chp!intacc!mann |
torsten@pcsbst.UUCP (Torsten Homeyer) (11/04/88)
In article <1215@vsedev.VSE.COM< logan@vsedev.VSE.COM (James Logan III) writes:
[..] V
<Getty sets your line to seven data bits after you type in a login
<name if you don't tell it specifically how many data bits you
<want. (It has default settings so that the line is reasonable
<when you don't tell it specifically what to use.) Put CS8 after
<the second pound-sign (#) like this:
[..] V
<1200# B1200 HUPCL CS8 CLOCAL OPOST ONLCR # B1200 HUPCL CS8 SANE IXANY TAB3 #login: #1200
That's the solution, but put the CS8 after the SANE, because in some
implementations SANE sets the character size.
Torsten.
---
Name : Torsten Homeyer {tho@pcsbst ; torsten@homeyer}.UUCP
Company : PCS GmbH, Munich W-Germany.
UUCP : ..uunet!unido!pcsbst!tho ..uunet!unido!pcsbst!sws4!torsten
PRIVAT: ..unido!{pcsbst,megalon,mikros,[altger,netmbx]!oldman}!homeyer!torsten
logan@vsedev.VSE.COM (James Logan III) (11/08/88)
In article <680@pcsbst.UUCP> sws4!torsten@pcsbst.UUCP (torsten) writes: >That's the solution, but put the CS8 after the SANE, because in some >implementations SANE sets the character size. > > Torsten. Oooops... He's right! Sorry about that, folks! -Jim -- Jim Logan logan@vsedev.vse.com (703) 892-0002 uucp: ..!uunet!vsedev!logan inet: logan%vsedev.vse.com@uunet.uu.net
gerti@ncrdk.dk (Gert Illemann) (11/08/88)
In article <130@tree.UUCP>, stever@tree.UUCP (Steve Rudek) writes: > We're running Micrport System V/AT release 2.4 and need to change the tty > default for incoming modem calls from the default (7 data bits even parity) > to 8 data bits no parity ... > ... I tried changing the standard entry: ... to: > 1200# B1200 HUPCL CS8 CLOCAL OPOST ONLCR # B1200 HUPCL SANE IXANY TAB3 #login: #1200 > but it didn't make any significant difference. Why not? Because you are using SANE, that will - among other settings - give you CS7 and PARENB > Why does UNIX default to 7 data bits/even parity, anyway? Most ports defaults to 7+even, because it used to be a good guess, as to what the terminal would like. That is even today a very good guess; the majority of terminals, used world-wide, are ASCII (more or less) based (not extended ASCII, just plain ASCII). As the character-width (unfortunately) still is only 8 bits in UNIX and as it's very nice to have some measure of assurance of what you type is what the program gets, most people prefer to use the eighth bit for parity checking. > ...If I succeed in switching to 8 data bits will > there be any unwanted side effects I should beware of? Yes ! dont use TAB3, it means "expand tabs to spaces"; normally that would be wrong (VERY wrong sometimes) for uucp-traffic. > I was told by one of the tech support folks at microport that the "#" in the > center of the gettydefs record delimits line condition BEFORE login from > line condition AFTER login. Is this correct? Yes, he was right there, syntax : name# initial settings (i.e. for opening and writing the login-message) \ # final settings (i.e. sat just before login is executed) # login-message \ #next-name >In general, I'd be fascinated > to hear the full story of what is really going on in a gettydefs entry. > While I can look up the supposed definition of some of these field mnemonics > (e.g., "PARENB" or "CS7") I feel that the UNIX documentation is extremely > inadequate in describing the available options and interactions in line > control settings. I wont't give you more of the story here, but, have you studied getty(1M), termio(7), gettydefs(4), stty(1) and maybe ioctl(2), I'm sure you know what to do. It's more than the part-time system-administrator cares to do, I know, so maybe you should ask your support-person(s) to do it :-) Gert Gert Illemann / gerti@ncrdk.dk (...uunet!mcvax!dkuug!ncrdk!gerti) NCR Danmark A/S, System Service Division Teglv{rksgade 31, DK-2100 Copenhagen O >>DISCLAIM.ABSOLUTE<< Nobody or -one, but I, claims to think so as it's probably incorrect, inconsistent, incoherent and generally untrustworthy
guy@auspex.UUCP (Guy Harris) (11/13/88)
>As the character-width (unfortunately) still is only 8 bits in UNIX It's not just a question of UNIX, it's a question of hardware. In the case of asynchronous serial ports, the hardware ultimately controls how many bits the system is willing to accept between the start and stop bits. Some asynchronous serial port hardware (most such hardware, I suspect) is capable of framing characters with a start bit, 9 other bits, and a stop bit; such hardware will treat 8 of those bits as data bits and the 9th as a parity bit. Not all software that controls that hardware will put it in this mode, however. Systems with a full System V-style tty driver interface will do so; just set CS8 and PARENB. This should include the system in question (it also includes SunOS 4.0 and later, and will probably include the next BSD release, since it will at least support a POSIX-style tty driver interface, and that permits 8 bits plus parity). Systems with a V7-style tty driver interface, such as current BSD systems, won't put the hardware in that mode; the software running inside some terminals may not do so either, in which case setting the host up to support this doesn't help you any. >> ...If I succeed in switching to 8 data bits will >> there be any unwanted side effects I should beware of? > >Yes ! dont use TAB3, it means "expand tabs to spaces"; normally that would >be wrong (VERY wrong sometimes) for uucp-traffic. If the guy wants 8-bit support for a user's terminal, rather than UUCP or some other software that wants an 8-bit "pass-through" binary data path, there should be no problem with setting TAB3; if the guy wants 8-bit support for a "pass-through" binary data path, the proper advice is "don't use OPOST", not "don't use TAB3", because *any* tty driver transformation of data on output - or input, for that matter - will be wrong.