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 |
`-------------------------------------------'