scotto@ipars.UUCP (Scott O'Connell) (03/03/91)
I have just taken over a network with several MultiTech MultiModem V32 modems. I have been using Telebit T2500's and now need to make the two flavors of V32 talk consistantly. The problem is when the MultiModem calls the Telebit (could be any modem on the answering end) it connects with "CONNECT 9600 RELIABLE COMPRESSED" and the session begins. After roughly 5-10 minutes (with or without activity) the connection is dropped. The last thing I tried before going to bed was calling the MultiModem from the Telebit. The T2500 responded "CONNECT 9600/REL". This connection lasted all night and only dropped when I disconnected the line manually. MultiModem V32 is configured as follows: AT &F &W AT Q2 X4 &D3 &E1 &E4 &E13 &E15 $SB19200 $BA0 $R1 &BS1 &W Modem ID: 2342 Firmware: 1.05 I have *not* called MultiTech technical support. I wanted to learn a little more about the modem before calling. Thanks
gandrews@netcom.COM (Greg Andrews) (03/04/91)
In article <148@ipars.UUCP> scotto@ipars.UUCP (Scott O'Connell) writes: > >The problem is when the MultiModem calls the Telebit (could be any modem >on the answering end) it connects with "CONNECT 9600 RELIABLE COMPRESSED" >and the session begins. After roughly 5-10 minutes (with or without >activity) the connection is dropped. > It looks from the result code like you're getting an MNP connection. What happens when you get a V.42 connection or one without any error control? -- .-------------------------------------------. | Greg Andrews | gandrews@netcom.COM | `-------------------------------------------'
paul@frcs.UUCP (Paul Nash) (03/05/91)
Thus spake scotto@ipars.UUCP (Scott O'Connell): > I have just taken over a network with several MultiTech MultiModem V32 > modems. I have been using Telebit T2500's and now need to make the two > flavors of V32 talk consistantly. I have had a similar problem, and found that the only way to make the MultiTech talk to the TB reliably was by disabling MNP (error correction _and_ compression) on the TB. Like this, it works fine. The TB has always called the MultiTechs reliably, but they just won't connect properly if the TB tries to negotiate error correction. Your mileage may vary. ---=---=---=---=---=---=---=---=---=---=---=---=---=---=---=---=---=--- Paul Nash Free Range Computer Systems cc paul@frcs.UUCP ...!uunet!m2xenix!frcs!paul
jiro@shaman.com (Jiro Nakamura) (03/07/91)
In article <408@frcs.UUCP> paul@frcs.UUCP (Paul Nash) writes: >I have had a similar problem, and found that the only way to make the >MultiTech talk to the TB reliably was by disabling MNP (error correction >_and_ compression) on the TB. Like this, it works fine. >The TB has always called the MultiTechs reliably, but they just won't >connect properly if the TB tries to negotiate error correction. 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. - jiro -- Jiro Nakamura jiro@shaman.com Shaman Consulting (607) 253-0687 VOICE "Bring your dead, dying shamans here!" (607) 253-7809 FAX/Modem
gandrews@netcom.COM (Greg Andrews) (03/07/91)
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 | `-------------------------------------------'
tim@appenzell.cs.wisc.edu (Tim Theisen) (03/10/91)
In article <408@frcs.UUCP> paul@frcs.UUCP (Paul Nash) writes: >Thus spake scotto@ipars.UUCP (Scott O'Connell): > >> I have just taken over a network with several MultiTech MultiModem V32 >> modems. I have been using Telebit T2500's and now need to make the two >> flavors of V32 talk consistantly. > >I have had a similar problem, and found that the only way to make the >MultiTech talk to the TB reliably was by disabling MNP (error correction >_and_ compression) on the TB. Like this, it works fine. > >The TB has always called the MultiTechs reliably, but they just won't >connect properly if the TB tries to negotiate error correction. Here is another data point: I have access to MultiTech V32's (MT932EA) and MultiTech 224E's (MT224EH) and Telebit T1600's. I checked interoperability between all of these modems. I found that the Telebit T1600's had no trouble talking with the MultiTechs as either originating or answering modem. The one problem that I did see involved a T1600 calling a MT224E. One of the 224E's that I tested had an older version of firmware. The Telebit could not negotiate for a reliable connection with it. Other 224E's did not exhibit this problem. Overall, I think that MultiTech modems interact fine with a Telebit T1600. ...Tim -- Tim Theisen Department of Computer Sciences Systems Programmer University of Wisconsin-Madison tim@cs.wisc.edu 1210 West Dayton Street (608)262-0438 Madison, WI 53706
gs26@prism.gatech.EDU (Glenn R. Stone) (03/14/91)
In <408@frcs.UUCP> paul@frcs.UUCP (Paul Nash) writes: >Thus spake scotto@ipars.UUCP (Scott O'Connell): >> I have just taken over a network with several MultiTech MultiModem V32 >> modems. I have been using Telebit T2500's and now need to make the two >> flavors of V32 talk consistantly. >I have had a similar problem, and found that the only way to make the >MultiTech talk to the TB reliably was by disabling MNP (error correction >_and_ compression) on the TB. Like this, it works fine. You can set S106, S97, and S95 on the T2500 to toggle the negotiation of LAP/M and MNP. If the Multitech has V.42 LAP/M, you may want to set things up so that only LAP/M is used. (I've found I have to do the opposite (i.e. set for MNP only) when calling a Microcom modem from my T2500.... the Microcom gets real confused when it hears the T2500 try to negotiate LAP/M...) See the Release 7.00 Addendum to TFM for details. -- Glenn R. Stone gs26@prism.gatech.edu