earle@poseur.JPL.NASA.GOV (Greg Earle - Sun JPL on-site Software Support) (02/07/90)
I have a Telebit TrailBlazer Plus with BA4.00 PROMs (BTW, what is the latest
PROM revision available for these beasties?). I have permanently set the
S52 register (DTR Interpretation) to `2', which (according to the manual)
should mean that
If DTR is turned off, the modem is disconnected and Configuration
A or B parameters are reloaded depending on the current setting of
the A/B switch. If the modem does not have an A/B switch,
Configuration A is loaded. Modem will not auto-answer if DTR is off.
I want this feature because I have tip and UUCP use different S register
settings, and want a stable base to work from when each is invoked. (This is
on a Sun-3/260C running SunOS 4.0.3 with post-4.0.3 serial patch tape, BTW)
What I have discovered is this:
If I connect to the modem and dump the registers, I get
E1 F1 M1 Q0 T V1 X0 Version BA4.00
S00=001 S01=000 S02=255 S03=013 S04=010 S05=008 S06=002 S07=040 S08=002 S09=006
S10=007 S11=070 S12=255
S45=000 S47=004 S48=000 S49=000
S50=000 S51=254 S52=002 S53=003 S54=003 S55=000 S56=017 S57=019 S58=003 S59=000
S60=000 S61=045 S62=003 S63=001 S64=000 S65=000 S66=000 S67=000 S68=255
S90=000 S91=000 S92=000 S95=000
S100=000 S101=000 S102=000 S104=000
S110=000 S111=255 S112=001
S121=000
(N0 - N9 omitted)
OK
If I were to, say, change S50 to 255, and then use "~." to exit the tip to
the modem, I see the DTR light drop, and then return (the modem is used for
incoming/outgoing calls). If I then tip to the modem again, and do an ATN?,
I see that S50 has been properly re-set to 000, just like I want/expect from
the behavior of the S52 register.
However, let's say I tip to a remote host, and my /etc/remote entry
for that host tacks on a `;S50=255;D' to the phone number (because
this host is the only one with a Telebit which answers with PEP tones
second instead of right away). After I log out of the remote machine
and exit `tip', if I tip back to the modem right after that, the modem
parameters are NOT reset, as I expect. E is 0 and V is 0, and S50 is still
255. Even though, when exiting tip after the remote host is logged off,
I also see DTR drop, and then return (when init starts the getty) - which
would make me think that it should be resetting the parameters, just like
as if I'd tip'ed to the modem directly and changed them.
This manifests itself in 2 ways:
(1) After an outgoing UUCP session, if I dial in to my modem, it will answer
but I won't get a getty prompt. If I drop the connection and re-dial,
again it answers and now things work as expected. This is a pain.
(2) On another system configured identically (S register wise), it gets into
a state whereby it won't even answer the phone at all (even though it is
also set for S00=001)!! I have to get on to the machine via some other
means, and then I have to tip directly to the modem, *twice* - the first
time, nothing I type (AAAAATZ, AAATV1E1, etc.) gets echoed or acknowledged;
if I then disconnect and reconnect, I still don't get anything echoed, but
an AAAATZ will yield `OK'. The modem will then answer the phone, and
everything is wonderful - until the next UUCP session puts it back to this
zombie mode. This is a ROYAL pain.
Has anyone out there seen this behavior before? Any possible explanations for
why things work correctly (resetting of the parameters) if I direct-connect
to the modem and change things, then get out of tip and back in; whereas
things don't work (parameters not reset) if a connection to a remote machine
is made during the first tip session?
My only solution (which I haven't implemented) at the moment would be to
modify uucico and tip to explicitly do an `ATZ' at connection close, but I'd
rather not have to do that (and, I'd be up the creek if I didn't have source).
Thanks for any ideas (and sorry about the long-windedness),
--
Greg Earle
Sun Microsystems, Inc. - JPL on-site Software Support
earle@poseur.JPL.NASA.GOV (direct)
earle@Sun.COM (indirect)