res@colnet.uucp (Rob Stampfli) (04/14/91)
I understand the basics of how MNP and V.42 work, but I have never seen anyone describe exactly how two modems negotiate a reliable protocol and, possibly, compression. How do they do this? Does one end send a special set of characters to the other end and look for a response? Do they use special tones or timing sequences? If I am calling an intelligent modem from a "dumb" one, what should I expect to see while the intelligent casts about trying to figure out the capabilities of the modem on the other end? Could someone post a short description of what goes on during the modem's call setup. Thanks, -- Rob Stampfli, 614-864-9377, res@kd8wk.uucp (osu-cis!kd8wk!res), kd8wk@n8jyv.oh
tnixon@hayes.uucp (04/17/91)
In article <1991Apr14.062847.16418@colnet.uucp>, res@colnet.uucp (Rob Stampfli) writes: > I understand the basics of how MNP and V.42 work, but I have never seen > anyone describe exactly how two modems negotiate a reliable protocol and, > possibly, compression. How do they do this? Does one end send a special > set of characters to the other end and look for a response? Do they use > special tones or timing sequences? If I am calling an intelligent modem > from a "dumb" one, what should I expect to see while the intelligent casts > about trying to figure out the capabilities of the modem on the other end? [How can I do this _briefly_? :-) ] A V.42 originating modem will initially send a series of XON (DC1; 11h) characters, with alternating parity bits (11h, 91h), separated by 8 to 16 mark bits (this was felt to be very difficult for a human typist to accidentally generate, thereby reducing the possibility of a non-error-control originating modem being mistaken for an error-control modem). It listens for the answering modem to send a series of repeated "EC" character patterns. If it receives this pattern, it assumes that the answering modem has V.42 LAPM capability, and goes on to establish the LAPM protocol. To establish the LAPM protocol, the originating modem first sends an Exchange Identification (XID) command frame. This frame contains the options that the modem desires to negotiate, in Type/Length/Value format. The answering modem analyzes this frame, selects from the options offered, and specifies the options to be used during the connection in an XID Response frame (I'm intentionally leaving out the "what ifs", such as "what if the XID command frame is corrupted by line noise?"). The originating modem then sends a SABME (Set Asynchronous Balanced Mode Extended) frame, the answerer responds with a UA (Unnumbered Acknowledge) frame, and the protocol is established and ready for data transfer. If the EC pattern is not received, a V.42 originating modem will attempt the Alternative protocol (MNP compatible), by sending an MNP "Link Request" frame one or more times using the start/stop character-oriented framing mode (MNP2). If the answering modem replies with an LR frame, the originating modem responds with a Link Acknowledge frame, and the MNP protocol is established. The LR frames contain the MNP protocol options, in T/L/V encoding; there is not a separate parameter negotiation phase (which is why MNP can't renegotiate parameters during a connection, but LAPM can). Data compression is one of the options negotiated in the XID or LR exchange. The originating modem specifies all the different types of data compression that it supports on the given protocol. The answering modem selects from among those, or none, and responds. The modems don't use any special tones to identify error control capability. Timing _is_ used, in the sense that if the modem doesn't see the character pattern or protocol frame expected from the other side within a specified timeout period, it gives up and assumes the other modem doesn't support error control (although it may retry the frame several times before giving up). If you call an error control modem from a dumb modem, you won't see ANYTHING (unless the error control modem you're calling is a Hayes modem, in which case you might see a pattern of space and backspace characters, which Hayes V-series modems use to detect the presence of pre-V.42 proprietary Hayes error control schemes). That's because the CALLING (originating) modem sends first in both LAPM and MNP. 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. -- Toby P.S. I represent Hayes in CCITT Study Group XVII, and helped write big chunks of V.42. The "Detection Phase" part of the V.42 standard originated in a contribution to the CCITT from Hayes. -- Toby Nixon, Principal Engineer | Voice +1-404-840-9200 Telex 151243420 Hayes Microcomputer Products Inc. | Fax +1-404-447-0178 CIS 70271,404 P.O. Box 105203 | UUCP uunet!hayes!tnixon AT&T !tnixon Atlanta, Georgia 30348 USA | Internet hayes!tnixon@uunet.uu.net
ho@hoss.unl.edu (Tiny Bubbles...) (04/17/91)
Say I have a dumb modem and I'm calling a smart modem, oh, for example,
a Microcom QX-series MNP 10/LAPM modem. (Real hypothetical, huh? :-) )
I advise people not to type *anything* for 2.5 seconds after the dumb
modem reports a connect to prevent being mistaken for an MNP modem.
But is there anything (like spaces, backspaces, returns) that would
actually cause a modem like that to screw up? I ask that because it
seems to have happened to a few people, and nobody knows why.
Also, some el-cheapo internal modems, most of them using very old
chipsets, can't connect to the Microcoms *at all*. Is this a problem
with other V.32 modems, or just Microcoms, or just our setup?
--
... Michael Ho, University of Nebraska
Internet: ho@hoss.unl.edu | Harry was too homely for Sally. (I have proof.)
Disclaimer: Views expressed within are purely personal and should not be
applied to any university agency.ho@HOSS.UNL.EDU (Tiny Bubbles...) (04/17/91)
>Newsgroups: comp.dcom.modems >Path: unlinfo.unl.edu!hoss!ho >From: ho@hoss.unl.edu (Tiny Bubbles...) >Subject: Re: Reliable and Compression Protocols -- how do they sync up? >Message-ID: <1991Apr17.010942.10457@unlinfo.unl.edu> >Sender: news@unlinfo.unl.edu >Nntp-Posting-Host: hoss.unl.edu >Organization: <none> >References: <1991Apr14.062847.16418@colnet.uucp> <3913.280b3f55@hayes.uucp> >Distribution: na >Date: Wed, 17 Apr 1991 01:09:42 GMT >Lines: 17 Say I have a dumb modem and I'm calling a smart modem, oh, for example, a Microcom QX-series MNP 10/LAPM modem. (Real hypothetical, huh? :-) ) I advise people not to type *anything* for 2.5 seconds after the dumb modem reports a connect to prevent being mistaken for an MNP modem. But is there anything (like spaces, backspaces, returns) that would actually cause a modem like that to screw up? I ask that because it seems to have happened to a few people, and nobody knows why. Also, some el-cheapo internal modems, most of them using very old chipsets, can't connect to the Microcoms *at all*. Is this a problem with other V.32 modems, or just Microcoms, or just our setup? -- ... Michael Ho, University of Nebraska Internet: ho@hoss.unl.edu | Harry was too homely for Sally. (I have proof.) Disclaimer: Views expressed within are purely personal and should not be applied to any university agency. -- ... Michael Ho, University of Nebraska Internet: ho@hoss.unl.edu | Harry was too homely for Sally. (I have proof.) Disclaimer: Views expressed within are purely personal and should not be applied to any university agency.
root@zswamp.uucp (Geoffrey Welsh) (04/18/91)
>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
root@zswamp.uucp (Geoffrey Welsh) (04/18/91)
In a letter to All, Tiny Bubbles... (ho@HOSS.UNL.EDU ) wrote: >Also, some el-cheapo internal modems, most of them using >very old >chipsets, can't connect to the Microcoms *at all*. Is this >a problem >with other V.32 modems, or just Microcoms, or just our >setup? As I just reported to Toby, I suspect that these modems can't handle the V.42 protocol negotiation request. Dropping back to MNP or no error correction at all should solve the problem (add the disable command to your dial string). -- 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
tnixon@hayes.uucp (04/18/91)
In article <9104170413.AA03912@ucbvax.Berkeley.EDU>, ho@HOSS.UNL.EDU (Tiny Bubbles...) writes: > Say I have a dumb modem and I'm calling a smart modem, oh, for example, > a Microcom QX-series MNP 10/LAPM modem. (Real hypothetical, huh? :-) ) > > I advise people not to type *anything* for 2.5 seconds after the dumb > modem reports a connect to prevent being mistaken for an MNP modem. > But is there anything (like spaces, backspaces, returns) that would > actually cause a modem like that to screw up? I ask that because it > seems to have happened to a few people, and nobody knows why. The MNP Link Request frame starts with the ASCII characters SYN, DLE, STX. Nothing else you type could be mistaken for an MNP frame, so it shouldn't cause the modem to "screw up". Some modems look for certain _specific_ characters (like ^C, or CR) to force an immediate fall back to non-error-control mode, but, again, this is the desired result, not a "screw up". Can you describe the problem in greater detail -- what are you observing that is undesirable? > Also, some el-cheapo internal modems, most of them using very old > chipsets, can't connect to the Microcoms *at all*. Is this a problem > with other V.32 modems, or just Microcoms, or just our setup? Who knows. It could be that the "el-cheapo" modems don't respond fast enough to the unscrambled binary one (USB1) signal sent to initiate V.22bis/V.22/Bell 212 modulation, so the Microcom modem (assuming it is the answering modem) goes on to try V.32 again, and the connection fails. But if the "el-cheapo" modem is this far out of compliance with the applicable standards, you'd see the problem with ANY of the newer V.32 Automode modems, not just Microcom. -- Toby -- Toby Nixon, Principal Engineer | Voice +1-404-840-9200 Telex 151243420 Hayes Microcomputer Products Inc. | Fax +1-404-447-0178 CIS 70271,404 P.O. Box 105203 | UUCP uunet!hayes!tnixon AT&T !tnixon Atlanta, Georgia 30348 USA | Internet hayes!tnixon@uunet.uu.net
tnixon@hayes.uucp (04/22/91)
In article <7220.280D2809@zswamp.uucp>, root@zswamp.uucp (Geoffrey Welsh) writes: > 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? If the GVC modem only sends 0x91 characters, a V.42-compliant answering modem will not recognize it as supporting LAPM protocol. It should connect in MNP after fallback, I hope... > 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! Does the Hedaka have MNP itself? Or is it a non-error-control modem? It's strange that it would "lock up", but then nothing much surprises me in modems anymore. -- Toby Nixon, Principal Engineer | Voice +1-404-840-9200 Telex 151243420 Hayes Microcomputer Products Inc. | Fax +1-404-447-0178 CIS 70271,404 P.O. Box 105203 | UUCP uunet!hayes!tnixon AT&T !tnixon Atlanta, Georgia 30348 USA | Internet hayes!tnixon@uunet.uu.net
root@zswamp.uucp (Geoffrey Welsh) (04/23/91)
>From: tnixon@hayes.uucp >In article <7220.280D2809@zswamp.uucp>, root@zswamp.uucp >(Geoffrey Welsh) writes: > 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? >If the GVC modem only sends 0x91 characters, a >V.42-compliant >answering modem will not recognize it as supporting LAPM >protocol. >It should connect in MNP after fallback, I hope... That's the thing: it appeared to connect in V.42 mode to modems such as the USRobotics HST. I was wondering if this was explainable... > 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! >Does the Hedaka have MNP itself? Or is it a >non-error-control >modem? It's strange that it would "lock up", but then >nothing much surprises me in modems anymore. No, it's a SendFAX modem. MNP initiation requests don't seem to bother it, but a call from a V.42 modem doesn't result in a usable connection. Oddly, my Hayes Smartmodem 2400 won't recognize its answer tone when I call at 2400, but it will at 1200 (a recent occurrence, though a USR HST in my area doesn't have the problem... once I configured that system to call this one with LAP-M disabled, he has all good connects) You're right about one thing: *nothing* about modem connectivity should surprise us anymore. -- UUCP: watmath!xenitec!zswamp!root | 602-66 Mooregate Crescent Internet: root@zswamp.uucp | 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