NetNews Usenet Archive 1992 #30/NN_1992_30.iso/spool/comp/sys/att/2660

Internet Message Format | 1992-12-16 | 7.3 KB

Path: sparky!uunet!munnari.oz.au!jabaru.cec.edu.au!csource!gateway
From: [e-mail] (Bruce Weinel)
Newsgroups: comp.sys.att
Subject: The proper configuration of a modem
Message-ID: <[e-mail]>
Date: Mon, 14 Dec 1992 08:23:10
Sender: [e-mail]
Lines: 145

Daniel W. James (cS) was heard in "The Pit" saying to  All

  cS> I have a 9600 baud modem (on a line both incoming and outgoing running
  cS> uugetty) on a port which is obviously configured at 9600 baud as well.
  cS> Unfortunatly I've only got 1200 at home.
  cS>
  cS> The problem is that uugetty (or is it login?) doesn't detect the fact
  cS> that I am connecting at such a slow speed.  After logging in, 'stty'
  cS> shows me connected at 9600, and I've also created custom login prompts
  cS> for each baud rate.  My modem tells me I've connected at 1200, but my
  cS> login prompt says 9600. This in itself wouldn't be a problem, except
  cS> that I am also dialing in using an old Atari computer running vt100
  cS> emulation software with a horrible flow-control problem.  If I try to
  cS> send something to the screen with about 3 or more lines, I begin
  cS> seeing nothing but garbage.  Perhaps I've 'cabled' my modem here
  cS> incorrectly, perhaps a lot of things, but it seems to me that if the
  cS> 3b2 was communicating with the modem at 1200, rather than 9600 (and
  cS> forcing the modem to buffer the i/o) that the problems might go away.

  cS> Also, the modem is on an eports card, and when I try to enable
  cS> hardware flow control, I get a different
  cS> problem.
  cS>
  cS> Anyway, here's my relevant settings:
  cS> ------------------------------------
  cS> /etc/inittab
  cS> ----------------------------------------
  cS> 12:234:respawn:/usr/lib/uucp/uugetty -r -t 25 tty12 modem # Dial-Up
  cS> Port
  cS>
  cS> /etc/gettydefs (first couple of relevant lines)
  cS> ----------------------------------------
  cS> modem# B19200 OPOST ONLCR # B19200 HUPCL SANE IXANY TAB3 # 19.2K
  cS> Login: #96modem
  cS> 96modem# B9600 HUPCL # B9600 SANE IXANY TAB3 HUPCL
  cS> #9600 baud Login: #24modem
  cS> 12modem# B1200 HUPCL # B1200 SANE IXANY
  cS> TAB3 HUPCL #baud Login: #3modem
  cS>
  cS> ---> The following doesn't seem to work at all...
  cS> I've been unable to connect @300:
  cS> 3modem# B300 HUPCL # B300 SANE IXANY
  cS> TAB3 HUPCL #300 baud Login: #modem
  cS>
  cS> /usr/lib/uucp/*  (These are all for outgoing calls no?)
  cS>
  cS> -----------------------------------------------------------------
  cS> Probably even more important, the modem settings:
  cS> -----------------------------------------------------------------
  cS> ACTIVE PROFILE:            DTE:9600      DCE:9600      PARITY:NONE B16
  cS> B1 B41 B60 E1 L1 M0 N1 Q2 T V1 W0 X4 Y0 &C2 &D3 &K7 &Q8 &S1 &U0 &Y0
  cS> S00:001 S01:000 S02:043 S03:013 S04:010 S05:008 S06:002 S07:050
  cS> S08:001 S09:006 S10:014 S11:070 S12:050 S18:000 S25:005 S26:001
  cS> S30:000 S36:007 S37:000 S38:020 S43:009 S46:138 S48:007 S82:128
  cS> S86:006
  cS> S95:045
  cS>
  cS> And, for reference sake, some of the settings that might be involved:
  cS> --------------------
  cS> PM9600 Quick Command Reference      Page 1 of 6 (*= Default Setting)
  cS>
  cS>                PM9600 Quick Command Reference              Page 1 of 6
                         (*= Default Setting)

   N0  Orig & Answer at S37 Speed     *N1  Orig & Answer Interwork from S37
   N3  Originate at S37 Speed,         N5  Originate Interworks from S37,
        Answer Interworks from V.32         Answer Only at S37 Speed
--> Using N1 allows both incoming and outgoing calls to negotiate a common
    speed, starting with the highest possible.

  *Q0  Send Result Codes               Q1  Do Not Send Result Codes
   Q2  No Result Codes on Answer
--> Using Q2...  I don't think uugetty watches for result codes, but then I
    was having this problem when I had it set at Q0

  *W0  No Negotiation Progress Messages
   W1  Progress Messages report DTE Speed
   W2  Progress Messages report DCE Speed
--> Was somewhat confusing, and caused problems at times,
    so I disabled it (W0)

  &K0  No Flow Control                *&K3  RTS/CTS Flow Control
  &K4  XON/XOFF Flow Control           &K5  Unsupported
  &K6  XON/XOFF Flow Control with      &K7  RTS/CTS Flow Control with
        Remote XON/XOFF Flow Control         Remote XON/XOFF Flow Control
--> &K7--Hardware flow control between 3b2/modem, software between
    connecting modems

  S1  Ring Count                 0     S25 DTR Change Time               5
  S2  Escape Sequence Char      43     S30 Inactivity Timeout            0
  S3  Carriage Return Char      13     S36 Negotiation Fallback          7
  S4  Line Feed Char            10     S37 Maximum DCE Speed             0
  S5  Back Space Char            8     S38 Delay before Hangup          20
  S6  Wait Time for Dial Tone    2     S43 Current DCE Speed             0
  S7  Wait Time for Carrier     50     S46 Compression Selection       138
  S8  Pause Duration             2     S48 Feature Negotiation Action    7
  S9  Carrier Detect Time        6     S82 Break Handling Options      128
  S10 Carrier Loss Time         14     S86 Connection Failure Reason     0
  S11 DTMF Tone Duration        95     S95 Negotiation Messages          0
  S12 Escape Guard Time         50

  cS>
--------------------------------------------------------------------------
  cS> Sorry to be so long, but I know that in a case like this, the more
  cS> information I can throw out, the more likely I'll here something back
  cS> :)
  cS>
  cS> Thanx, Dan.

Sorry for this huge quote, but this is a FAQ (and not just on Unix). If you
want the system to use other than the default 9600 BPS then there is a
conflict
in the smart modem settings. Setting W0 (instead of W2) causes the modem to
report all connections at the host-to-modem (DTE) speed instead of the
modem-to-modem
(DCE) speed. In this case the modem would always report 'CONNECT 9600' when
the 1200 BPS home modem connects. The dialer scripts aren't included [Don, you
didn't throw out enough...sorry], but if they look at the 'CONNECT' message
then they'll have no reason to shift speed. The getty won't autobaud away from
9600 because the modem is using 9600 BPS and that's what the Unix port sees.

However, it is questionable whether it is desirable to shift to lower speed
anyway. If end-to-end handshaking is valid then there is no need to slow the
host modem to remote speed. XON/XOFF is usually preferred for Unix access and
I would normally set &K3, but &K7 is valid if you know that the eports card
is configured for RTS/CTS handshake *AND* that your tty driver supports the
card properly in this mode. If in doubt (and I am) then I'd fallback to
XON/XOFF
flow control.

The odds are that the problem is in the remote. Either the emulator software
is too slow (resulting in overrunns that scramble characters), is missing
XOFFs
(this could also be due to their being scrambled) or doesn't handle them
right.
There is also a remote chance that the 1200 BPS modem is intentionally
changing
XOFF characters in an attempt to implement TRANSPARENT XON/XOFF (the
unsupported
&K5 option of your host modem), but this is unlikely.

Rule of thumb: Use XON/XOFF at Unix end. Leave the host modem alone. Fiddle
with the remote emulator (in fact, try several) until satisfied.

 * Origin: Howls from "The Pit" BBS [phone] (3:632/456.1@fidonet)