teg@peabody.iusb.indiana.edu (Tim Gurbick) (04/20/91)
We've attached 2 98638A and 1 98642A MUX boards to one of our 900/400s and have connected some of the ports to a menu-driven modem regulator (called DCA) which also talks to several other machines. Our goal is to cause the user to be logged-out and the connection dropped if the terminal is switched off or if the modem carrier is dropped (in other words, if DTR goes low). As an attempt to rig this, we've changed the character-special device files to "dial-in modem" mode (minor device number ending in 00), and have wired DCD to DTR, as recommended by the owner's manual. HUPCL was added to gettydefs, and -clocal was set. Our current problem is that for a totally unknown reason and after am ambiguous amount of time, the DTR on the mux board refuses to recognise any external stimuli, which in turn prevents any login on that tty. As far as the modems are concerned, however, the port is fine, and it just makes login impossible on the entire set of modems because it will grab the first one it can find. Running in this mode causes the getty processes for these ttys to run without being attached to any specific tty ("?" in the TTY column of a ps), with "/etc/getty -h 2400 tty10" being shown as the command running. Our second problem is that the hard-wired terminals we are running in the next room at 9600 baud are experiencing occasional communications problems as well. Because one of our faculty wants everybody to use emacs, we are forced to run these at 7E1 (which is also the case for the modem lines at 2400 baud), but simple things like kermit, umodem, or X/Y/Zmodem transfers abort for unknown reasons, and this is going through only 20 feet of cable. The modem thingy (DCA) can communicate successfully with another campus machine (Prime running Primos) in the manner we'd LIKE it to talk with our HP; 7E1 all the way and it exits when DTR is dropped. I am therefore assuming it's not a DCA problem. The relevant entries from gettydefs follow, with 2400s for the modem lines and 9600 for the others: 2400 # B2400 HUPCL IGNPAR PARENB ICRNL IXON OPOST ONLCR CS7 CREAD ISIG ICANON ECHO ECHOK PARENB IXANY TAB3 IENQAK # B2400 SANE CS7 PARENB IXANY IXANY TAB3 HUPCL IENQAK #login: #2400 9600 # B9600 HUPCL IGNPAR CRTS PARENB ICRNL IXON OPOST ONLCR CS7 CREAD ISIG ICANON ECHO ECHOK PARENB ISTRIP IXANY TAB3 # B9600 SANE CS7 PARENB ISTRIP IXANY TAB3 #login: #9600 The response center is totally confused on this issue. They have yet to advise if the patch for the internal serial port will apply to a mux board as well. We're just scratching our heads. Opinions would be GREATLY appreciated. We hope to move to a TCP/IP-based system (e.g. Annex box) REAL soon, as this is just short of academic disaster for our students. =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Tim Gurbick a.k.a. teg@peabody.iusb.indiana.edu Dept of Math & CS: 237-GEEK Help: 911 d.b.a. teg@natasha.iusb.indiana.edu `whois \!TEG12` Traci:0x45 SYSV: just say NO! teg@nova.cc.purdue.edu !hoser The Amiga: Born a Champion Me: International Unix Standards Bored, educational division: (219)237-IHEX address: CS Dept IUSB POB 7111 1700 Mishawaka Avenue, South Bend, IN 46634 "Work FOR? I don't work FOR anybody... I'm just having fun." - The Doctor
zap@indic.se (Jonas Petersson) (04/24/91)
In article <1991Apr19.234717.25668@bronze.ucs.indiana.edu> teg@peabody.iusb.indiana.edu (Tim Gurbick) writes: > [a lot about MUX problems] I have also had a weird problem with the 98642A MUX on 375 and 340 (that is - all that I've tried with): The systems we sell need to have 2 modems, one for data collection at 1200/2400 baud and one for support etc at 19200 baud (a USR HST modem). First I try the HST on the internal serial port as I imagined that it would be the safest. Seemed to work fine but when I try to run something heavy, like zmodem, it seems to get handshaking problems and starts over all the time. Now I move the HST to the MUX instead - and strange things start to happen: For some reason the RTS wont work unless I try to run kermit on that line - kermit fails, but when I quit kermit everything works fine. If I then run 'cu' on that line it goes back to the initial state again. But the good thing is that handshaking works fine on the MUX after running kermit! So after some hours of trial&error I came up with the solution to add something like: mux1::boot:/bin/sh /etc/HSTinit to /etc/inittab (where HSTinit is a script that runs kermit safely) and removing the possibility to run 'cu' on that line. As we need the slow modem anyway there really isn't anything to make a fuzz about, but I just wanted to point out that there probably are some minor problems with both serial ports. HP labs people might want to enlighten us? A glance on the kermit and cu code would help. Regards / Jonas "Just what the world needs - more bugs!" -- Photographer in Arachnophobia. -- /// "Are you THE Zaphod Beeblebrox ????" # zap@indic.se __ /// # Air Quality Surveillance \\\/// "No, just A Zaphod Beeblebrox. # "I can feel it coming \/// Didn't you hear - I come in sixpacks !" # in the air..."
norman@hpgnd.grenoble.hp.com (Norman MAC DONALD) (04/25/91)
/ hpgnd:comp.sys.hp / teg@peabody.iusb.indiana.edu (Tim Gurbick) / 1:47 am Apr 20, 1991 / We've attached 2 98638A and 1 98642A MUX boards to one of our 900/400s and have connected some of the ports to a menu-driven modem regulator (called DCA) which also talks to several other machines. Our goal is to cause the user to be logged-out and the connection dropped if the terminal is switched off or if the modem carrier is dropped (in other words, if DTR goes low). As an attempt to rig this, we've changed the character-special device files to "dial-in modem" mode (minor device number ending in 00), and have wired DCD to DTR, as recommended by the owner's manual. HUPCL was added to gettydefs, and -clocal was set. Our current problem is that for a totally unknown reason and after am ambiguous amount of time, the DTR on the mux board refuses to recognise any external stimuli, which in turn prevents any login on that tty. As far as the modems are concerned, however, the port is fine, and it just makes login impossible on the entire set of modems because it will grab the first one it can find. Running in this mode causes the getty processes for these ttys to run without being attached to any specific tty ("?" in the TTY column of a ps), with "/etc/getty -h 2400 tty10" being shown as the command running. Our second problem is that the hard-wired terminals we are running in the next room at 9600 baud are experiencing occasional communications problems as well. Because one of our faculty wants everybody to use emacs, we are forced to run these at 7E1 (which is also the case for the modem lines at 2400 baud), but simple things like kermit, umodem, or X/Y/Zmodem transfers abort for unknown reasons, and this is going through only 20 feet of cable. The modem thingy (DCA) can communicate successfully with another campus machine (Prime running Primos) in the manner we'd LIKE it to talk with our HP; 7E1 all the way and it exits when DTR is dropped. I am therefore assuming it's not a DCA problem. The relevant entries from gettydefs follow, with 2400s for the modem lines and 9600 for the others: 2400 # B2400 HUPCL IGNPAR PARENB ICRNL IXON OPOST ONLCR CS7 CREAD ISIG ICANON ECHO ECHOK PARENB IXANY TAB3 IENQAK # B2400 SANE CS7 PARENB IXANY IXANY TAB3 HUPCL IENQAK #login: #2400 9600 # B9600 HUPCL IGNPAR CRTS PARENB ICRNL IXON OPOST ONLCR CS7 CREAD ISIG ICANON ECHO ECHOK PARENB ISTRIP IXANY TAB3 # B9600 SANE CS7 PARENB ISTRIP IXANY TAB3 #login: #9600 The response center is totally confused on this issue. They have yet to advise if the patch for the internal serial port will apply to a mux board as well. We're just scratching our heads. Opinions would be GREATLY appreciated. We hope to move to a TCP/IP-based system (e.g. Annex box) REAL soon, as this is just short of academic disaster for our students. =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Tim Gurbick a.k.a. teg@peabody.iusb.indiana.edu Dept of Math & CS: 237-GEEK Help: 911 d.b.a. teg@natasha.iusb.indiana.edu `whois \!TEG12` Traci:0x45 SYSV: just say NO! teg@nova.cc.purdue.edu !hoser The Amiga: Born a Champion Me: International Unix Standards Bored, educational division: (219)237-IHEX address: CS Dept IUSB POB 7111 1700 Mishawaka Avenue, South Bend, IN 46634 "Work FOR? I don't work FOR anybody... I'm just having fun." - The Doctor ----------