Return to BSD News archive
Newsgroups: comp.os.386bsd.questions Path: sserve!newshost.anu.edu.au!harbinger.cc.monash.edu.au!msunews!uwm.edu!cs.utexas.edu!howland.reston.ans.net!news.sprintlink.net!dg-rtp!webo!usenet From: dave_toth@dgc.ceo.dg.com (David Toth) Subject: Re: 28.8 Modems Connecting at 14.4 ???? Sender: usenet@us.dg.com (Usenet Administration) Message-ID: <1995Mar6.214701.26045@us.dg.com> Date: Mon, 6 Mar 95 21:47:01 GMT References: <jsm9153-0303950103440001@vision0.visio.com> Organization: Data General (Canada) Inc. X-Newsreader: WinVN 0.92.6+ Lines: 39 In article <jsm9153-0303950103440001@vision0.visio.com>, jsm9153@visio.com (Jeremy Malli) says: > >Hello, > I'm having a hell of time figuring this one out. Alright, i'm running >28.8 Hayes Accura modems to allow dialup connections. The &Q? setting i'm >using is &Q5, I tried &Q6 like BSD recommends and unfortunately it seems >to turn off all error correction and data compression. What's happening is >that when someone attempts to connect to my modems at 28.8 they seem to >only be connecting at 14.4 ( at least their transfer rates would seem to >indicate so ). This happens with several different 28.8 modems trying to >connect to my system. Is there some type of register that could possibly >change the DTE and/or DCE speed to always connect at the highest possible >rate? I'm using a digiboard 8em and all the tty entries are set to 57600. > Also, if anyone could explain to me why a US Robotics Courier V.34 ( >actually two different V.34 modems ) modem will almost never connect to my >Hayes Accura V.FC i'd be thankful. I had NASTY problems with my USR connecting to V.FC modems... the answer I got from USR ... which actually makes sense was this (badly paraphrased) Many V.FC and V.Fast modem mfgs created their V.FC/V.FAST code from pre- release V.34 specifications. During the final stages of V.34, the protocol handshaking code challenge/response sequence was altered. What happens when the USR V.34 tries to talk to a "not-quite-V.34" modem goes something like this: USR Sends Negotiation Other Modem Answers with a "Can do!" message USR Sends V.34 Protocol Negotiation Other Modem Sends "old" protocol response and does CONNECT 28800/VFC/LAPM USR Looks at response... reads it as invalid... and prints NO CARRIER <click> USR Hangs up... It was found that the particular problem was in the LAPM negotiation... if you disable LAPM on the USR side when calling V.FC modems (S27=32 I think) the problem goes away and you get a V.FC/MNP connect between the modems. Hope that helps! DT