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 Doctorzap@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
----------