>: >I operate a pool of some 170 rack mounted Motorla Codex 3267 V.34 modems
>: >(rom versions 7.1 & 7.5) for the University of Alberta. Users dialing in
>: >with USR Sportster V.34 modems (both old & new rom versions) are
>: >encountering line drop problems some 5 or so minutes into almost every
>: >connection they make to the pool.
>: >I get various ati6 disconnect reasons from the Sportsters (loss of
>: >carrier, loop loss disconnect, GSTN cleardown).
>: >The Codex end always reports "Training timer expired (V.32/V.32bis)"
>: >- admittedly weird.
>: These sound like V.42 negotiation failures during retraining.
>Nonsense; V.42 isn't renegotiated after retrains. V.42 has nothing to
>do with retrains, and in fact is independent of the particular modulation
>it is implemented over: V.34, V.32bis, V.22bis, or whatever.
>A retrain timeout means that the modems didn't complete a retrain within
>the time allotted. Each phase of the retrain process (there are three,
>exactly the same as phases 2 through 4 of the original connection
>process) has a recovery procedure should one of the signals involved not
>be detected correctly or in time. Essentially what happens is that
>the failing phase is repeated. If the connection is bad enough, or
>failures are generated by some other cause, it is possible for retrain
>to continue indefinitely. Most modems will call a halt to this process
>if it goes on long enough (either based on time or number of attempts
>or both) and disconnect.
this group, but independently I have explored this problem and wonder if
this problem is something else, and only a Scope could tell if this is the
Rockwell states that " V.FC (TM) probes at 68 frequencies and uses 50 Hz
spacing, while V.34 uses 21 frequencies with 150 Hz spacing. However, V.FC
(TM) analyzes the probe data results in the same way as V.34. So, V.FC (TM)
uses three times more line probing frequencies than V.34. The channel probe
only occurs in the initial train for both technologies."
Note that they say that the "channel probe only occurs in the initial
train." Since most V.34 modems have V.fc code within, then what if, for
whatever the reason, one of the modems goes into the "initial train" for
the wrong standard (V.34 or V.fc). In other words, the two modems are
handshaking on different frequencies, and this causes the "Downward Death
Yes, Rockwell states that " While V.FC (TM) has the same retrain and
speed switching procedures as V.34, it also has a semi-seamless rate change.
The semi-seamless rate change has the advantage of not interrupting the
data modulation. Retrains by the V.FC (TM) data pump require the same time
as a V.34 retrain. In the past, there have been differences in host
controller implementations that have increased the retrain time under
certain conditions, but they have been corrected.
Note they say, "In the past, there have been differences in host
But, what if, somehow, one of these modems which have conflicts switches to
the "intial" train at the opposite configuration (V.34 vs V.fc).
Further, at the ISP that I am using with my Zoom V.fc, I have found that for
some reason I can not use the LAP-M protocol unless I want disconnects with
the USR modems. So, I have to use the MNP protocol to avoid this problem.
Out of 16 modems, there is only one modem which I get disconnected on now,
and this line always connects at a much lower modem speed; hence, maybe bad
telephone line or modem.
In my situation with the Zoom V.fc, I use
(1) No Retrains %E Default
(2) Run MNP \N5
(3) No compression S46=136
(4) MNP connect only S36=4
Verbose result code S95=127
Thus, I use:
and get this:
Footnote: On Zoom, the default for retrains is "turned-off," but before IQuote:>CARRIER 24000
>COMPRESSION: CLASS 5
started changing the AT strings around, I noticed that from time to time my
modem was "whinning" during a session and then "Ka-boom," a disconnect. In
other words, even though the retrain was turned off by default, it APPEARED
that the modem was handshaking during the session. Since I do not have a
Scope, I have concluded that retraining was going on even though it should
not have occured. Further, the LAP-M protocol APPEARS to be related to this
I have not explored this testing phase, but if I would put the %E2 string in
on the MNP protocol, I have a feeling that nothing would happen; in other
words, no disconnects. But I have not tried this yet.
In essence, I found that by using the MNP protocol, the disconnects went
away. Of course, check your modem book for the correct AT string, ihmo.