bartm@cv.ruu.nl (Bart Muyzer) (04/25/91)
Hi,
I'm experiencing a problem with a HP37212B "Error Correcting Modem". I know
what causes it but I don't know what to do about it (except rebooting :-( ).
The modem is connected to a HP 9000/835 using a mux which (among others) also
attaches the system console to the system. This one works fine so I know it's
not the mux.
The problem is that the modem refuses to pick up the phone because the MDTR
is low. So it thinks the connected computer isn't ready and refuses to
answer. This situation occurs after the following sequence:
* user calls and logs in
* user initiates to be called back
* user hangs up and gets called back
* user works and hangs up
Now the modem never answers any further incoming calls. The RI(ng) light is on
during a ring but no answer...
The callback service uses the 'ct' program supplied by HP. As long as this
service isn't used, things seem to keep working fine. Even if I call the
modem, wait for it to start whistling and then throw down the hook things keep
working.
I used the following tricks to make the modem listen again:
* for a while, it worked to have the modem initiate a call using 'cu'. This
somehow reset the modem and it all worked again;
* it sometimes helped to kill a process called 'uugetty'. Init restarts it and
all is fine again;
* If this fails, the only thing left is to reset the 835.
A HP technician looked at the modem and even replaced the entire printboard,
but this didn't help. And I think (from the above) the modem is not to blame
but the 835 because it messes around with the MDTR signal.
Questions:
1. Can anybody provide an "off shelve" solution?
2. Is it possible that 'ct' doesn't properly reset things on exit?
3. Is there some way to flip the MDTR signal to "active" without rebooting?
4. Did I miss some modem configuration stuff (yes, I tried setting MDTR
always high using dipswithes on the modem, but this doesn't work either
since the modem picks up the phone but I never get a login prompt)
5. Are there any PD 'callback programs" available. If yes, where can they be
ftp'd from?
Any help will be appreciated.
>] Bart [<
--
Bart Muyzer(SysAdm), 3D Computer Vision, University Hospital Utrecht
Heidelberglaan 100, Room E 02.222, 3584 CX Utrecht, The Netherlands.
tel: +31-30-506711 (w), +31-3402-52157 (h) | "You never get a second chance
fax: +31-30-513399, e-mail: bartm@cv.ruu.nl | to make a first impression"lstowell@pyrnova.pyramid.com (Lon Stowell) (04/26/91)
In article <1991Apr25.154031.2013@cv.ruu.nl> bartm@cv.ruu.nl (Bart Muyzer) writes: >Hi, > >I'm experiencing a problem with a HP37212B "Error Correcting Modem". I know >what causes it but I don't know what to do about it (except rebooting :-( ). >The modem is connected to a HP 9000/835 using a mux which (among others) also >attaches the system console to the system. This one works fine so I know it's >not the mux. > >The problem is that the modem refuses to pick up the phone because the MDTR >is low. So it thinks the connected computer isn't ready and refuses to >answer. This situation occurs after the following sequence: The problem is NOT the modem, it is the [ software in ] the computer. As you note if DTR is low, the modem passes RI to the computer....(which is obviously ignoring it...). When you change the modem to set DTR high, the modem answers... [so the modem is performing perfectly normal] but you get no login....[which means the computer is dead] >* user calls and logs in >* user initiates to be called back >* user hangs up and gets called back >* user works and hangs up At some point after this, the computer [ software ] should be raising DTR to take another inbound call. This actually looks like a system problem...in that magically one user gets in, gets called back, and can access the computer. Something is drastically wrong with the exit routine which is leaving the port inoperative. Either the port should again raise DTR (so the modem can answer automatically) or it should detect RI, then raise DTR so the modem will answer. You don't have a modem problem, you have a software problem. Either that or your MUX is messing with the DTR signal from your computer. If you have a breakout, see if the computer has DTR on ( or will raise DTR if RI is high ).