Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!wuarchive!zaphod.mps.ohio-state.edu!mips!spool.mu.edu!uunet!shaman!jiro
From: jiro@shaman.com (Jiro Nakamura)
Newsgroups: comp.dcom.modems
Subject: Re: MultiTech MultiModem V32 & T2500
Keywords: MultiModem V32, T2500
Message-ID: <1991Mar7.002423.4267@shaman.com>
Date: 7 Mar 91 00:24:23 GMT
References: <148@ipars.UUCP> <408@frcs.UUCP>
Organization: Shaman Consulting
Lines: 20

In article <408@frcs.UUCP> paul@frcs.UUCP (Paul Nash) writes:
>I have had a similar problem, and found that the only way to make the
>MultiTech talk to the TB reliably was by disabling MNP (error correction
>_and_ compression) on the TB.  Like this, it works fine.
>The TB has always called the MultiTechs reliably, but they just won't 
>connect properly if the TB tries to negotiate error correction.

	I think this has been mentioned before. The reason is because
the TB sends a extra MNP packet inquring whether or not the other modem
can do remote debugging. This extra packet has been registered with 
Microcom and the remote modem *should* ignore it if it can't handle it.
	Unfortunately, some modems don't ignore it and mistake it for
a "hang up the line" packet. That's most probably what's happening.

	- jiro

-- 
Jiro Nakamura				jiro@shaman.com
Shaman Consulting			(607) 253-0687 VOICE
"Bring your dead, dying shamans here!"	(607) 253-7809 FAX/Modem