CS117341@YUSol.BITNET (Norman) (12/05/89)
Hello all, In a previous posting, I mentioned that MNP didn't seem to be very transparent... I received the following message from Bjorn Sjoholm: >>Oh, on a (slightly) related note, I've noticed that when connecting >>to non-MNP modems with MNP enabled on the T2500 results in an >>unusable connection. Maybe I'm mistaken, but I thought MNP was >>supposed to be a transparent protocol negotiated by both modems >>after they connect. Does anyone have any suggestions? > I have the same problem using Microcom AX/2424c Modems which > are MNP class 5. After days of struggling with the problem > I noticed, in the manual entry > for "AT\N", that when operating in "AT\N3"-mode (auto-reliable) > the modem needs 12 seconds (!) to drop down to normal mode! > The solution is to always use "AT\N0"-mode when calling > non-MNP modems. > > Hope this helps, > > Bjorn I checked the T2500 manual, and when you set S95=2 (auto-reliable), the modem will attempt to connect with MNP for 4 second. If it cannot negotiate MNP within that time, it will fall back to non-reliable mode. Unfortunately, when I try this, the modem does indeed take about 4 seconds to show a CONNECT, however, at this point the modem doesn't seem to respond to anything typed from the keyboard. After 20 to 30 seconds, the connection is dropped. I suppose the only solution is to turn off MNP when you know the modem on the other end is non-MNP. *sigh* Norman cs117341@yusol.Bitnet cs117341@sol.YorkU.CA cs117341%yusol@mivma.mit.edu cs117341%yusol@cunyvm.cuny.edu
joe@junkyard.UUCP (Joseph Sarkes) (12/06/89)
In article <89Dec4.212759est.57389@ugw.utcs.utoronto.ca>, CS117341@YUSol.BITNET (Norman) writes: > >>Oh, on a (slightly) related note, I've noticed that when connecting > >>to non-MNP modems with MNP enabled on the T2500 results in an > >>unusable connection. Maybe I'm mistaken, but I thought MNP was > >>supposed to be a transparent protocol negotiated by both modems > >>after they connect. Does anyone have any suggestions? My understanding of what is happening is that if the machine being called is set up to echo (full duplex) characters sent to it, it is quite easy for the mnp modem to get confused and assume that it is talking to another mnp modem, and then just gets hung in trying to talk mnp to the other modem, which is just echoing what the mnp modem is transmitting for negotiation. Thus the non mnp modem "looks" just like an mnp modem that is sending the negotiation data. Are you confused yet???? Joseph Sarkes (junkyard!joe)
bei@puzzle.UUCP (Bob Izenberg) (12/06/89)
In article <89Dec4.212759est.57389@ugw.utcs.utoronto.ca> CS117341@YUSol.BITNET (Norman) writes: >I suppose the only solution is to turn off MNP when you know the modem >on the other end is non-MNP. > The MNP Class 5 on the AT&T 2224CEO caused uucp 'g' to choke, and the other end would get a SIGNAL 1 or an IN SEND/SLAVE MODE INPUT FAILURE. Turning it off let data through with only the usual line problems... There's such a thing as a too-smartmodem. -- Bob -- ------------------------------------------------------------------------------ Bob Izenberg [ ] Ralph Kirkley Associates attctc!puzzle!bei (or) cs.utexas.edu!ibmchs!auschs!evil-ed!bei ------------------------------------------------------------------------------
jobrien@nixbur.UUCP (John O'Brien) (12/09/89)
one other "non-transparent" feature I noticed with MNP is what happened when I tried to do a kermit file transfer. The reason I was using kermit was that I was transferring a large number of files and I didn't want to have to type in all those file names. When I tried to do the transfer, the modem locked up and had to be reset. The problem was that kermit uses ^a (ctrl-a) as a packet header, and MNP uses ^a for something, too. When I set the start of packet header to ^b instead, the transfer worked, although it was slower than straight text transfer. Is there any software file trans- fer protocol that works with MNP? John F. O'Brien