Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!wuarchive!zaphod.mps.ohio-state.edu!pacific.mps.ohio-state.edu!linac!att!news.cs.indiana.edu!maytag!xenitec!zswamp!root From: root@zswamp.uucp (Geoffrey Welsh) Newsgroups: comp.dcom.modems Subject: Re: Reliable and Compression Protocols -- how do they sync up? Message-ID: <7220.280D2809@zswamp.uucp> Date: 17 Apr 91 18:44:42 GMT Organization: Izot's Swamp BBS (FidoNet), Kitchener, Ontario Lines: 35 >From: tnixon@hayes.uucp >[How can I do this _briefly_? :-) ] Forget briefly, you did it *well*. >If, on the other hand, the DUMB modem was answering and being >called by a V.42 modem, it would first see XONs with alternating >parity for about 750 milliseconds, followed by one or two spurts of >"garbage" data (the MNP protocol attempt), followed by nothing when >the error-control modem falls back to non-error-control mode. During my experimentation with the GVC Super Modem 9600 (V.32 & V.42), I found that my Hayes Smartmodem reported only 0x91 characters; is there a logical explanation for this, or might this have been the source of occasional problems I had with the GVC V.32? I have found many modems which don't like being blasted with a V.42 negotiation request, and sometimes dropping them to MNP only solved the problem. One example is a SendFAX modem sold under the name "Hedaka"; I can't call it with V.42 modems such as the ATI 2400etc and the latest revision of HST, but the older HSTs (which only requested MNP) and modems such as the Cardinal 2400MNP work fine. The Hedaka locks up completely when called by a V.42 compliant modem! -- UUCP: watmath!xenitec!zswamp!root | 602-66 Mooregate Crescent Internet: root@zswamp.fidonet.org | Kitchener, Ontario FidoNet: SYSOP, 1:221/171 | N2M 5E6 CANADA Data: (519) 742-8939 | (519) 741-9553 The mile is traversed not by a single leap, but by a procession of coherent steps; those who insist on making the trip in a single element will be failing long after you and I have discovered new worlds. -- me