Telecom-Request%mit-mc@brl-bmd.UUCP (Telecom-Request@mit-mc) (02/22/84)
TELECOM Digest Wednesday, 22 Feb 1984 Volume 4 : Issue 25
Today's Topics:
Issue #23
Cure for Vadic Triple Modem Problem
Statistical Multiplexors and inverse multiplexing
does anyone care what is happening in the SW ?
Yugoslav telephone security.
Re: TELECOM Digest V4 #24
----------------------------------------------------------------------
Date: 20 Feb 1984 2103-EST
From: Jon Solomon <M.JSOL at MIT-EECS>
Subject: Issue #23
Due to a error on my part, there was no Issue #23. Sorry for any
inconvenience.
--JSol
------------------------------
From: vortex!lauren at RAND-UNIX
Date: Mon, 20-Feb-84 00:39:48-PST
Sender: Lauren Weinstein <vortex!lauren@RAND-UNIX>
Subject: Cure for Vadic Triple Modem Problem
So bunky, you say you got yourself a Racal-Vadic triple modem
(3451-series) and you have some problems with it? You say that
sometimes in auto-answer mode it seems to hang offhook, making it
impossible for any new calls to arrive? You say that when this
happens it refuses to respond to DTR and only resets if you cycle the
power or fiddle with the mode toggle switch (if you have one, that
is)? Is that what's bothering you, bunky?
WELLLLL! Lift up your head and greet the sun, 'cause a solution does
exist -- and it doesn't even involve hydrochloric acid or jackhammers!
Seriously, though, many persons have reported problems with triple
modems getting into a strange wedged condition from which it is
difficult to escape. Both manual dial and autodial triples have shown
this behavior, which is characterized by the modem being offhook,
sending a 212 carrier, and having both the HS and DSR lights lit.
Only cycling the power or performing a software reset (by flipping the
toggle switch between auto and manual on the autodial modems) will
clear this condition; the modem is oblivious to DTR. After having
this occur repeatedly on the main Vortex dialup line, I started
harassing the engineers up at Racal. Actually, they were quite
helpful, once they realized that I knew what I was talking about and
hadn't plugged the RJ-11C phone plug into an AC wall outlet!
After talking with three different engineers and having them duplicate
***Sender closed connection***
=== brl netread error from MIT-MC at Tue Feb 21 18:26:57 ===Telecom-Request%mit-mc@brl-bmd.UUCP (Telecom-Request@mit-mc) (02/22/84)
TELECOM Digest Wednesday, 22 Feb 1984 Volume 4 : Issue 25
Today's Topics:
Issue #23
Cure for Vadic Triple Modem Problem
Statistical Multiplexors and inverse multiplexing
does anyone care what is happening in the SW ?
Yugoslav telephone security.
Re: TELECOM Digest V4 #24
----------------------------------------------------------------------
Date: 20 Feb 1984 2103-EST
From: Jon Solomon <M.JSOL at MIT-EECS>
Subject: Issue #23
Due to a error on my part, there was no Issue #23. Sorry for any
inconvenience.
--JSol
------------------------------
From: vortex!lauren at RAND-UNIX
Date: Mon, 20-Feb-84 00:39:48-PST
Sender: Lauren Weinstein <vortex!lauren@RAND-UNIX>
Subject: Cure for Vadic Triple Modem Problem
So bunky, you say you got yourself a Racal-Vadic triple modem
(3451-series) and you have some problems with it? You say that
sometimes in auto-answer mode it seems to hang offhook, making it
impossible for any new calls to arrive? You say that when this
happens it refuses to respond to DTR and only resets if you cycle the
power or fiddle with the mode toggle switch (if you have one, that
is)? Is that what's bothering you, bunky?
WELLLLL! Lift up your head and greet the sun, 'cause a solution does
exist -- and it doesn't even involve hydrochloric acid or jackhammers!
Seriously, though, many persons have reported problems with triple
modems getting into a strange wedged condition from which it is
difficult to escape. Both manual dial and autodial triples have shown
this behavior, which is characterized by the modem being offhook,
sending a 212 carrier, and having both the HS and DSR lights lit.
Only cycling the power or performing a software reset (by flipping the
toggle switch between auto and manual on the autodial modems) will
clear this condition; the modem is oblivious to DTR. After having
this occur repeatedly on the main Vortex dialup line, I started
harassing the engineers up at Racal. Actually, they were quite
helpful, once they realized that I knew what I was talking about and
hadn't plugged the RJ-11C phone plug into an AC wall outlet!
After talking with three different engineers and having them duplicate
the problem on their test benches, we arrived at the cause of the
problem and a (simple) solution. The problem is caused by a "hole" in
the triple modem protocol select algorithm. Under certain random
timing conditions, the modem may be "fooled" into entering a
pseudo-originate mode during its answer-mode operations. The exact
reasons are too complex to go into here, but the cure is
straightforward:
Inside the modem, option dip switch A1 is described by the manual as:
"Attended/Unattended Disconnect -- Set to Attended [ON] for Auto Dial
modems. (Unattended setting relates to manual originate operation
only.)"
DON'T YOU BELIEVE IT! This switch also affects the handling of DTR
during answer mode processing. The "normal" setting of this option
(as set by the "standard-options" switch A6) is ON (Attended). This
is WRONG for almost all operations. For both auto-dial and
non-autodial triple modems, this option should normally be set to OFF
(Unattended). The only side effect of this is that if you attempt to
use the modem in a MANUAL originate mode, you will probably have to
supply DTR at the RS232 interface (big deal!) If you leave A1 OFF,
the answer mode wedging problem should vanish! Auto-dial operations
on auto-dial modems should work as always.
NOTE: If your triple has switch A6 OFF, then "standard-options" mode
is ENABLED and the remaining A and B switches are ignored. In order
to change the state of A1 to OFF, you must also turn switch A6 ON to
disable "standard-options" and make sure that all other switches are
set appropriately.
I recommend the following settings (some of these are NOT the default
settings):
A1 -- OFF (Unattended -- fixes the answer wedge problem) A2 -- OFF (Do
NOT respond to remote test) [do you want everyone in
the universe "testing" your modem for you?] A3 -- ON (10
bit chars -- this is normal) A4 -- ON 103 operation enabled A5 -- OFF
(10 bit chars -- this is normal) A6 -- ON Disable standard-options
(enables all other switches) A7 -- ON Auto-disconnect on loss of
carrier enabled
B1 -- OFF Local digital loopback select (ignored when not testing) B2
-- OFF DTR controlled from RS232 interface B3 -- OFF Originate and
Answer modes allowed B4 -- OFF 1204 bps speed (this is normal) B5 --
ON Auto-disconnect/Abort timer enabled B6 -- OFF Asynchronous
operation B7 -- ON DSR off in test (ignored when not testing)
In addition, I recommend the following two jumper changes on the
BOTTOM pc board:
Insert jumper "r" -- enable data rate indicator on RS232 pin 12 Remove
jumper "ag" -- do not tie carrier detect high (RS232 pin 8)
------
The "wedged" condition mentioned above, being related to a rather
random timing window, is more likely to have been seen on modems that
have a high volume of calls than on low volume incoming lines.
However, it occurs frequently enough that I recommend the option
change for all triple modems being used for incoming calls.
Be sure to let me know if you have any questions about or problems
with this info. I hope it's of some use, bunky...
--Lauren--
------------------------------
Date: Monday, 20 Feb 1984 13:27:49-PST
From: (Rich Rosenbaum, Network Services)
From: <decwrl!rhea!bergil!rosenbaum@Shasta>
Subject: Statistical Multiplexors and inverse multiplexing
To: Richard M. King <KING@KESTREL> Subject: statistical multiplexors
MICOM makes a box called the Micro100. This is called either an
inverse line multiplexor, reverse multiplexor, or something similar.
I believe it can use multiple links between Micro100's to "convert"
several low bandwidth lines into one medium bandwidth line. The
number of "output" (inter-Micro100) lines is switch selectable.
The specific capacity I was looking for was to "spread" a 56 Kbit/sec
link across 6 9600 bit/sec leased lines. According to MICOM, the box
can do this, as well as handle asynchronous lines (as in your
question). I never did get one, so I don't know anything for sure.
I do not know if it can perform statmux (concentration) functions. It
is very hard to find a description of the device. The people at MICOM
had problems in describing it's exact spec's, or finding reference
accounts, so I gather it is a low volume product. Good luck.
__Rich
------------------------------
Date: Tue 21 Feb 84 07:14:55-CST
From: Werner Uhrig <CMP.WERNER@UTEXAS-20.ARPA>
Subject: does anyone care what is happening in the SW ?
Quizzing the black void ......
I have been most intrigued by the back-and-forth in local
politics, which determine our future phone-costs; but,
unfortunately, only news concerning regional developments here
in Texas make the news here, and little becomes known about
what is going on elsewhere (outside the Texas end of
Southwestern Bell).
I assume that the same is true elsewhere, which is why I have
been posting some of the newspaper articles describing the
local developments, both for your information and amusement
(tragic comedy ?? comic tragedy??)
Three questions:
1) does anyone care ? if not, I'll discontinue posting.
2) can anyone report what is happening in other regions?
3) my timid attempts at becoming "active", by calling the
local PUC office for information about future meetings
as well as to get someone on the phone whom I could
"lobby" in the consumer-interest have failed dismally,
as all I get is the "run-around" and mis-information.
Does anyone have some guidelines he/she might care to
share for "dealing with a PUC" and becoming effective
in getting information and making them feel the
pressure of "public opinion"?
------------------------------
Date: Tue, 21 Feb 84 15:04:11 EST
From: Ron Natalie <ron@brl-vgr>
Subject: Yugoslav telephone security.
All telephones have this problem to some extent. When I worked on a
classified project, telephones had to be unplugged from the wall when
not in use. In addition, there were two buttons on the handset.
Push-to-talk was obvious. Push to listen was less obvious. However,
I do remember when I was in high school, they removed the mouthpieces
from the data telephones to keep the students from using them for
personal conversations. When we got incoming calls, we found if you
yelled loud enough into the earpiece you could be heard. Usually, it
was "Hold on" while we went and dug up the microphone cartridge.
-Ron
------------------------------
Date: Tue 21 Feb 84 13:14:59-MST
From: Walt <Haas@UTAH-20.ARPA>
Subject: Re: TELECOM Digest V4 #24
The following is a copy of a message which I sent on 8 Feb:
-----------------------------
Subject: Re: Interfacing mail systems To: Telecom@MIT-MC.ARPA
Sigh. How slowly we learn. About a hundred years ago the railroads
and the electric companies both pursued non-interchange policies.
Cars that ran on one raiload couldn't be used on another because the
track guages of competing roads were different. The result was that
freight had to be unloaded from one car and loaded onto another to
make a connection. Needless to say customers quickly got sick of the
unnecessary breakage and expense. Finally the railroads standardized
the interchange of their rolling stock, with the result that people
became more willing to use railroads to ship things, and all the
railroads prospered together. Shortly afterwards, the electric
illumination industry got started with different sizes of light bulb
bases. Each company designed light bulbs that couldn't be used in the
lamps of competing companies. This was bad for everybody, and finally
standards were adopted. Eventually it has to sink in to the
management of Autonet, CompuServe, ITT, MCI, Telenet, Tymnet and
Uninet that the industry will work best with maximum standardization
and interchange. I only hope I live long enough to see history repeat
itself.
Cheers -- Walt
------------------------------
End of TELECOM Digest
*********************