cadwell@sumax.UUCP (James A. Cadwell) (08/02/90)
hello: I have a Telebit T2500 which I would like to connect to my PI running IRIX 3.2.1. The "guides" explain the setup for either dial-out OR dial-in use. I desire to do both at 19200 or 96000 baud. Folks, is there a solution? thank you, Jim Cadwell
jweldon@renegade.sgi.com (Jack P. Weldon) (08/03/90)
In article <1565@sumax.UUCP> cadwell@sumax.UUCP (James A. Cadwell) writes: >hello: > I have a Telebit T2500 which I would like to connect to >my PI running IRIX 3.2.1. The "guides" explain the setup for either >dial-out OR dial-in use. I desire to do both at 19200 or 96000 baud. > >Folks, is there a solution? Sure is. Setup a dx_19200 getty in /etc/gettydefs. Look at the fix-telebit script in /usr/lib/uucp and run it on your serial port with the modem connected and turned on. *Then* start your getty. If you want to get fancy, you can setup uugetty running on ttyf (hdwr-flow ctl) so that you can either dial-in or dial-out on the same port, but I'd get one or the other going first before tackling uugetty. Your cable will be pinned as: 2-8 straight through, and 9->20. The fix-telebit script gives some good suggestions for initial uugetty lines in /etc/inittab. Good luck. Cheers, Jack P. Weldon (jweldon@sgi.com)
dwatts@ki.UUCP (Dan Watts) (08/03/90)
In article <1565@sumax.UUCP> cadwell@sumax.UUCP (James A. Cadwell) writes: >hello: > I have a Telebit T2500 which I would like to connect to >my PI running IRIX 3.2.1. The "guides" explain the setup for either >dial-out OR dial-in use. I desire to do both at 19200 or 96000 baud. > >Folks, is there a solution? >thank you, Jim Cadwell I've got our PI running with a T2500 at 19200 for dial-in & dial-out usage. I'm running uugetty on the port and have the modem set for constant 19200 baud rate with full modem control. I also have the dial-in set for dial-up password request on the SGI (/etc/dialups and /etc/d_passwd). I also made a change to /etc/profile and /etc/cshrc to send email to root whenever there is a login on that line. I found some of the info from the uugetty and login man pages. d_passwd contains lines of the form: shell:password: The hardest part was creating the password. Seems that there isn't a password generating utility. I ended up writing one to make my life easier. The way that SGI told me to get passwords was to set a password for a login account and then copy the password out of /etc/passwd and put it into the d_passwd file. The d_passwd file is nice so that you only request passwords for those accounts that run specific shells like /bin/csh or /bin/sh. For uucp users, you can skip the dial-up password if you like. It also allows you to have different passwords for your uucp dial-ins vs your personal dial-ins. -- ##################################################################### # CompuServe: >INTERNET:uunet.UU.NET!ki!dwatts Dan Watts # # UUCP : ...!uunet!ki!dwatts Ki Research, Inc. # ############### New Dimensions In Network Connectivity ##############
vjs@rhyolite.wpd.sgi.com (Vernon Schryver) (08/04/90)
In article <1565@sumax.UUCP>, cadwell@sumax.UUCP (James A. Cadwell) writes: > hello: > I have a Telebit T2500 which I would like to connect to > my PI running IRIX 3.2.1. The "guides" explain the setup for either > dial-out OR dial-in use. I desire to do both at 19200 or 96000 baud. uugetty has been in use on sgi.sgi.com for years and sounds like what is needed. It is used within Silicon Graphics on various machines for SLIP and dial-up lines. The script "/usr/lib/uucp/fix-telebit" might be useful, given args like `fix-telebit -io d2` to poke at a T2500 on /dev/ttyd2. You can adjust the script to set the T2500 (or TB+ or T1[05]00) to your notion of correctness. You will need a cable with pins 2,3,4,5,7,8, and 9/20 connected, as described in one of the manuals. (Sorry, I can never find it, although I've seen and helped edit the text and tables many times.) Uugetty should be told to use /dev/ttyf* in /etc/inittab, which means you will need to turn off the *getty in /etc/inittab when running fix-telebit. Lines in /usr/lib/uucp/Systems should use entries that ultimately connect to /dev/ttyf*. You will need to adjust /usr/lib/uucp/Devices appropriatedly. There are some examples in the 3.3 version. Vernon Schryver Silicon Graphics vjs@sgi.com
wheelan@quiche.cs.mcgill.ca (Bill HEELAN) (08/05/90)
From article <66085@sgi.sgi.com>, by vjs@rhyolite.wpd.sgi.com (Vernon Schryver): > In article <1565@sumax.UUCP>, cadwell@sumax.UUCP (James A. Cadwell) writes: >> hello: [Discussion about hooking up modems] I'm currently doing the same thing -- I have to hook up several modems to a 4D-240S running 3.2. At the moment I've hooked up a Hayes 2400 Smartmodem to ttym3 and a Trailblazer Plus to ttyf2. Both are to be used for dialing in and out. To test them I use 'cu' to dial out through one and into the other. I am able to log in all right, but when I log out and the modems disconnect the machine hangs: the console is dead and rlogins are impossible, although 'ping' gets replies. Has anyone seen this behaviour before? I've noticed that when it is hung, DTR is raised on only one of the ports, seeming to indicate that it hung before or during the second 'uugetty's relaunching ( don't have my notes with me -- not positive which port ). I noticed that a couple of people have mentioned the version of the OS they are running, and in both cases it's higher than 3.2 ( 3.2.1 and 3.3? ). Is there a bug fixed in these, or should 'uugetty' just not be run on a ttym port? ( It is fine the first time, when started by init. ) Just what is the reason for the ttym ports? Are they for slow modems that don't use hardware flow control? Sorry for all the questions, but it's frustrating having all one's attempts in getting modems to work require rebooting the machine! - Bill
vjs@rhyolite.wpd.sgi.com (Vernon Schryver) (08/06/90)
In article <3813@quiche.cs.mcgill.ca>, wheelan@quiche.cs.mcgill.ca (Bill HEELAN) writes: > ... > To test them I use 'cu' to dial out through one and into the other. I am > able to log in all right, but when I log out and the modems disconnect > the machine hangs: the console is dead and rlogins are impossible, > although 'ping' gets replies.... 3.2 IRIX on MP machines through at least the penultimate version of 3.2 (perhaps it was called 3.2.2) had bugs that could cause a CPU to lock-up. Most of the complaints went away with fixes put in to the last version of 3.2 (perhaps 3.2.3--many of us are confused by the numbers). As Murphy would have predicted, additional problems on MP machines have been discovered and will be fixed in 3.3.1. There is also a collection of low frequency (<1 occurrance/machine-millenium) problems that we have not yet been able to reproduce, and so have not been able to fix. If you have a way to reproduce such problems, please let the Hotline know. Vernon Schryver vjs@sgi.com
jweldon@renegade.sgi.com (Jack P. Weldon) (08/07/90)
In article <66136@sgi.sgi.com> vjs@rhyolite.wpd.sgi.com (Vernon Schryver) writes: >In article <3813@quiche.cs.mcgill.ca>, wheelan@quiche.cs.mcgill.ca (Bill HEELAN) writes: >> ... >> To test them I use 'cu' to dial out through one and into the other. I am >> able to log in all right, but when I log out and the modems disconnect >> the machine hangs: the console is dead and rlogins are impossible, >> although 'ping' gets replies.... > > >3.2 IRIX on MP machines through at least the penultimate version of 3.2 >(perhaps it was called 3.2.2) had bugs that could cause a CPU to lock-up. >Most of the complaints went away with fixes put in to the last version of >3.2 (perhaps 3.2.3--many of us are confused by the numbers). > >Vernon Schryver Vernon is correct. The 3.2 bug that would hang a MP machine (when accessing ttyf* or ttym*) was fixed in 3.2.1. Any release greater than that will also have the fix (3.2.2, 3.2.3). If you have a support contract and do not have on of these loaded on your machine, or available to you, contact the SGI Geometry Hotline. Cheers, Jack P. Weldon (jweldon@sgi.com)