*BSD News Article 43215


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