Re: Lucent K56Flex Upgrades broke a few modems
Karl Denninger (karl@Mcs.Net)
Tue, 19 Aug 1997 08:21:58 -0500
On Mon, Aug 18, 1997 at 09:19:33PM -0400, Robert Boyle wrote:
> At 06:43 PM 08/18/97 -0600, Stephen Fisher wrote:
> >Everyone will have to excuse my last posting which is jumping to things
> >when I don't even have experience with the new cards.. it's the feeling
> >I'm getting though.
> >
> >Karl, are most/all of the problems going on fixable by going back to MNP?
> >At least the disconnect problems (don't know if there are really any
> >others-anyone?).
>
> I'm not sure that I understand what Karl meant about MNP? Are you referring
> to error correction or compression? None of the users having problems are
> using STAC if that is what you meant. Please elaborate. However, overall,
> I'm INCREDIBLY pleased with our PM3s. I wouldn't trade them for anything
> else out there! My original message was not intended to start a thread
> about Livingston's products stability or merits vs. the competition's. I
> just posted this message because I am wondering if anyone else is having
> these same problems we are. Only a handful of users have complained, but
> that is unusual since usually nobody complains. However, this is
> essentially release 1.0 code that we are running here (ComOS 3.7) and
> considering the fact that most of our users get 33.6k connections every
> time and the inclusion of 56k support, I REALLY can't (and won't) complain. :)
>
> -Robert
>
> btw- I installed the STAC card in our PM3 today and I'm waiting for
> feedback from customers to see how they like it. So far so good. One person
> commented that he thought something was wrong because his revision control
> program just flashed for a second while checking in new code. I think
> that's a good sign. I'll try to do some benchmarks and then I'll post them
> here.
Most of the problems right now in the 3.7 ComOS related to modems are V.42
related. If you look at the disconnect reasons, you'll see a lot of "LAPM
RETRY LIMIT" causes.
This is a V.42 protocol botch. There's some fairly serious stupidity among
different modem vendors on this matter, including US Robotics. Some modems
will not request a renegotiation after 6 failed block transmissions -- but
they are supposed to. If you get to *12* failed transmissions, the call is
dropped.
One way around this is to shut off V.42. Having the customer reset their
modem to use MNP5 instead does this. That, however, is somewhat slower in
throughput than a good V.42bis implementation (which runs on top of V.42),
therefore my other suggestion -- turn off *all* error control, run STAC for
compression, and let the PPP layer handle frame retransmission in the event
of errors.
Lucent and Livingston are aware of the V.42 problems and their severity.
I consider it the most serious open problem in the 3.7 release; there IS
another extremely serious problem as well having to do with MCPPP spanned
calls, but I have a tentative fix for this and it appears to be working
(as such I expect that the world will have a fix for that problem in a
few days). If you run only 1B ISDN or only analog, or if you're on
channelized lines you won't see this -- it only shows up on PRIs with
spanned sessions.
--
--
Karl Denninger (karl@MCS.Net)| MCSNet - Serving Chicagoland and Wisconsin
http://www.mcs.net/~karl | T1's from $600 monthly to FULL DS-3 Service
| NEW! K56Flex modem support is now available
Voice: [+1 312 803-MCS1 x219]| 56kbps DIGITAL ISDN DOV on analog lines!
Fax: [+1 312 803-4929] | 2 FULL DS-3 Internet links; 400Mbps B/W Internal