nelson@sun.soe.clarkson.edu (Russ Nelson) (12/18/90)
Is there a way to convince the tty2A driver to automagically change baud rates on Xenix 2.3.2? My boss just found out that you have to send a break, and he's not happy about it. Is there some configuration option I haven't found, or is there an alternative tty driver? -- --russ (nelson@clutx [.bitnet | .clarkson.edu]) FAX 315-268-7600 It's better to get mugged than to live a life of fear -- Freeman Dyson I joined the League for Programming Freedom, and I hope you'll join too.
neal@mnopltd.UUCP (12/19/90)
->Is there a way to convince the tty2A driver to automagically change baud
->rates on Xenix 2.3.2? My boss just found out that you have to send a break,
->and he's not happy about it. Is there some configuration option I haven't
->found, or is there an alternative tty driver?
Sheesh, yer boss better develop some flexibility. He's gonna have a cow when
he has to deal with awk....
What baud rates are you rolling between? If I remember the origin of the
break code, at certain speeds (like 9600+) a character transmitted is not
visible to a receiver at certain other speeds. (like 1200) Basic math.
If we are talking modems, then why change baud rates? Spend the $50 and get
him a 2400 baud. If you are using a higher speed modem, lock the interface.
Enough speculation. 'Splain yourself.
------------------------------------------------------------------------------
Neal Rhodes MNOP Ltd (404)- 972-5430
President Lilburn (atlanta) GA 30247 Fax: 978-4741
emory!mnopltd!neal
------------------------------------------------------------------------------mikes@iuvax.cs.indiana.edu (Michael Squires) (12/20/90)
In article <158@mnopltd.UUCP> gatech!stiatl!mnopltd!neal writes: > >->Is there a way to convince the tty2A driver to automagically change baud >->rates on Xenix 2.3.2? Buy a different modem. I've used the ARK/Paradyne 24K, USR HST or Dual Standard, and Telebits with the comm port locked and the modem set to do speed changes. This leads to much increased work for the sysadmin but less work for people who don't know how to send BREAKs (or what a BREAK is, for that matter). The main problem of this approach (aside from the additional cost, as modems that do this reliably tend to be more expensive) is that the line speed seen by software is wrong - it's always the highest possible. When the port is locked at 38.4K and the login is at 300 this can lead to substantial errors... -- Mike Squires (mikes@iuvax.cs.indiana.edu) 812 855 3974 (w) 812 333 6564 (h) mikes@iuvax.cs.indiana.edu 546 N Park Ridge Rd., Bloomington, IN 47408 Under construction: mikes@sir-alan@cica.indiana.edu
nelson@sun.soe.clarkson.edu (Russ Nelson) (12/25/90)
In article <158@mnopltd.UUCP> neal@mnopltd.UUCP writes:
->Is there a way to convince the tty2A driver to automagically
->change baud rates on Xenix 2.3.2? My boss just found out that
->you have to send a break, and he's not happy about it. Is there
->some configuration option I haven't found, or is there an
->alternative tty driver?
Sheesh, yer boss better develop some flexibility. He's gonna have
a cow when he has to deal with awk....
The problem is that I get random users calling into the BBS, and it's not
practical to tell them that they have to press break, nor can I suggest
that they get a 2400 baud modem. My boss is on my case about it because
*he* tried it, and he couldn't get in. His attitude is that if *he*
can't get in, how's J. Random User (who knows as much about the system
as he does) going to get in?
Another part of the problem is that we switched from a MS-DOG BBS to a Xenix
BBS, and now it won't auto-switch baud rates. C'mon, Unix fans, you're not
going to tell me that Unix loses out over MS-LOSS, are you?
--
--russ (nelson@clutx [.bitnet | .clarkson.edu]) FAX 315-268-7600
It's better to get mugged than to live a life of fear -- Freeman Dyson
I joined the League for Programming Freedom, and I hope you'll join too.news@m2xenix.psg.com (Randy Bush) (12/26/90)
How to avoid having to hot BREAK to cycle baud rates in getty :
Don't cycle baud rates!
Lock the computer-modem baud rate at the max your modem and computer can
handle, and tell gettydefs that rate.
I have the hacked dialTBIT etc. here for modem init and dialout with TeleBit
and Intel. I can't send the whole thing, as it is dreived from copyrighted
work. But I can send diffs.
--
..!{uunet,qiclab,intelhf,bucket}!m2xenix!newsdavidsen@sixhub.UUCP (Wm E. Davidsen Jr) (12/26/90)
In article <134@mixcom.UUCP> sysop@mixcom.UUCP (System Operator) writes: | 3. If you are using SCO UNIX 3.2.2, get the getty from 3.2.0. | The 3.2.0 getty will interpret a RETURN the same as a | break, causing it to cycle through the baud rates specified | in gettydefs. This feature was "fixed" (removed) in 3.2.2. Would someone from SCO like to reply to this? I have some comments, but I don't want to bash SCO until they have a chance to comment on this. Of course if they say that I should educate my users (as they did on the Xenix versions of the problem) I will ask just how to do that be fore they get a connection over which I can send data> -- bill davidsen - davidsen@sixhub.uucp (uunet!crdgw1!sixhub!davidsen) sysop *IX BBS and Public Access UNIX moderator of comp.binaries.ibm.pc and 80386 mailing list "Stupidity, like virtue, is its own reward" -me
bill@bilver.uucp (Bill Vermillion) (12/27/90)
In article <134@mixcom.UUCP> sysop@mixcom.UUCP (System Operator) writes: >SOAP BOX ON >Hey UNIX vendors! This is (almost) 1991! >Wake up and smell the coffee! I want a >getty for hardwired terminals and one for >modems that will use the modem's abilities to >report the baud rate. Also, the modem getty >should have the ability to send an init string >to the modem. In a time of smart hardware, >why is the software so stupid? >SOAP BOX OFF Well, at one time we could detect speed change, and it was done in hardware. Pin 12 low was 300 and pin 12 high was 1200. Then along came 2400, and I saw two different implmentations arrive. I saw two modems from AT&T and NEC that added a second pin. So now we could detect 4 baud rates via hardware. At the same time Hayes said, from now on pin 12 high shall be 2400, pin 12 low will not be 2400. And right then and there the hardware solution broke. I was using hardware detect up until that time and it worked flawlessly. Now we do have another problem. The v.22bis specs (2400 bps) says that if the line gets too bad, you step back to 1200. So the modems now move back to 1200, while the software stays at 2400. So what do you get - a screen full of garbage, or a disconnect if you are doing an error checking file protocol. If hardware speed checking had been continued it would have been easier. Now the only real way to make sure you are talking properly is with your solution to the previous questioner, modems that used fixed dce/dte rates. Of course that means good hardware flow control, and a lot of systems don't handle that very gracefully. I used Hayes products from the time Dennis was building 300 bps full size S-100 boards in his garage. I haven't forgiven them for breaking the hardware speed standards. -- Bill Vermillion - UUCP: uunet!tarpit!bilver!bill : bill@bilver.UUCP
kabra437@pallas.athenanet.com (Ken Abrams) (12/27/90)
In article <NELSON.90Dec24233400@image.clarkson.edu> nelson@clutx.clarkson.edu (aka NELSON@CLUTX.BITNET) writes: > > ->Is there a way to convince the tty2A driver to automagically > ->change baud rates on Xenix 2.3.2? My boss just found out that > ->you have to send a break, and he's not happy about it. Is there > ->some configuration option I haven't found, or is there an > ->alternative tty driver? > >The problem is that I get random users calling into the BBS, and it's not >practical to tell them that they have to press break, nor can I suggest >that they get a 2400 baud modem. My boss is on my case about it because As usual, having the whole story might change the answer (opinion) that one receives back. There IS an alternative hardware solution. Replace the modem at the host with one that is buffered so you can set the Xenix baud rate at a fixed value and leave it there. There are a lot of 2400 MNP modems on the market that use a fixed baud rate of 9600. There are also several 9600 models that use a fixed rate of 19,200 or 38,400. The latter is probably your best long term solution but will set you back a few more bucks. The USR Dual Standard and Hayes Ultra come to mind (and they both are in the $700 -> $1K price range) but there are others too. This solution allows the host to always use a fixed rate in talking to the modem and the modem negotiates the final (actual) baud rate with the device at the far end. If your application is for general public access BBS service, the USR modems seem to the most popular (and they offer a special price break for BBS operators). -- ======================================================== Ken Abrams uunet!pallas!kabra437 Illinois Bell kabra437@athenanet.com Springfield (voice) 217-753-7965
ronald@robobar.co.uk (Ronald S H Khoo) (12/28/90)
kabra437@pallas.UUCP (Ken Abrams) writes: > There IS an alternative hardware solution. Replace the modem at the host > with one that is buffered so you can set the Xenix baud rate at a fixed > value and leave it there. Genrally speaking, this is good advice. It's becoming more and more important too, as the data compression in the modems renders the relationship between the modem carrier speed and the DTE speed more fuzzy. However, the caveat here is that you *absolutely* need hardware flow control between the modem and the host, particularly at the higher speeds. Using xon/xoff flow control just doesn't hack it because it interferes with the user's use of it for paging, and anyway emacs switches it off. Now, this presents a problem. Many intelligent serial ports just don't support hardware flow control, and worse still SCO's own standard serial driver's flow control logic is wrong, in that xon/xoff flow control and cts/rts flow control interfere with each other(*). Worse still, if you run any program that uses the v7 TIOCSETP calls, they *force off* the ctsflow and rtsflow flags. However, if you use an intelligent serial port with a driver that flow controls properly, and can arrange not to run programs that use the v7 compatibility ioctls, then the result is very good. (I used to run a commercial BBS in the UK that does just that with Hayes V series modems, and a Specialix serial adaptor. Actually, for hysterical reasons, I only locked the speed interface when error correction was active (and that's when hardware flow control becomes nearly mandatory anyway) but I matched baud rates when error correction wasn't active -- as you can guess, I made no use of getty -- the modems were spoken to by a severely hacked copy of the SCO dialer program -- so I could parse the CONNECT message to determine what baud rate to speak at, and to determine what kind of error correction/data compression protocols were active) (*) It's easy to see where the interference goes wrong. Make a call over a modem link where the modem carrier speed is lowish (say 1200 or 2400, but where the the DTE speed is 19200 or something. Now make sure that ixon and ctsflow are set, then do something like yes "the quick brown fox jumps over the lazy dog" to generate lots of output. If you look at the modem lights, you will see that CTS flow control works beautifully, and no characters would be lost. Now type a ^S at the session, and output will stop, but when you type ^Q to restart the output, CTS flow control no longer works and you lose tons of characters. It looks like they've overeconomised by just using one flag for both sorts of output flow control, when you do really need two, as they are completely orthogonal. Specialix's serial driver gets this right. I'd like to hear who else does. -- ronald@robobar.co.uk +44 81 991 1142 (O) +44 71 229 7741 (H)
larry@tapa.uucp (Larry Pajakowski) (12/29/90)
As was pointed out some time ago try setting the gettydefs file to go from the highest speed you need to the lowest instead of the default low to high. I've had very good results with just hitting CR until I get an intelligible prompt. Larry
dhesi%cirrusl@oliveb.ATC.olivetti.com (Rahul Dhesi) (01/03/91)
In <NELSON.90Dec24233400@image.clarkson.edu> nelson@sun.soe.clarkson.edu (Russ Nelson) writes: >The problem is that I get random users calling into the BBS, and it's not >practical to tell them that they have to press break... My admittedly limited experience with setting of data rates suggests that most hardware interfaces will detect a "framing error" when the user types at the wrong data rate. A framing error is all that the software needs to switch to a different data rate. In fact, from the device driver's point of view, a "break" and a "framing error" should be identical. I believe this works for Microport System V/AT on standard AT hardware, and for 4.3BSD on a VAX using dz-11 serial port hardware. If for some reason just typing carriage return doesn't cause the driver to switch to a different data rate (before the user has logged in), then your hardware, or the SCO Xenix device driver, is at fault. I would blame the specific hardware or software, not UNIX in general. If the hardware or software does not correctly detect a framing error, then it probably won't detect a break either. All this assumes, of course, that the configuration files for the dial-up ports have entries such that each entry has a pointer to the next entry for a differnt data rate. E.g., you might cycle through 300 -> 1200 -> 2400 -> 300. This will make the initial getty process cycle through these data rates, switching each time it sees a framing error. -- Rahul Dhesi <dhesi%cirrusl@oliveb.ATC.olivetti.com> UUCP: oliveb!cirrusl!dhesi