larrys@adsi.UUCP (Larry Slavick) (06/28/90)
Hello;
Has anyone connected a USR HST dual standard to a NCR Tower 32/700?
I would like to know how to set up the configuration files to take
full advantage of this modem in either HST or v.32 modes. I would
like to use this modem for dial-in or dial-out access. Any help
would be appreciated.
Larry Slavick
--
Larry A. Slavick Application Data Systems, Inc.
WORK: (601)393-2046 HOME: (901)853-5967 Southaven, Mississippi
UUCP: {fedeva,chromc}!dynasys!adsi!larrys USAdavis@ncrclt.Dayton.NCR.COM (Susan Davis) (06/30/90)
> From: uunet!adsi!larrys (Larry Slavick) > Newsgroups: comp.sys.ncr,comp.dcom.modems > Message-Id: <150@adsi.UUCP> > Date: 28 Jun 90 14:37:15 GMT > Has anyone connected a USR HST dual standard to a NCR Tower 32/700? > I would like to know how to set up the configuration files to take Larry, I haven't connected a USR HST but I know from trying uucp on a 32/700 that only an NCR 2500 microcom modem works with uugetty and that uugetty has got enough bugs in the first release (1.0) that you would be better if you used a separate modem for dialing in and dialing out and don't use it at all. Susan Davis ncrclt
nolan@tssi.UUCP (Michael Nolan) (07/03/90)
In article <150@adsi.UUCP>, larrys@adsi.UUCP (Larry Slavick) writes: > LS> Has anyone connected a USR HST dual standard to a NCR Tower 32/700? LS> I would like to know how to set up the configuration files to take LS> full advantage of this modem in either HST or v.32 modes. I would LS> like to use this modem for dial-in or dial-out access. Any help LS> would be appreciated. In an item on the NCR mailing list that I haven't seen on comp.sys.ncr, Susan Davis replies: SD> I haven't connected a USR HST but I know from trying uucp on a 32/700 that SD> only an NCR 2500 microcom modem works with uugetty and that uugetty has SD> got enough bugs in the first release (1.0) that you would be better if SD> you used a separate modem for dialing in and dialing out and don't use SD> it at all. Perhaps all this applies to the 32/700 but not to other Towers. I'm running a 450, on 2.01.00 (aka System V Release 2 1/2). I'm using uugetty on a bidirectional line and an Everex 2400 modem. The only problem I've encountered, which I've documented in this newsgroup before, is that the system fails to log off a user if the phone line drops without a CTRL-D having been sent, this leaving a slight security hole. I've also been able to use a very non-Hayes modem in this capacity, and the biggest problem I had was writing a Devices entry to handle dial-outs. I understand NCR attempted to 'improve' uugetty, and that some of the improvements didn't work out so well. And if the 700 is substantially different than the 450, excuuuuse me! Below are the entries from my system: The inittab entry for this line is as follows: t07:1:respawn:/usr/lib/uucp/uugetty -h -r 3 -t 60 tty07 A vt100 I have made a few minor modifications in the gettydefs file, so that A cycles only between a 2400 baud (first choice) and a 1200 baud line: A# B2400 ISTRIP CS7 PARENB NL1 CR1 ECHO # B2400 HUPCL PARENB TAB3 ECHO SANE #login: #A2 A2# B1200 ISTRIP CS7 PARENB NL1 CR1 ECHO # B1200 HUPCL PARENB TAB3 ECHO SANE #login: #A B# B300 ISTRIP CS7 PARENB NL1 CR1 ECHO # B300 HUPCL PARENB TAB3 ECHO SANE #login: #B C# B9600 ISTRIP CS7 PARENB NL1 CR1 ECHO # B9600 HUPCL PARENB TAB3 ECHO SANE #login: #C Contents of Devices entry: ACU tty07 - 1200 hayes ACU tty07 - 2400 hayes24 Dialers entry, modified as suggested by Vernon Hurdle: hayes =,-, "" \dATQ0L1&D3\r\c OK\r \EATDT\T\r\c CONNECT hayes24 =,-, "" \dATQ0L1&D3\r\c OK\r \EATDT\T\r\c CONNECT ------------------------------------------------------------------------------ Mike Nolan "I don't know what apathy is, Tailored Software Services, Inc. and I don't want to find out!" Lincoln, Nebraska (402) 423-1490 UUCP: tssi!nolan should work, if not try something like uunet!frith!upba!tssi!nolan
davis@ncrclt.Dayton.NCR.COM (07/06/90)
In article <150@adsi.UUCP>, larrys@adsi.UUCP (Larry Slavick) writes: > LS> Has anyone connected a USR HST dual standard to a NCR Tower 32/700? > LS> I would like to know how to set up the configuration files to take > LS> full advantage of this modem in either HST or v.32 modes. I would > LS> like to use this modem for dial-in or dial-out access. Any help > LS> would be appreciated. > > In an item on the NCR mailing list that I haven't seen on comp.sys.ncr, > Susan Davis replies: > > SD> I haven't connected a USR HST but I know from trying uucp on a 32/700 th > SD> only an NCR 2500 microcom modem works with uugetty and that uugetty has > Perhaps all this applies to the 32/700 but not to other Towers. I'm running > a 450, on 2.01.00 (aka System V Release 2 1/2). I'm using uugetty on a > bidirectional line and an Everex 2400 modem. The only problem I've > encountered, which I've documented in this newsgroup before, is that the > system fails to log off a user if the phone line drops without a CTRL-D > having been sent, this leaving a slight security hole. > > I've also been able to use a very non-Hayes modem in this capacity, and > the biggest problem I had was writing a Devices entry to handle dial-outs. > > I understand NCR attempted to 'improve' uugetty, and that some of the > improvements didn't work out so well. Mike - Unfortunately the 3/5/700 are substantially different than the rest of the systems, especially 4xx/6xx under 2.01. It deals with being driven by the streams drivers versus the pure hpsio and uugetty definately has bugs under release 1.00 but some are fixed under 1.01. To my knowledge many folks were never able to get uugetty to work if they had old 1200 baud ncr hayes lookalike modems. Sorry! Susan Davis cmd - NCR charlotte
vernon@ssi600.lonestar.org (Vernon E. Hurdle) (07/09/90)
> > LS> Has anyone connected a USR HST dual standard to a NCR Tower 32/700? > > LS> I would like to know how to set up the configuration files to take > > LS> full advantage of this modem in either HST or v.32 modes. I would > > LS> like to use this modem for dial-in or dial-out access. Any help > > LS> would be appreciated. > > In an item on the NCR mailing list that I haven't seen on comp.sys.ncr, > > Susan Davis replies: > > SD> I haven't connected a USR HST but I know from trying uucp on a 32/700 th > > SD> only an NCR 2500 microcom modem works with uugetty and that uugetty has > > Perhaps all this applies to the 32/700 but not to other Towers. I'm running > > a 450, on 2.01.00 (aka System V Release 2 1/2). I'm using uugetty on a > > bidirectional line and an Everex 2400 modem. The only problem I've > > encountered, which I've documented in this newsgroup before, is that the > > system fails to log off a user if the phone line drops without a CTRL-D > > having been sent, this leaving a slight security hole. > > I've also been able to use a very non-Hayes modem in this capacity, and > > the biggest problem I had was writing a Devices entry to handle dial-outs. > > I understand NCR attempted to 'improve' uugetty, and that some of the > > improvements didn't work out so well. > Mike - Unfortunately the 3/5/700 are substantially different than the rest > of the systems, especially 4xx/6xx under 2.01. It deals with being driven > by the streams drivers versus the pure hpsio and uugetty definately has > bugs under release 1.00 but some are fixed under 1.01. To my knowledge > many folks were never able to get uugetty to work if they had old 1200 > baud ncr hayes lookalike modems. > > Sorry! > > Susan Davis > cmd - NCR charlotte Susan and Mike, we have several computers using uugetty, including a 32/600 and 32/700. They are both using Multitech 224EH modems. The only problem I had in getting this to work 100% of the time, was caused by the command responses on the modem being set on all the time. This caused a problem because when the remote system dialed into our modem, it (our modem) would send the response "RING" (in upper case) to uugetty on our system. Our system would respond as though the remote system was using the login "RING". This was overcome by using a feature of the Multitech and, as I have learned since, many other modems' ablility to do a reset (ATZ) on loss of DTR (Data Terminal Ready). Using this feature, I set the modem's default settings to disable command responses (ATQ1). Then, I added a new entry in the dialers file for a multitech modem. This entry looked just like the hayes entry except it enabled command responses (ATQ0). In this way, when the modem dials out, it has the responses enabled. But as soon as you disconnect, and DTR is lost, the modem is reset to disable command responses. This now works all the time with no reported problems. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ~ Vernon E. Hurdle ~ ~ Seay Systems, Inc. ~ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
shawn@ncrcae.Columbia.NCR.COM (Shawn Shealy) (07/10/90)
>responses on the modem being set on all the time. This caused a problem >because when the remote system dialed into our modem, it (our modem) would >send the response "RING" (in upper case) to uugetty on our system. Our >system would respond as though the remote system was using the login "RING". Vernon, I do not know how you had your modem setup when you had this problem, but if it were setup so that the open() by uugetty would not complete until a call came in (this can be a verified by doing a ps and looking at the TTY field for the uugetty entry --- if it shows a ? then the open has not completed) then the -r<seconds> option of uugetty should have been used. Of course this is just another solution to your problem --- your solution works equally well with modems which can be set up to reset on DTR drop. From uugetty (1M): -r waittime Wait to read a character before putting out the login message, thus preventing two uugettys from looping. An intelligent modem or direct line that has a uugetty on each end must use the -r option. If there is a uugetty on one end of a direct line, there must be a uugetty on the other end as well, or no getty at all. If a waittime is specified, the system waits that amount of time after receipt of the first character and checking for the lock before input is flushed and a second character is sought. ... >> Mike - Unfortunately the 3/5/700 are substantially different than the rest >> of the systems, especially 4xx/6xx under 2.01. It deals with being driven >> by the streams drivers versus the pure hpsio and uugetty definately has >> bugs under release 1.00 but some are fixed under 1.01. To my knowledge >> many folks were never able to get uugetty to work if they had old 1200 >> baud ncr hayes lookalike modems. Susan, The uugetty source code is the same in 1.00.00 and 1.01.00. The problem with setting up a line to receive incoming calls and outgoing calls on the 3/5/700 has been solved in release 1.01.01. I implemented the solution myself. Furthermore the "old 1200 baud ncr hayes look alike modems" do work properly in this capacity --- I tested this myself. This release is currently in its test phase and I do not know when it will be customer available. The streams head single threads driver open() calls. If one process is in the middle of opening a device and a second process attempts to open() the device, then the second process will not cause the driver's open() routine to be invoked until the first process's open() has completed. This causes a problem in the case of a dial in/dial out modem as follows: A first process (for example uugetty) attempts to open() a tty device node which is attached to a modem without using the O_NDELAY flag. If carrier detect (DCD) or device ready (DSR or DTR) on that tty node is not present, then the driver routine suspends the process. If a call were now to come in to the modem, and the modem were to answer and hear the carrier tone, then it would assert carrier detect to the TOWER and the process's open() would complete. However, if someone wants to use the modem before a call comes in, they may execute the cu command. This process would try to open() the modem using the O_NDELAY flag which says not to wait on carrier detect and device ready to be active. However, this second open would hang waiting on the first open to complete. The solution implemented for 1.01.01 deals with using a different device node (with a new minor number) for outgoing calls than for incoming calls. I have attached a PRELIMINARY copy of the manual page which describes the new subdevice scheme. -shawn DIALOUT(7) DIALOUT(7) NAME dialout, dio - dial out tty lines DESCRIPTION For each asynchronous communications port governed by the nec driver (typically /dev/ttya and /dev/ttyb), the hp driver (hpsio ports), or the dtcs driver, there exist two logical devices. Use the cmajor(1M) utility to determine the major device numbers for nec, hp, and dtcs devices. The two logical devices are the conventional tty port and the dial out tty port. The logical devices are distinguished by distinct minor numbers. To determine the minor number for a dial out tty node (which uses the same physical port as a conventional tty node): add the number of physical tty ports (which the driver supports) to the minor number for the conventional tty node. The nec driver supports 2 physical tty ports. The hpsio driver supports 64 physical tty ports. The dtcs driver supports 96 physical tty ports. Therefore: nec dial out minor number = nec conventional minor number + 2 hpsio dial out minor number = hpsio conventional minor number + 64 dtcs dial out minor number = dtcs conventional minor number + 96 An open() of a dial out tty node does not wait for carrier detect to be asserted (whether or not the O_NDELAY flag is set). If a conventional tty node is open and an open() is attempted on a dial out tty node, then the open() will fail (return -1) and errno will be set to EBUSY. If an open() is attempted on a dial out tty node and an open() of the corresponding dial in tty node is waiting for carrier detect to be asserted, then the open() of the dial out tty node will complete successfully and the open() of the conventional node will normally stay suspended until the dial out tty node is no longer in use and carrier detect is present. If a process attempts to open() a conventional tty node with the O_NDELAY flag set and a corresponding dial out tty node is in use, then the open() will fail and errno will be set to EBUSY. If a process attempts to open() a conventional tty node without the O_NDELAY flag set and the corresponding dial out tty node is in use, then the open() will not complete until the dial out tty node is no longer in use and carrier detect is present. FILES /dev/tty* /dev/dio* SEE ALSO cmajor(1M), dual_hpsio(7), hpsio(7), nec(7), open(2), termio(7). SUPPORT STATUS Supported. Page 1 (printed 7/10/90)