davidg%aegis.or.jp@kyoto-u.ac.jp (Dave McLane) (03/26/91)
But while we're talking about USRobotics that's always puzzled me: I take it that they are used for UNIX where everything has to be set into the RAM with AT&W so UNIX doesn't allow any modem init each call (as far as I know). But the USR DS I have will start it's answer tone cycle at the speed of the previous caller. That is, if somebody linked at, say, 1200 BPS and logs off, the next caller gets an answer tone sequence of 1200->300->HS->9600->2400->1200... Thus if the next caller wants to link at, say, 2400 BPS, they must lock their speed at 2400 BPS (a feature not available on a lot of the modems for sale here) or the calling modem changes speed to the first answer tone (1200) and there is a mismatch. Two questions come from this: My solution for this is has always been to re-init the modem to the highest speed with at least an ATH command so the answer tones always go from high to low. But this isn't possible with UNIX, is it? Somebody has suggested that it is only Japanese-made modems that change speed on call as well as answer. The USRobotics I have doesn't change on call but all the Japanese modems I've tested do (Aiway, Omron, Epson). What about other US-made modems, do they change speed on call as well as on answer? --Dave
tnixon@hayes.uucp (03/27/91)
In article <22HgZ1w163w@aegis.or.jp>, davidg%aegis.or.jp@kyoto-u.ac.jp (Dave McLane) writes: > Somebody has suggested that it is only Japanese-made modems that > change speed on call as well as answer. The USRobotics I have > doesn't change on call but all the Japanese modems I've tested do > (Aiway, Omron, Epson). What about other US-made modems, do they > change speed on call as well as on answer? To the best of my knowledge, virtually ALL modems will, when being used to originate a call, change speeds to match the capabilities of the answering modem, unless they've been specifically configured to disable this feature. All Hayes modems do. Older (pre-V-series) Hayes modems behaved like your USR -- once they answered a call at a lower speed, that speed became the maximum for future calls if the modem didn't receive a command from the DTE at a higher speed in the meantime. We learned, however, about systems like Unix and other applications that CAN'T issue commands to the modem between calls, and so changed the behavior of our modems so that between calls they switch back to the speed of the last AT command issued rather than the speed at which the last call connected. Many other manufacturers have done the same thing, but not all. Of course, with the V-series modems, you can set an S-register to specify the maximum connect speed rather than it being dependent on the AT command speed. -- Toby Nixon, Principal Engineer | Voice +1-404-840-9200 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
davidg%aegis.or.jp@kyoto-u.ac.jp (Dave McLane) (03/27/91)
tnixon@hayes.uucp writes: > To the best of my knowledge, virtually ALL modems will, when being > used to originate a call, change speeds to match the capabilities of > the answering modem, unless they've been specifically configured to > disable this feature. All Hayes modems do. Thanks for the info. > Older (pre-V-series) Hayes modems behaved like your USR -- once they > answered a call at a lower speed, that speed became the maximum for > future calls if the modem didn't receive a command from the DTE at a > higher speed in the meantime. We learned, however, about systems > like Unix and other applications that CAN'T issue commands to the > modem between calls, and so changed the behavior of our modems so > that between calls they switch back to the speed of the last AT > command issued rather than the speed at which the last call > connected. Many other manufacturers have done the same thing, but > not all. Of course, with the V-series modems, you can set an > S-register to specify the maximum connect speed rather than it being > dependent on the AT command speed. If so, then I can't use my USR (or any modem that behaves in a similar fashion). --Dave
root@zswamp.fidonet.org (Geoffrey Welsh) (03/28/91)
Dave McLane (davidg%aegis.or.jp@kyoto-u.ac.jp ) wrote: >But the USR DS I have will start it's answer tone cycle at >the speed of the previous caller. ... unless it receives a command at another baud rate. >My solution for this is has always been to re-init the modem >to the highest speed with at least an ATH command so the answer >tones always go from high to low. A simple AT<cr> will do. -- UUCP: watmath!xenitec!zswamp!root | 602-66 Mooregate Crescent Internet: root@zswamp.fidonet.org | Kitchener, Ontario FidoNet: SYSOP, 1:221/171 | N2M 5E6 CANADA Data: (519) 742-8939 | (519) 741-9553 The mile is traversed not by a single leap, but by a procession of coherent steps; those who insist on making the trip in a single element will be failing long after you and I have discovered new worlds. - me
davidg%aegis.or.jp@kyoto-u.ac.jp (Dave McLane) (03/29/91)
root@zswamp.fidonet.org (Geoffrey Welsh) writes: > Dave McLane (davidg%aegis.or.jp@kyoto-u.ac.jp ) wrote: > > >But the USR DS I have will start it's answer tone cycle at > >the speed of the previous caller. > > ... unless it receives a command at another baud rate. Yes, I know. I believe I already mentioned that in my orginal post. > >My solution for this is has always been to re-init the modem > >to the highest speed with at least an ATH command so the answer > >tones always go from high to low. > > A simple AT<cr> will do. Yes, exactly; on a BBS where you can do such. But the question was how to do this with UNIX? Specifically ISC UNIX R3.2 V2.2. --Dave
jseymour@medar.com (James Seymour) (03/29/91)
In article <B6DLZ3w163w@aegis.or.jp> davidg%aegis.or.jp@kyoto-u.ac.jp (Dave McLane) writes: > >Yes, exactly; on a BBS where you can do such. But the question >was how to do this with UNIX? Specifically ISC UNIX R3.2 V2.2. Check for something like this: the MultiTech modems we use here have a nifty setting that causes the modem to re-initialize to the RAM settings when loss of DTR is seen. (It happens to be AT&D3 - &D<n> is all the DTR options.) We set the modems to the highest baud rate we want them to answer at (i.e.: maximum smoke :-)) and when the login is terminated, DTR drops and resets the modem to that, regardless of what the login was at. Same for when the modem is used for call-out, as with 'cu'. Interestingly enough, when I mentioned to MultiTech that that seemed awfully handy for a UNIX/Xenix system, I was told they had added that option at the specific request of a UNIXoid. I seem to recall from earlier postings that you're not using MultiTechs, but maybe whatever you are using has a similar thing. Hope this helps. -- Jim Seymour | Medar, Inc. ...!uunet!medar!jseymour | 38700 Grand River Ave. jseymour@medar.com | Farmington Hills, MI. 48331 CIS: 72730,1166 GEnie: jseymour | FAX: (313)477-8897
root@zswamp.fidonet.org (Geoffrey Welsh) (03/30/91)
Dave McLane (davidg%aegis.or.jp@kyoto-u.ac.jp ) wrote: > A simple AT<cr> will do. >Yes, exactly; on a BBS where you can do such. But the >question >was how to do this with UNIX? Specifically ISC UNIX R3.2 >V2.2. I've long been of the opinion that getty needs a serious rewrite. For instance, my SCO Unix feed has both 2400 and PEP lines, but my login script must send a number of BREAK signals to tell uugetty to toggle baud rates. The number of BREAKs needed depends on many things, including line noise at connect. Only recently have I managed to get a decent uucico working with my brain-dead PC software, allowing me to put conditional sends into my login scripts(!) Even so, the time it takes for getty to react to a break varies, so I must put in long login chat timeouts... unfortunately, in many cases, it would be to my advantage to reduce those timeouts if at all possible (e.g. no point waiting a minute to figure out that CARRIER isn't going to show up if the system's busy)... all of this would be solved if getty had the ability to recognize connect strings sent by the modem. To bring our gripes together, it would be nice if getty could re-initialize the modem periodically using a user- (oops, sysadmin-) configurable string, much as the Mess-DOS BBS programs currently do. Geoff P.S.: Incidentally, I was surprised and pleased to read a few months back in the SCO *ix docs that dialout scripts can now be told to watch for baud rates reported in the CONNECT string. These scripts, though not as efficient as dialer binaries, seem a *lot* friendlier and would be by far my choice when configuring a new modem. Heck, *patching* DialTBit.c was hell... -- UUCP: watmath!xenitec!zswamp!root | 602-66 Mooregate Crescent Internet: root@zswamp.fidonet.org | Kitchener, Ontario FidoNet: SYSOP, 1:221/171 | N2M 5E6 CANADA Data: (519) 742-8939 | (519) 741-9553 The mile is traversed not by a single leap, but by a procession of coherent steps; those who insist on making the trip in a single element will be failing long after you and I have discovered new worlds. - me
davidg%aegis.or.jp@kyoto-u.ac.jp (Dave McLane) (03/30/91)
jseymour@medar.com (James Seymour) writes: > In article <B6DLZ3w163w@aegis.or.jp> davidg%aegis.or.jp@kyoto-u.ac.jp (Dave M > > > >Yes, exactly; on a BBS where you can do such. But the question > >was how to do this with UNIX? Specifically ISC UNIX R3.2 V2.2. > > Check for something like this: the MultiTech modems we use here have a > nifty setting that causes the modem to re-initialize to the RAM settings > when loss of DTR is seen. (It happens to be AT&D3 - &D<n> is all the I guess I didn't make the point of my query clear. I *know* how to set up a modem to re-initialize to the RAM settings so when the DTR goes down it's all set to go. But I have a USRobotics DS ($1,000) and two made-in-Japan Omrons ($300 each) that don't allow enough parameters to be stored in the RAM; they *must* be reinitialzed every call to get them to send the tones from highest speed to lowest. If I can't re-init them for dialin (initializing for dialout is no problem) with UNIX it means I have to get modems that do. Technically trivial but an economic burden. From the replies that I've gotten (here and in mail) I take it that you can't re-init a modem for dialin under ISC UNIX. I thought so, but I wanted to make sure I hadn't overlooked something before I shell out for new modems. Unless somebody has something new to add, I think that answers the question: for UNIX, you have to use a modem who initialization for dial-in can be stored wholly in the modem (via RAM or DIP switches). Thanks for the help everybody, --Dave McLane <davidg%aegis.or.jp@kyoto-u.ac.jp> ==== The Aegis Society ============================================= Minami Hirao 1-6, Imazato The content and process of Nagaokakyo-shi, Kyoto-fu, 617 Japan international/cultural Tel: +81-75-951-1168 Fax: +81-75-957-1087 communication. ====================================================================
jhood@alchemy.tcnet.ithaca.ny.us (John Hood) (03/31/91)
davidg%aegis.or.jp@kyoto-u.ac.jp (Dave McLane) writes: > I *know* how to set up a modem to re-initialize to the RAM settings > so when the DTR goes down it's all set to go. But I have a > USRobotics DS ($1,000) and two made-in-Japan Omrons ($300 each) > that don't allow enough parameters to be stored in the RAM; they > *must* be reinitialzed every call to get them to send the tones > from highest speed to lowest. If I can't re-init them for dialin > (initializing for dialout is no problem) with UNIX it means I have > to get modems that do. Technically trivial but an economic burden. > > From the replies that I've gotten (here and in mail) I take it > that you can't re-init a modem for dialin under ISC UNIX. I thought > so, but I wanted to make sure I hadn't overlooked something before > I shell out for new modems. > > Unless somebody has something new to add, I think that answers the > question: for UNIX, you have to use a modem who initialization for > dial-in can be stored wholly in the modem (via RAM or DIP switches). > > Thanks for the help everybody, I have something to add :) I see three possibilities you may want to try for your problem. 1) My (very old) USR HST has an undocumented feature-- setting the lowest bit of S13 will cause a modem reset on DTR drop. I have no idea if this still exists or is documented or has been replaced by something else or has been dropped entirely in the vastly different modem you have. 2) There is more than one Hayes modem compatible getty replacement out there that knows about setting up Hayes modems and using their connect messages to set the baud rate on the line. You may have to hack on something like this a bit to get it to work with your HST. 3) With the HST, you can use the &B1 command to keep the baud rate between modem computer fixed. RTFM. Caveats about flow control apply; look this stuff up too. --jh -- John Hood, student at large jhood@albert.mannlib.cornell.edu
larry@nstar.rn.com (Larry Snyder) (03/31/91)
In comp.dcom.modems you write: >1) My (very old) USR HST has an undocumented feature-- setting the >lowest bit of S13 will cause a modem reset on DTR drop. I have no idea >if this still exists or is documented or has been replaced by something >else or has been dropped entirely in the vastly different modem you have. this option is still available on the latest dual standard modems available from USR - and we use it here on nstar >2) There is more than one Hayes modem compatible getty replacement out >there that knows about setting up Hayes modems and using their connect >messages to set the baud rate on the line. >You may have to hack on something like this a bit to get it to work with >your HST. we have that getty available here on the BBS (number below) - which accepts CONNECT 9600/ARQ, CONNECT 2400, etc. strings from the modem and sets the baud rate correctly - but unless you are using smartboards, we have found that the characters from the modem get dropped in which case getty doesn't know how to proceed (at least when using multiple high speed modems) -- Larry Snyder, NSTAR Public Access Unix 219-289-0287 (HST/PEP/V.32/v.42bis) regional UUCP mapping coordinator {larry@nstar.rn.com, ..!uunet!nstar.rn.com!larry}
root@zswamp.fidonet.org (Geoffrey Welsh) (03/31/91)
Dave McLane (davidg%aegis.or.jp@kyoto-u.ac.jp ) wrote: >Unless somebody has something new to add, I think that >answers the >question: for UNIX, you have to use a modem who >initialization for >dial-in can be stored wholly in the modem (via RAM or DIP >switches). OK, 'original' thought: init is set up to respawn getty on your login tty ports; could you perhaps spawn something else which would init the modem and then exec getty? -- UUCP: watmath!xenitec!zswamp!root | 602-66 Mooregate Crescent Internet: root@zswamp.fidonet.org | Kitchener, Ontario FidoNet: SYSOP, 1:221/171 | N2M 5E6 CANADA Data: (519) 742-8939 | (519) 741-9553 The mile is traversed not by a single leap, but by a procession of coherent steps; those who insist on making the trip in a single element will be failing long after you and I have discovered new worlds. - me
paul@frcs.UUCP (Paul Nash) (04/01/91)
Thus spake davidg%aegis.or.jp@kyoto-u.ac.jp (Dave McLane): > jseymour@medar.com (James Seymour) writes: > > I guess I didn't make the point of my query clear. > > I *know* how to set up a modem to re-initialize to the RAM settings > ... > *must* be reinitialzed every call to get them to send the tones Rewrite getty, or rather write somthing (a'la the Xenix dialers) that will initialise your modems, then exec getty. Not totally trivial, but not _such_ a problem either. No, I won't do it for you, I am busy :-), but try asking in places like `comp.sources.wanted'. ---=---=---=---=---=---=---=---=---=---=---=---=---=---=---=---=---=--- Paul Nash Free Range Computer Systems cc paul@frcs.UUCP ...!uunet!m2xenix!frcs!paul
davidg%aegis.or.jp@kyoto-u.ac.jp (Dave McLane) (04/01/91)
paul@frcs.UUCP (Paul Nash) writes: > Rewrite getty, or rather write somthing (a'la the Xenix dialers) that > will initialise your modems, then exec getty. Not totally trivial, > but not _such_ a problem either. No, I won't do it for you, I am > busy :-), but try asking in places like `comp.sources.wanted'. Sounds like a good belling-of-the-cat-solution; I don't have a lot of time either. But at least I know what do look for; thanks. --Dave
vjs@rhyolite.wpd.sgi.com (Vernon Schryver) (04/02/91)
In a system with HDB UUCP, it is convenient to add a arg to getty that tells it to use an ordinary Dialers tag. With source, it is easy to paste a handy part of UUCP into getty. It is particularly easy if you start with the SVR3 uugetty, where the requisite parts of UUCP have already been spliced into getty. Vernon Schryver, vjs@sgi.com
davidg%aegis.or.jp@kyoto-u.ac.jp (Dave McLane) (04/02/91)
root@zswamp.fidonet.org (Geoffrey Welsh) writes: > Dave McLane (davidg%aegis.or.jp@kyoto-u.ac.jp ) wrote: > > >Unless somebody has something new to add, I think that > >answers the > >question: for UNIX, you have to use a modem who > >initialization for > >dial-in can be stored wholly in the modem (via RAM or DIP > >switches). > > OK, 'original' thought: init is set up to respawn getty on your login tty > ports; could you perhaps spawn something else which would init the modem and > then exec getty? I guess I should have waited a bit longer before coming to that conclusion; quite a few other people have said the same thing (mostly in mail): one can have init respawn something else that will init the modem and then getty, or one can init some other program that will do both in one shot. In a larger context, being new to UNIX, I see that I had it in mind that I could use what came of the box (ISC V2.2) to do what I want and was therefore talking about what could be done with the system I have. But the answers to this and other questions have shown me that what comes in the box is many times just a place to hang all the bug fixes, additional programs, etc., etc. With regard to initing the modem, I didn't know if this was something that could be done with the my ISC UNIX in some way I wasn't aware of, or whether I needed to add some new wrinkle. I take it I have to add something new (like I had to add the FAS driver, the compress program, the patch to bring it up to V2.2.1, etc.). Back to the problem of initing the modem, what sounds cleanest (and most educational for me) is to have the source code for a uugetty-like program (I need to call out and in on these lines) that would allow me to init the modem *and* to set the speed according to the kind of messages that are returned by the modem. If anybody knows of such code and where I could find it, could they let me know? --Dave McLane <davidg%aegis.or.jp@kyoto-u.ac.jp> JUNET <dgm@nova.kuis.kyoto-u.ac.jp> DINTERNET <dgm@nova.kuis.jpnkyoto.kyoto-u.ac.jp> BITNET <dgm%nova.kuis.kyoto-u.ac.jp@uunet.uu.net> via UUNET ==== The Aegis Society ============================================= Minami Hirao 1-6, Imazato The content and process of Nagaokakyo-shi, Kyoto-fu, 617 Japan international/cultural Tel: +81-75-951-1168 Fax: +81-75-957-1087 communication. ====================================================================
john@jwt.UUCP (John Temples) (04/03/91)
In article <kJ0mZ7w163w@aegis.or.jp> davidg%aegis.or.jp@kyoto-u.ac.jp (Dave McLane) writes: >From the replies that I've gotten (here and in mail) I take it >that you can't re-init a modem for dialin under ISC UNIX. Here's what I use for my brain-dead Everex modem, which doesn't have non-volatile RAM. My inittab invokes /etc/mgetty, which is a shell script containing: (sleep 5; stty 2400; echo 'ATZ\r\c'; sleep 2; echo 'ATEMS0=1\r\c';) < /dev/ttyF04 > /dev/ttyF04 exec /etc/getty $@ This successfully gets the modem back into 2400 bps mode even if the previous caller was at 1200 bps. The initial "sleep 5" waits for the modem to re-enter command mode after loss of carrier. The Everex is quite slow in this respect; other modems might not need such a delay. The second "sleep" waits for the modem to re-enter command mode after the reset command. This is under ESIX, which is identical to ISC in many respects. -- John W. Temples -- john@jwt.UUCP (uunet!jwt!john)
john@jwt.UUCP (John Temples) (04/03/91)
In article <1991Mar31.144401.18443@nstar.rn.com> larry@nstar.rn.com (Larry Snyder) writes: >we have that getty available here on the BBS (number below) - which accepts >CONNECT 9600/ARQ, CONNECT 2400, etc. strings from the modem and sets the >baud rate correctly - but unless you are using smartboards, we have found >that the characters from the modem get dropped I've tried one of those gettys that parses the connect string, and it didn't work on a "dumb" modem. Apparently the modem is issuing the connect string before asserting DCD; hence getty is still asleep and never sees it. I suppose it might work if you had getty hold the port open all the time, but that wouldn't allow dialout on the port. -- John W. Temples -- john@jwt.UUCP (uunet!jwt!john)
davidg%aegis.or.jp@kyoto-u.ac.jp (Dave McLane) (04/04/91)
To try and summarize where the replies to my original query, the question of how to control the sequence of answer tones has come down to how to init the modem. Initing the modem for dial-out isn't a problem as it can be done in the dialout chat script. For dial-in, some modems can have everything needed for their initialization stored in their non-volitile RAM such that they are reset correctly when the DTR is dropped (e.g. Telebit). And some need to be re-initialized through either a getty that allows one to do so, or, as john@jwt.UUCP (John Temples) writes: > Here's what I use for my brain-dead Everex modem, which doesn't have > non-volatile RAM. My inittab invokes /etc/mgetty, which is a shell > script containing: > > (sleep 5; stty 2400; echo 'ATZ\r\c'; sleep 2; echo 'ATEMS0=1\r\c';) > < /dev/ttyF04 > /dev/ttyF04 > exec /etc/getty $@ A second point was raised regarding how to have a getty intrepret the modem result codes and set changed to the whatever speed was appropriate. John@jwt.UUCP (John Temples) adds: > I've tried one of those gettys that parses the connect string, and it > didn't work on a "dumb" modem. Apparently the modem is issuing the > connect string before asserting DCD; hence getty is still asleep and never > sees it. I suppose it might work if you had getty hold the port open all > the time, but that wouldn't allow dialout on the port. Hope that summarizes it OK. --Dave McLane <davidg%aegis.or.jp@kyoto-u.ac.jp> JUNET <dgm@nova.kuis.kyoto-u.ac.jp> DINTERNET <dgm@nova.kuis.jpnkyoto.kyoto-u.ac.jp> BITNET <dgm%nova.kuis.kyoto-u.ac.jp@uunet.uu.net> via UUNET ==== The Aegis Society ============================================= Minami Hirao 1-6, Imazato The content and process of Nagaokakyo-shi, Kyoto-fu, 617 Japan international/cultural Tel: +81-75-951-1168 Fax: +81-75-957-1087 communication. ====================================================================
gandrews@netcom.COM (Greg Andrews) (04/06/91)
In article <7iNwZ1w163w@aegis.or.jp> davidg%aegis.or.jp@kyoto-u.ac.jp (Dave McLane) writes: > >John@jwt.UUCP (John Temples) adds: > >> I've tried one of those gettys that parses the connect string, and it >> didn't work on a "dumb" modem. Apparently the modem is issuing the >> connect string before asserting DCD; hence getty is still asleep and never >> sees it. I suppose it might work if you had getty hold the port open all >> the time, but that wouldn't allow dialout on the port. > The modem is supposed to send the result code before turning on DCD. Otherwise, how is the computer to know which characters are the modem's result code and which are the caller's keystrokes? The instructions for the special getty should have said how to configure the modem and port. Either you can't do dialout through the same port, or you can with a special setup. -- .------------------------------------------------------------------------. | Greg Andrews | UUCP: {apple,amdahl,claris}!netcom!gandrews | | | Internet: gandrews@netcom.COM | `------------------------------------------------------------------------'