ho@hoss.unl.edu (Tiny Bubbles...) (02/12/91)
In <653@twg.bc.ca> bill@twg.bc.ca (Bill Irwin) writes: >I have had an annoying problem that I would like to eliminate. >Frequently, although not always, when disconnecting from a >Unix/Xenix system by entering ^D to log out, a mess of control >charters is spewed to the screen before the carrier is dropped. This is caused by the loss of carrier itself. During that time, the modem is missing the underlying carrier and spews random garbage. It's not the fault of the host system, but rather of the modem and protocol used. (For example, local BBS'es would cause this effect also.) >I have some systems that I connect to which, upon log out, >produce no garbage whatsoever - then a NO CARRIER; and others >that produce no garbage, but give a new login prompt so that I >must manually tell the modem to hang up. 1. No garbage: Probably your 9600-baud lines, and 2400-baud hookups which are using an error-correcting protocol such as MNP. These will "eat" the trash so that you won't see it on the screen. In reality, the modem is waiting for the corrected data to come. It never does. It's told to drop carrier first. 2. Manually: The host modem never drops carrier, and you have to hang up on it. By definition, if you hang up on someone, the modem "knows" that you did it. On the other hand, if the other end hangs up on you, it takes a while (see below) to figure out that it happened. 3. #&$*(%(!!^%*(#@ NO CARRIER: Non-error-corrected lines will exhibit this behavior. The garbage comes from the lack of carrier and will last for a length of time determined by a modem setting. Try using "ATS10=2" and see if that reduces the length of the garbage. If so, that's the culprit. (You will never be able to completely eliminate the garbage... at least, I don't think so. I'm not a modem engineer. Toby?) -- ... Michael Ho, University of Nebraska Internet: ho@hoss.unl.edu | "Mine... is the last voice that you will ever hear." Disclaimer: Views expressed within are purely personal and should not be applied to the Daily Nebraskan or any university department.
tnixon@hayes.uucp (02/12/91)
In article <653@twg.bc.ca>, bill@twg.bc.ca (Bill Irwin) asked about
why he sometimes sees garbage on the screen when he logs off.
Michael Ho has already given a very good response: that
non-error-control modems will often spew garbage during the time
between when the carrier is lost and when they actually disconnect
the line, and that error-control modems generally hide this from the
user. There's not much you can do about it on non-error-control
calls, except make the modem more sensitive to carrier loss by
reducing the S10 time (but even this won't eliminate it entirely).
Another choice is to simply hang up the phone yourself (+++, then
ATH), but this leaves your session active on the remote until IT
detects the carrier loss, which may be a security breach and cause
other problems.
I did want to comment further on one point: this problem is MUCH
worse with V.32 modems than with V.22bis. Why? Becuase V.32 modems
use echo cancellation, and thus have a much more difficult time
determining when the remote modem has actually disconnected from the
line. When the remote disconnects, it changes the echo
characteristics of the circuit, confusing the echo canceller. Many
modems, but not all, detect this situation and hang up, but it is by
no means instantaneous (you don't want the modem hanging up on just
a burst of line noise). There are ways to take help, such as
sending a period of unmodulated carrier first rather than simply
hanging up the line, so that the other modem's echo canceller
continues to work properly and so that the remote modem can detect
the loss of signal properly. But the best way is to use an
error-control protocol, since all such protocols include a
"disconnect" function in the protocol itself, which is used to
signal the remote modem the desire to terminate the connection.
Fortunately, most V.32 modems being sold today do have error control
built in; smooth disconnections are just another reason not to buy
non-error-control V.32 modem for async applications.
Bill did mention that he has some proprietary (non-V.32) 9600
modems. I should point out that _every_ proprietary 9600 modulation
scheme in common use (PEP, HST, MNP6, Hayes, Vadic, etc.) all
_require_ the use of error control; you can't use the modulation
scheme without error control enabled, at least in async operation
(Hayes does allow synchronous non-error-control ping-pong
operation). Therefore, you should never see garbage on
disconnection from any of the proprietary schemes.
-- Toby
----------------------------------+-----------------------------------------
Toby Nixon, Principal Engineer | Voice +1-404-449-8791 Telex 151243420
Hayes Microcomputer Products Inc. | Fax +1-404-447-0178 CIS 70271,404
P.O. Box 105203 | UUCP uunet!hayes!tnixon AT&T !tnixon
Atlanta, Georgia 30348 USA | Internet hayes!tnixon@uunet.uu.net
----------------------------------+-----------------------------------------flinton@eagle.wesleyan.edu (02/14/91)
In article <653@twg.bc.ca>, bill@twg.bc.ca (Bill Irwin) asked about
why he sometimes sees garbage on the screen when he logs off.
That happens to me at times, too: when using plain vanilla 2400 to Wesleyan,
which simply drops carrier after logout, I get such bursts of ASCII (once even
the escape sequence for locking my keyboard!); on the other hand, using the
same plain vanilla 2400 to AT&T Mail, the cutoff is spotlessly clean. From
trying at 300, where I can distinguish mark from space by ear, I dicover
that AT&T Mail sends a really long break after logout, and only then drops
carrier -- that break is long enough to convince my modem of CARRIER LOST,
and it hangs up cleanly.
MNP-4 connections, like those to MCI Mail, have always been clean at logout.
-- Fred <flinton@eagle.Wesleyan.EDU> <fejlinton@{att|mci}mail.com>necka@motcid.UUCP (William J. Necka) (02/15/91)
In article <3773.27b7e1b6@hayes.uucp> tnixon@hayes.uucp writes: >Bill did mention that he has some proprietary (non-V.32) 9600 >modems. I should point out that _every_ proprietary 9600 modulation >scheme in common use (PEP, HST, MNP6, Hayes, Vadic, etc.) all >_require_ the use of error control; you can't use the modulation ^^^^^^^^^^^^^^^^^^^^^^^^^ >scheme without error control enabled, at least in async operation ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ >(Hayes does allow synchronous non-error-control ping-pong >operation). Therefore, you should never see garbage on >disconnection from any of the proprietary schemes. One small correction. The USR HST does allow none error controlled async operation. The draw back is that that the modem will not be able to switch the high speed channel. This means that depending on if your modem answered or originated, you will have the high speed or low speed channel. If memory serves me correctly, setting AT&M0&N6 will accomplish this. The &N6 forces the modem to connect at 9600. Both modems need to be configured the same. This feature has been in all the past USR HSTs, but it was never popular. ______________________________________________________________________________ ------------------------------------------------------------------------------ -- x || William Necka - __/ \__/\/\/\/ \____ Motorola Cellular || uunet!motcid!necka / \__/ \ _/ [][\_ Arlignton Heights Il. || Opinions expressed are not \__/ \__/ (________) 708-632-4435 || necessarily my employer's. _____\__/__________()__()________________________||____________________________ -------------------------------------------------------------------------------
wallach@motcid.UUCP (Cliff H. Wallach) (02/16/91)
In article <6508@khaki8.UUCP> necka@motcid.UUCP (William J. Necka) writes:
-
- One small correction. The USR HST does allow none error controlled
-async operation. The draw back is that that the modem will not be able
-to switch the high speed channel. This means that depending on if your
-modem answered or originated, you will have the high speed or low speed
-channel. If memory serves me correctly, setting AT&M0&N6 will accomplish
-this. The &N6 forces the modem to connect at 9600. Both modems need to
-be configured the same. This feature has been in all the past USR HSTs, but
-it was never popular.
This was originally a test mode from the time before MNP was
implemented; however, a surprising number of customers use this mode.
Synchronous operation is possible by setting &M1&N[4..8]
Cliff Wallach ...uunet!motcid!wallach