ditto@cbmvax.UUCP (Michael "Ford" Ditto) (10/20/88)
In article <727@wsccs.UUCP> terry@wsccs.UUCP (Every system needs one) writes: >UNIX on, DTR high, phone rings: Modem answers the phone. Connection > occurs. Modem sends "CONNECT" > message to the computer. [ ... ] > [ Turning off ] > [ result codes is a bad idea, since it can ] > [ keep you from dialing out. ] I disagree. Having "result codes" on a dialin modem on a Unix system is a pretty stupid idea, for the above mentioned reason (Modem sends "CONNECT" message to the computer ... computer thinks "CONNECT" is a login name, etc.). There is no reason for the "result codes" to be turned on except when dialing out. -- -=] Ford [=- "The number of Unix installations (In Real Life: Mike Ditto) has grown to 10, with more expected." ford@kenobi.cts.com - The Unix Programmer's Manual, ...!sdcsvax!crash!elgar!ford 2nd Edition, June, 1972. ditto@cbmvax.commodore.com
friedl@vsi.COM (Stephen J. Friedl) (10/20/88)
In article <5042@cbmvax.UUCP>, ditto@cbmvax.UUCP (Michael "Ford" Ditto) writes: > > I disagree. Having "result codes" on a dialin modem on a Unix > system is a pretty stupid idea, for the above mentioned reason > (Modem sends "CONNECT" message to the computer ... computer thinks > "CONNECT" is a login name, etc.). It is certainly a drag to be stuck in upper case because RING was seen as a login. To combat this, we set our modems to give digit result codes instead of verbose ones; we've been quite pleased except that it's harder to debug the outgoing dialing... Steve -- Steve Friedl V-Systems, Inc. +1 714 545 6442 3B2-kind-of-guy friedl@vsi.com {backbones}!vsi.com!friedl attmail!vsi!friedl ---------Nancy Reagan on the Three Stooges: "Just say Moe"---------
jfh@rpp386.Dallas.TX.US (The Beach Bum) (10/22/88)
In article <889@vsi.COM> friedl@vsi.COM (Stephen J. Friedl) writes: >In article <5042@cbmvax.UUCP>, ditto@cbmvax.UUCP (Michael "Ford" Ditto) writes: >> I disagree. Having "result codes" on a dialin modem on a Unix >> system is a pretty stupid idea, ... > >It is certainly a drag to be stuck in upper case because >RING was seen as a login. To combat this, we set our modems >to give digit result codes instead of verbose ones; I run both lines bi-directional on this system. The approach I use is to turn off echo and result codes when I prepare the modem for dialin. Then, when the modem is being initialized for dialing out, result codes and echo are both enabled. I use verbose result codes since getty is no longer in the picture. The string I send just after hangup is ATE0V1Q1S0=1, then when I am ready to start dialing I send ATE1V1Q0S0=0 [ and curse the RING codes I still wind up getting ]. -- John F. Haugh II +----Make believe quote of the week---- VoiceNet: (214) 250-3311 Data: -6272 | Nancy Reagan on Richard Stallman: InterNet: jfh@rpp386.Dallas.TX.US | "Just say `Gno'" UucpNet : <backbone>!killer!rpp386!jfh +--------------------------------------
dave@westmark.UUCP (Dave Levenson) (10/22/88)
In article <889@vsi.COM>, friedl@vsi.COM (Stephen J. Friedl) writes: > In article <5042@cbmvax.UUCP>, ditto@cbmvax.UUCP (Michael "Ford" Ditto) writes: ... > > (Modem sends "CONNECT" message to the computer ... computer thinks > > "CONNECT" is a login name, etc.). ... > It is certainly a drag to be stuck in upper case because > RING was seen as a login. To combat this, we set our modems > to give digit result codes instead of verbose ones; we've > been quite pleased except that it's harder to debug the > outgoing dialing... There is a simpler solution, for UNIX Sys V Rel 2.5 on the 6300PLUS. Perhaps it also applies to the 6386. In your inittab, when you spawn uugetty on the modem, set option -d<n> with a value in seconds. This causes uugetty to ignore characters for <n> seconds before prompting for login. I generally use uugetty -d8 to pause 8 seconds after answering before prompting. This means that the modem can generate the RING message, and then the CONNECT message that results from the modem handshake, before I expect a login name. Verbose mode works fine with this option. I find verbose mode makes the dialer script a bit more robust. -- Dave Levenson Westmark, Inc. The Man in the Mooney Warren, NJ USA {rutgers | att}!westmark!dave
dave@onfcanim.UUCP (Dave Martindale) (10/22/88)
What you *really* want for mixed dialin/dialout on UNIX is a modem that is totally silent, like any dumb modem, when answering a call but which provides verbose "result codes" in originate mode. With some Hayes-compatible modems, you can do this by having result codes turned off in the settings in EEPROM, having the modem reset itself from the EEPROM settings when DTR drops, and then using a uucico "chat script" to turn on result codes before dialing. Or you can just use a Trailblazer, which allows you to specify silent answer mode and verbose originate mode. The Trailblazer has the largest number of useful options of any modem I've ever seen. (Hello, Hayes, anyone awake out there?)
terry@wsccs.UUCP (Every system needs one) (10/30/88)
In article <889@vsi.COM>, friedl@vsi.COM (Stephen J. Friedl) writes: > In article <5042@cbmvax.UUCP>, ditto@cbmvax.UUCP (Michael "Ford" Ditto) writes: > > I disagree. Having "result codes" on a dialin modem on a Unix > > system is a pretty stupid idea, for the above mentioned reason > > (Modem sends "CONNECT" message to the computer ... computer thinks > > "CONNECT" is a login name, etc.). > > It is certainly a drag to be stuck in upper case because > RING was seen as a login. To combat this, we set our modems > to give digit result codes instead of verbose ones; we've > been quite pleased except that it's harder to debug the > outgoing dialing... Urg. My suspicions confirmed. Nobody is reading anything anybody else is posting. IF you have your modem set up correctly, it will not raise DCD until after it has sent the result code. IF you have your UNIX set up correctly, all input prior to the modem raising DCD will be thrown away, as the open has not completed. IF you open your port correctly when dialing out, the open will not hang and you will be able to read() and write() the modem fd without DCD present. IF you have your UNIX set up correctly, it will drop DTR when the port is not open or in the process of being open. If you have your modem set up correctly, the modem will be reset by a DTR drop, thereby making it a moot point that your dialer has turned on result codes anyway. Your dialer could set ANY settings it wanted to without it effecting dial in, as long as the permanent modem settings were correct for dial in. Summary: set it up correctly. terry@wsccs
paulr@prapc2.UUCP (Paul Raulerson) (11/03/88)
In article <758@wsccs.UUCP> terry@wsccs.UUCP (Every system needs one) writes: >In article <889@vsi.COM>, friedl@vsi.COM (Stephen J. Friedl) writes: >> In article <5042@cbmvax.UUCP>, ditto@cbmvax.UUCP (Michael "Ford" Ditto) writes: >> > I disagree. Having "result codes" on a dialin modem on a Unix >> > system is a pretty stupid idea, for the above mentioned reason >> > (Modem sends "CONNECT" message to the computer ... computer thinks >> > "CONNECT" is a login name, etc.). >> >> It is certainly a drag to be stuck in upper case because >> RING was seen as a login. To combat this, we set our modems >> to give digit result codes instead of verbose ones; we've >> been quite pleased except that it's harder to debug the >> outgoing dialing... > >Urg. My suspicions confirmed. Nobody is reading anything anybody else >is posting. > >IF you have your modem set up correctly, it will not raise DCD until after >IF you have your UNIX set up correctly, all input prior to the modem raising >IF you open your port correctly when dialing out, the open will not hang and >IF you have your UNIX set up correctly, it will drop DTR when the port is not >Summary: set it up correctly. > terry@wsccs And if wishes were horses then beggars would ride :-) I notice that even though you are right, not much information is provided about *how* to "set it up properly". Since there are probably a zillion different "it"s around, ranging from AT's to Crays', I suspect that configuring a modem for dial in/dial out is not as simple everywhere as where you apparently reside. <grin>. Don't forget, some modems treat DTR a little differently than on Telebits or Hayes V series, or USR HST's. The common Hayes 1200 modem doesn't even have the &D commands for DTR control. Many many clone modems have neither dip switches or software commands to control DTR. Either you gots it or you don't. Notice please, that several implmentations of UNIX are far easier to deal with concerning modems and tty configuration than others. MicroPort on an AT is much easier to configure for modems than a Sun workstation. Maybe the folks concerned with 'standards' could think up some agreeable way to handle modem control on standard RS-232C configurations. (Did I really say that. standard and RS232 in the same sentance??) Yours, -- Paul Raulerson & Paul Raulerson & Associates +---------------------------+ Data/Voice: 1+215-275-2429 / 1+215-275-5983 | Always Aim To Please ... | Cis: 71560,2016 Bix: paulr | Always Aim High ... | UUCP: ...!rutgers!lgnp1!prapc2!paulr +---------------------------+
dave@onfcanim.UUCP (Dave Martindale) (11/04/88)
In my humble opinion, a modem that is configured correctly for answer use will obey the RS-232 specs: 1) if DTR is low, the modem will not answer 2) if DTR is dropped during a connection, the modem will hang up 3) the modem WILL NOT utter nonsense like "RING" or "CONNECT" on the Receive Data lines. That's what the Ring and Carrier pins are for. 4) the modem will not, under any circumstances, treat incoming or outgoing characters as a "command mode escape". If you are going to use the modem for dialout as well, you also need: 5) the modem should be able to return status information (RING, etc.) when in originate mode 6) If (5) is done by changing the internal modem state with commands, the modem must be reset to its "answer mode" state by the fall of DTR. Now, a Telebit Trailblazer can simultaneously be configured to be quiet during answer mode and verbose during originate mode. With most others, you make the modem default to quiet when reset, and tell it to be verbose as part of the dial string.
mmengel@cuuxb.ATT.COM (Marc W. Mengel) (11/08/88)
> In article <5042@cbmvax.UUCP>, ditto@cbmvax.UUCP (Michael "Ford" Ditto) writes: > > I disagree. Having "result codes" on a dialin modem on a Unix > > system is a pretty stupid idea, for the above mentioned reason > > (Modem sends "CONNECT" message to the computer ... computer thinks > > "CONNECT" is a login name, etc.). A good kluge for this particular problem is to make a login id called "connect" with no password, and a login shell of /bin/false (or some equally null program). Then the "login" as CONNECT logs in that user in upper case mode, but their login shell immediately exits... The only real problems there are if you have HUPCL set on the line, but make a program that turns off HUPCL, then exits, and make that CONNECT's login shell, and you're set.
ditto@cbmvax.UUCP (Michael "Ford" Ditto) (11/09/88)
In article <5042@cbmvax.UUCP>, I wrote: > Having "result codes" on a dialin modem on a Unix > system is a pretty stupid idea [ ... ] In article <2174@cuuxb.ATT.COM> mmengel@cuuxb.UUCP (Marc W. Mengel) writes: >A good kluge for this particular problem is [ ... ] (and several other people mentioned "solutions" for the "problem") My point was that Unix has the software support required to handle modems the way they were meant to work -- using EIA signals rather than ASCII strings sent by a microprocessor in the modem. There is no reason to have a dialin modem in verbose mode in the first place. -- -=] Ford [=- "The number of Unix installations (In Real Life: Mike Ditto) has grown to 10, with more expected." ford@kenobi.cts.com - The Unix Programmer's Manual, ...!sdcsvax!crash!elgar!ford 2nd Edition, June, 1972. ditto@cbmvax.commodore.com
les@chinet.chi.il.us (Leslie Mikesell) (11/09/88)
In article <5203@cbmvax.UUCP> ditto@cbmvax.UUCP (Michael "Ford" Ditto) writes: >My point was that Unix has the software support required to handle >modems the way they were meant to work -- using EIA signals rather >than ASCII strings sent by a microprocessor in the modem. There is >no reason to have a dialin modem in verbose mode in the first place. Where is the EIA signal to indicate 9600 vs. 4800 vs. 2400 vs. 1200 baud connection? Where is the software support for it? The real point is that modern microprocessor controlled modems have many more features than those available when the EIA signals were defined (although it is still reasonable to expect DCD to indicate a connection to a remote modem). ASCII strings are the only way to access the new features, so why hasn't the software support caught up. Why can't getty be told to match the speed of a connection? (I know something like this has been posted.) Why doesn't uucp's dialer pay attention to the CONNECT message and change speeds if necessary? Les Mikesell
ditto@cbmvax.UUCP (Michael "Ford" Ditto) (11/10/88)
In article <6916@chinet.chi.il.us> les@chinet.chi.il.us (Leslie Mikesell) writes: >Where is the EIA signal to indicate 9600 vs. 4800 vs. 2400 vs. 1200 >baud connection? Where is the software support for it? All gettys have some kind of autobaud support, and don't require anything nonstandard from the modem. > The real >point is that modern microprocessor controlled modems have many more >features than those available when the EIA signals were defined (although >it is still reasonable to expect DCD to indicate a connection to a >remote modem). ASCII strings are the only way to access the new features, Why do you think this? I have my doubts about using a new feature that was added in a way that does not work with commonly used software. I think that the more sophisticated modems get, the dumber they should look to the computer; fixed bit rate, completely transparent flow control, etc. All these things should be configurable, but they don't need to change "on the fly". If the modem is so smart, let IT worry about the details and just present a boring, old byte-stream to the computer, very much like a socket ... there are "connect" and "disconnect" concepts (CD/DTR), but that's about the only thing that the modem and computer need to communicate to each other aside from the "bytes". > Why doesn't uucp's dialer pay attention to the CONNECT message and >change speeds if necessary? When would it be necessary to change speeds when dialing? Why should a modem accept dialing commands at one speed and then suddenly start speaking another speed? Yes, I know there are modems that do this, but that doesn't mean it's a good idea. There are also very sophisticated modems that hide all the details of the connection and don't require any communication other than the common EIA signals. Dialing control, of course, is another story entirely... -- -=] Ford [=- "The number of Unix installations (In Real Life: Mike Ditto) has grown to 10, with more expected." ford@kenobi.cts.com - The Unix Programmer's Manual, ...!sdcsvax!crash!elgar!ford 2nd Edition, June, 1972. ditto@cbmvax.commodore.com
les@chinet.chi.il.us (Leslie Mikesell) (11/11/88)
In article <5212@cbmvax.UUCP> ditto@cbmvax.UUCP (Michael "Ford" Ditto) writes: > >All gettys have some kind of autobaud support, and don't require anything >nonstandard from the modem. Not all of them work, though (AT&T's Unix PC comes to mind) and how many will print the "login" message at the right speed the first try? Does your terminal like the random garbage you get from characters sent at the wrong speed? >>... ASCII strings are the only way to access the new features, > >Why do you think this? I have my doubts about using a new feature that >was added in a way that does not work with commonly used software. I think this because it has been this way since hays started selling an affordable 1200 baud modem back in 1980 or so. How long is a feature "new"? >I think that the more sophisticated modems get, the dumber they should look >to the computer; fixed bit rate, completely transparent flow control, etc. >All these things should be configurable, but they don't need to change "on >the fly". If the modem is so smart, let IT worry about the details and No argument here, except that many computers do not observe the CTS/DSR leads (AT&T's 3B2 comes to mind) and xon/xoff flow control is not transparent. Also buffering in the modem may interfere with protocol timing and makes it extremely difficult to tell if data has gotten to the end device. For example, if you want to print something on a remote teletype (I do a lot of this), you need to know if the connection is dropped before the end of data is sent. If the modem buffers, you don't even know when it is safe to hang up the line. Then there is the question of where xon/xoff flow control should happen if the remote end needs it. If the modem passes it through to the host, the buffered data will still be sent - if the modem handles xon/xoff then you need a way to turn the mode off for binary file transfers. >> Why doesn't uucp's dialer pay attention to the CONNECT message and >>change speeds if necessary? > >When would it be necessary to change speeds when dialing? Why should >a modem accept dialing commands at one speed and then suddenly start >speaking another speed? Yes, I know there are modems that do this, >but that doesn't mean it's a good idea. It's a better idea than making the connection and not being able to do anything, which is what happens now. A little extra code in the dialing routine would be all it takes to fix it, and if it were controlled by tokens in the dialer string it wouldn't bother the EIA purists. Les Mikesell
berger@clio.las.uiuc.edu (11/11/88)
There's a perfectly good reason to have a dialin modem in verbose
mode. Some of us can't afford extra serial ports and modems, and
have to use the same modem for dial in and dial out. We do it all
the time with microcomputers, so it doesn't have to be kludgy.
Mike Berger
Department of Statistics
University of Illinois
berger@clio.las.uiuc.edu
{convex | pur-ee}!uiucuxc!clio!bergerrwhite@nusdhub.UUCP (Robert C. White Jr.) (11/11/88)
in article <6916@chinet.chi.il.us>, les@chinet.chi.il.us (Leslie Mikesell) says: > Xref: nusdhub comp.dcom.modems:1126 comp.sys.att:1681 > Where is the EIA signal to indicate 9600 vs. 4800 vs. 2400 vs. 1200 > baud connection? Where is the software support for it? The real We call the EIA signal to indicate baud "receive detect." When this signal lead is examined over time and compared with a known "base state series" (you and I call them characters) one can easily determine baud rate (and other settings). This procedure is called "auto-bauding" and has been successfully used for years. The software support for same can be found in /etc/gettydefs and /etc/gettys (amoung other places). > point is that modern microprocessor controlled modems have many more > features than those available when the EIA signals were defined (although > it is still reasonable to expect DCD to indicate a connection to a > remote modem). ASCII strings are the only way to access the new features, Wrong! DCD is *supposed* to indicate connection to a *remote device* many peices of software are so broken that they use DCD to detect the modem. DSR (Data Set Ready) is intended to detect the presence of a "ready" "data set" (you know, a modem) and DTR (Data Terminal Ready) the computer or "terminal" (e.g. the terminal endpoint on any given leg of the circut. . . instead of "terminal" in the common usage). Some old UNIX System implementations were broken in this respect, but almost all of them have since fixed this. > so why hasn't the software support caught up. Why can't getty be told > to match the speed of a connection? (I know something like this has been > posted.) Why doesn't uucp's dialer pay attention to the CONNECT message and > change speeds if necessary? getty doesn't need this behavior. To implement it would needlessly make a simple opperation much more complex. Especially when you consider that the many different "connect messages" produced by the various types of modems. I have seen dialers (on UNIX Systems) which attempt this, and even tried to manage a few of them, but when you get a hundred or more modems going, the space usage does not justify the inconvience. (yes, I meant those words just that way.) If you cant live through the extra five characters at 9600 baud, you must really be tense! ;-) > Les Mikesell Less, please study the specs of RS-232C and later specs like RS-442 et. al. before complaining to much. The larger specs contain the types of direct-wire protocols you want. They are also quite a lot more expensive to fully implement. Not to many companies or individuals feel the expense is worth the features for the kind of environment you are talking about. Remember the KISS principle "Keep It Simple Stupid" becuase simple is often more reliable. Rob.
rwhite@nusdhub.UUCP (Robert C. White Jr.) (11/12/88)
in article <18600068@clio>, berger@clio.las.uiuc.edu says: > Nf-ID: #R:cbmvax.UUCP:5203:clio:18600068:000:405 > Nf-From: clio.las.uiuc.edu!berger Nov 10 15:25:00 1988 > > > There's a perfectly good reason to have a dialin modem in verbose > mode. Some of us can't afford extra serial ports and modems, and > have to use the same modem for dial in and dial out. We do it all > the time with microcomputers, so it doesn't have to be kludgy. Nothing personal, but I don't consider this to be anything even vaguely near a "good reason" for any such thing. Properly defined dialing strings in your uucp system will allow you to use the built in dialing system (cu, uucp, whatever) without ever leaving your modem in "verbose mode" beyond the scope of the actual dial. For example (in HDB for a Hayes [from memory if I make a mistake;-)]): \rATZ\d\r\rATE1V1X1\r\rAT\r OK-ATE1V1X1\rAT\r-OK ATD\T;V0X0O CONNECT to whit; reset modem, set verbose mode and demand acknowlege, if no acknowlege try to force acknowlege again-or fail, Dial number but do not go online-reset verbose mode off-then go online, wait for connect. This is ugly, and there are better ways which I don't have at hand right now, but it is not *that* dificult to do. Really good modems even have a dialer which you have to "wake up" with a code, which goes back to sleep if (1) you make a connection or (2) you leave the set idle for a few seconds [like 20+] or (3) you cycle DTR. This latter bit being the "best" behavior. Verbose mode is an "always off unless the operator really askes for it" type of function. this is true for UNIX systems, PCs, Data-Switches (all types), Printers, Data collection devices, and etc. "Do it right, or live with the wrongness" Rob.
dtynan@sultra.UUCP (Der Tynan) (11/12/88)
In article <6924@chinet.chi.il.us>, les@chinet.chi.il.us (Leslie Mikesell) writes: > In article <5212@cbmvax.UUCP> ditto@cbmvax.UUCP (Michael "Ford" Ditto) writes: > >When would it be necessary to change speeds when dialing? Why should > >a modem accept dialing commands at one speed and then suddenly start > >speaking another speed? Yes, I know there are modems that do this, > >but that doesn't mean it's a good idea. > > It's a better idea than making the connection and not being able to > do anything, which is what happens now. A little extra code in > the dialing routine would be all it takes to fix it, and if it were > controlled by tokens in the dialer string it wouldn't bother the > EIA purists. > > Les Mikesell Not true. It's not the dialer that makes this decision. I know, because I ran into this VERY problem last night. I'd make a call @ 2400baud, and for some reason get dumped on a rotary which would only answer @ 1200. So, the modem sends back a CONNECT 1200, and now changes it's speed. The dialer program returns SUCCESS to uucico, which then cannot access the system, because it thinks the line speed is 2400. So, it fails while executing the 'chat' script. As if this wasn't bad enough, when uucico fails to make the connection, it once again calls the dialer to hang up the phone. Well, guess what. The modem won't respond to the '+++' escape, because it's talking 1200 baud now. How autocratic! Anyway, the line stays off-hook, until the other end times out (if ever!). At which stage, the modem returns NO CARRIER. Like I cared at that point. Don't tell me to fix uucico, because the problem runs deeper than that. Let's say that I want to transfer X-windows from UUNET. OK, so lets say for arguments sake, it is 10Mb of code. This is 12 hours of transfer at 2400 baud. Or, $120 in UUNET fees. Now, if I get dumped onto a 1200 baud line (or worse, a 300 baud line!), I'd prefer that uucico forget it, than double the transfer fee. If anything, this should be an S-register option. - Der -- dtynan@sultra.UUCP (Dermot Tynan @ Tynan Computers) {mips,pyramid}!sultra!dtynan --- God invented alcohol to keep the Irish from taking over the planet ---
les@chinet.chi.il.us (Leslie Mikesell) (11/13/88)
In article <2653@sultra.UUCP> dtynan@sultra.UUCP (Der Tynan) writes: >Not true. It's not the dialer that makes this decision. I know, because I >ran into this VERY problem last night. I'd make a call @ 2400baud, and for >some reason get dumped on a rotary which would only answer @ 1200. So, the >modem sends back a CONNECT 1200, and now changes it's speed. The dialer >program returns SUCCESS to uucico, which then cannot access the system, because >it thinks the line speed is 2400. It is possible to do slightly better here by making separate dialer scripts for 1200 and 2400 baud. If you make the chat script expect 1200 or 2400 in the connect string it will at least give up fairly quickly but you are still going to pay for a call and not transfer any data. Most of my traffic is time-sensitive and I would prefer to have it go at any speed the other system will accept instead of failing, though. That can be accomplished at the expense of a second call by making duplicate entries in the Systems file for 1200 and 2400 baud. Les Mikesell
les@chinet.chi.il.us (Leslie Mikesell) (11/13/88)
In article <1249@nusdhub.UUCP> rwhite@nusdhub.UUCP (Robert C. White Jr.) writes: >> There's a perfectly good reason to have a dialin modem in verbose >> mode. > >Nothing personal, but I don't consider this to be anything even >vaguely near a "good reason" for any such thing. Most reasonable modems deliver their verbose messages *before* asserting the CD line, so unix programs will never see them unless they have specifically opened the line with O_NDELAY and set CLOCAL in the termio flags (SysV) or you have set the modem to always assert CD. Before SysVr3.1 and the addition of the \M and \m dialer codes to control CLOCAL a fake CD signal was required to allow dialing at all - with current releases there is no excuse for it. Les Mikesell
chip@ateng.ateng.com (Chip Salzenberg) (11/15/88)
According to dtynan@sultra.UUCP (Der Tynan): [Complaining because of modem fallback from 2400 to 1200 on uunet call] >Now, if I get dumped onto a 1200 baud line (or worse, a 300 baud >line!), I'd prefer that uucico forget it, than double the transfer fee. >If anything, this should be an S-register option. Read The Friendly Manual. It *is* an S-register option. Example L-devices entries for BSD UUCP: ACU ttya7 unused 2400 hayes2400tone "" ATS34=0\r\d\c ACU ttya7 unused 1200 hayes2400tone Assigning zero to S34 inhibits automatic fallback to 1200. -- Chip Salzenberg <chip@ateng.com> or <uunet!ateng!chip> A T Engineering Me? Speak for my company? Surely you jest! Beware of programmers carrying screwdrivers.
cks@ziebmef.uucp (Chris Siebenmann) (11/24/88)
In article <5212@cbmvax.UUCP> ditto@cbmvax.UUCP (Michael "Ford" Ditto) writes: ... >Why do you think this? I have my doubts about using a new feature that >was added in a way that does not work with commonly used software. I >think that the more sophisticated modems get, the dumber they should look >to the computer; fixed bit rate, completely transparent flow control, etc. The problem with this is that at different baud rates the user may wish drastically different behavior from programs, depending on the baud rate she is at. Consider just two examples; the amount of text on the initial page of an article rn shows, and the special low-speed interactive search mode of GNU Emacs. Things that appear perfectly reasonable to the computer at baud rate M may be highly undesirable or even impossible at the connection's true baud rate of N (consider a status display program who's screen updates simply push out more characters per second than N can ever transmit in one second). The need for this sort of information won't go away; since the modem can provide it and the computer recognize it, why not use it? -- "The hell I will!" WHAK! "Surpise, kid -- they retract! Try that again and I'll kick you back. With my claws." Chris Siebenmann uunet!utgpu!{ontmoh!moore,ncrcan}!ziebmef!cks cks@ziebmef.UUCP or .....!utgpu!{,ontmoh!,ncrcan!brambo!}cks
ditto@cbmvax.UUCP (Michael "Ford" Ditto) (11/27/88)
In article <1988Nov24.004706.7463@ziebmef.uucp> cks@ziebmef.UUCP (Chris Siebenmann) writes: [ in reply to discussion about the computer knowing the "real" baud rate of a modem connection ] > > The problem with this is that at different baud rates the user may >wish drastically different behavior from programs, This is true, but is a more general problem than the modem issue. Such programs must base their idea of the user's communication rate on something more than the rate of the "last hop" of the connection. Consider this example: I am running a terminal program on my Amiga which can display characters at a nominal rate equivalent to 9600 bps. It is communicating via a serial link at 19200 baud to a Unix machine with a built-in 1200 baud modem. The modem places a call to a terminal server which connects via ethernet (10Mbps) to a Unix machine which believes the connection is at 38400 baud. Now, does it make any difference whether the answering modem talks to its host (the terminal server) at 1200, 300, or 38400 baud? And what about the on-board modem that will speak 1200bps to the phone line regardless of whether the port is ioctl'd to 1200 or 9600 baud. Added to all the other unknowns is the existence of devices with data-dependent throughput, like modems with data compression. I think the best that can be hoped for in this (increasingly common) type of situation is for all the communication links to be as "dumb" as possible and just provide a reliable, flow controlled 8-bit connection, and for the "host" to be directly told what rate to "pretend" the connection has (1200bps in the example). Of course, if it were practical for the host to automatically figure out the rate of the "bottleneck point" of the connection, that might be a good idea. -- -=] Ford [=- "The number of Unix installations (In Real Life: Mike Ditto) has grown to 10, with more expected." ford@kenobi.cts.com - The Unix Programmer's Manual, ...!sdcsvax!crash!elgar!ford 2nd Edition, June, 1972. ditto@cbmvax.commodore.com