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