Path: utzoo!news-server.csri.toronto.edu!cs.utexas.edu!usc!wuarchive!zaphod.mps.ohio-state.edu!casbah.acns.nwu.edu!ucsd!pacbell.com!tandem!netcom!gandrews From: gandrews@netcom.COM (Greg Andrews) Newsgroups: comp.dcom.modems Subject: Re: MultiTech MultiModem V32 & T2500 Summary: It's NOT the remote access packet. Keywords: MultiModem V32, T2500 Message-ID: <27258@netcom.COM> Date: 7 Mar 91 15:47:54 GMT References: <148@ipars.UUCP> <408@frcs.UUCP> <1991Mar7.002423.4267@shaman.com> Organization: Netcom - Online Communication Services UNIX System {408 241-9760 guest} Lines: 26 In article <1991Mar7.002423.4267@shaman.com> jiro@shaman.com (Jiro Nakamura) writes: > [report of T2500-Multitech MNP disconnection problem deleted] > > 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. > No, that's *NOT* what's happening, as is evidenced by the fact the problem still shows up when the T2500 answers the phone, and also when the T2500 has been told to disable remote access and protocol support. Under those circumstances, the T2500 does not attempt to negotiate those features, so no "extra MNP packet" is sent. People who are experiencing this problem are kindly requested to ask Telebit tech support about it rather than trade wild guesses on Usenet. Pretty please? -- .-------------------------------------------. | Greg Andrews | gandrews@netcom.COM | `-------------------------------------------'