root@mjbtn.UUCP (Mark J. Bailey) (07/23/88)
Hello,
I am having an annoying problem that some of you may have also experienced.
I have 1) Mitsuba 2400 Internal Hayes compat. modem and 2) Prometheus 2400P
External Modem and my Tandy 4000 '386 system running SCO Xenix 2.2.2. I have
my modems set to answer at 2400 baud and then cycle to 1200 on a CR and then
back to 2400. They are supposed to reset to 2400 baud at logoff, aren't
they? Well, what is happening is that on initial setup, they answer the
first calls just fine, and then when the user logs off, they answer the
next call properly at 2400 baud ... sometimes. At other times, they seems
to get "stuck" in a 1200 baud mode, and that is where they stay, regardless
of getty sending at 2400 (supposedly), they still answer at 1200 baud.
My question was if anyone else in netland had experienced this odd behavior
with Hayes 2400 compat. modems, and if so, what you did to correct the
problem. Is it getty? Or the modem? I have even tried logging in at the
1200 speed and then logging out with control-d and watching getty throw
garbage on the screen as it resends the "login" prompt at 2400 baud to the
modem, yet the modem still answers at 1200 on the next call. Only until
I reset the modem back to a pre-first call state, does it again answer at
2400 as it should.
Any help would be greatly appreciated. Answer by direct email if you
prefer.
Thank you! Mark.
--
Mark J. Bailey "Y'all com bak naw, ya hear!"
USMAIL: 511 Memorial Blvd., Murfreesboro, TN 37130 ___________________________
VOICE: +1 615 893 4450 / +1 615 896 4153 | JobSoft
UUCP: ...!{ames,mit-eddie}!killer!mjbtn!root | Design & Development Co.
FIDO: Mark Bailey at Net/Node 1:116/12 | Murfreesboro, TN USAjfh@rpp386.UUCP (John F. Haugh II) (07/23/88)
In article <273@mjbtn.UUCP> root@mjbtn.UUCP (Mark J. Bailey) writes: >Hello, > >I am having an annoying problem that some of you may have also experienced. > >I have 1) Mitsuba 2400 Internal Hayes compat. modem and 2) Prometheus 2400P >External Modem and my Tandy 4000 '386 system running SCO Xenix 2.2.2. I have >my modems set to answer at 2400 baud and then cycle to 1200 on a CR and then >back to 2400. They are supposed to reset to 2400 baud at logoff, aren't >they? Well, what is happening is that on initial setup, they answer the >first calls just fine, and then when the user logs off, they answer the >next call properly at 2400 baud ... sometimes. At other times, they seems >to get "stuck" in a 1200 baud mode, and that is where they stay, regardless >of getty sending at 2400 (supposedly), they still answer at 1200 baud. this seems to be a very common problem with 2400 baud hayes compatible modems, hence the posting. the problem arises whenever a connection is received at 1200 baud and the modem is not reset. some of the modems have a setting which allows the modem to be reset whenever DTR drops. i'm unfortunate enough to not fall in that catagory, so i know of what i speak ;-( if you modem does not have a command option to reset the modem on hangup, and you are equally unfortunate to have the 1200 baud problem, there is nothing you can do outside of resetting the modem on each hangup. the simple fix is to write a wrapper around getty and have it reset the modem on each invocation. just a word to the wise, you have to fork a child to do the actual talking to the tty port because the process group will get messed up. not enough room to explain it here, just trust me. if you are unfortunate enough to be stuck with micropoor unix and its perverse getty, you are in real trouble. i understand installing your own version of getty is very difficult. you know what they say, "surf sco or go home" (sorry eric) - john. -- John F. Haugh II +--------- Cute Chocolate Quote --------- HASA, "S" Division | "USENET should not be confused with UUCP: killer!rpp386!jfh | something that matters, like CHOCOLATE" DOMAIN: jfh@rpp386.uucp | -- with my apologizes
root@ozdaltx.UUCP (root) (07/23/88)
I have the same problem with an Incomm 2400b modem, too.
The Incomm people says I have to send the modem a command to
reset it to 2400 after the last close.
I too, would be interested in answers.
--
Scotty
AIDS INFORMATION EXCHANGE BBS (214) 247-2367/247-5609
"Education is the best weapon"
{ames,mit-eddie,rutgers,osu-cis,lll-winken,texsun,smu}!killer!ozdaltx!sysop mikej@dasys1.UUCP (Mike Johnston) (07/24/88)
In article <273@mjbtn.UUCP> root@mjbtn.UUCP (Mark J. Bailey) writes: >I am having an annoying problem that some of you may have also experienced. >my modems set to answer at 2400 baud and then cycle to 1200 on a CR and then >back to 2400. They are supposed to reset to 2400 baud at logoff, aren't >they? Well, what is happening is that on initial setup, they answer the >first calls just fine, and then when the user logs off, they answer the >next call properly at 2400 baud ... sometimes. At other times, they seems >to get "stuck" in a 1200 baud mode, and that is where they stay, regardless I have had similar problems. A partial victory might be achieved by setting your modems to reset on a dtr change. I.E. ATD0 I believe. Thus, when the getty drops the line (dtr low) the modem performs an ATZ on itself and resets back to 2400 baud. This has worked somewhat well on my machine but sometimes the modem just loops on itself and continually resets for hours until someone turns it off. I am using a Hayes 2400 external on an Altos 2086 running Xenix. If someone else has a more elegant solution I'd sure like to hear it. +-----------------------------------------------------------------------------+ |Michael R. Johnston / cpmain!mrj | |Franchise Data Specialist ....cmcl2!phri!dasys1! | |Career Employment Services Inc. \ mikej | | ".......but it was working just yesterday.........." | +-----------------------------------------------------------------------------+
mdc@mcp.entity.com (Marty Connor) (07/25/88)
In article <273@mjbtn.UUCP> root@mjbtn.UUCP (Mark J. Bailey) writes: >I am having an annoying problem that some of you may have also experienced. >my modems set to answer at 2400 baud and then cycle to 1200 on a CR and then >back to 2400. They are supposed to reset to 2400 baud at logoff, aren't >they? Well, what is happening is that on initial setup, they answer the >first calls just fine, and then when the user logs off, they answer the >next call properly at 2400 baud ... sometimes. At other times, they seems >to get "stuck" in a 1200 baud mode, and that is where they stay, regardless I had the same problem with my Practical Peripherals 2400 baud modems. Apparently, one *minor* ambiguity with HAYES compatibility is, whether the modem should ALWAYS answer the phone at the HIGHEST baud rate that it can do, and then step down. If a modem answers the phone and starts making 1200 baud noises, the modem on the other end will not even bother trying a higher baud rate. Therein lies the screw. Well, I convinced the people at Practical Peripherals that I was not crazy, and that it was broken behavior for a modem to answer at a 1200 baud if it could do 2400, if the modem had been set up with the AT&C1&D3 command. They said their gold-standard HAYES did it. I suggested they get a new HAYES and try it; I also suggested that even if HAYES did it, it was broken, and emulating this bug was evil. Apparently OLDER genuine HAYES modems would answer the phone at the last baud rate that modem was USED at. The folks at Practical Peripherals tell me that newer HAYESes have changed their minds on this. Nice folks, these. They just sent me new ROMs for my PM2400SAs to fix the bug. Thanks, Therese, Dave, and Roland (on bass). Small point, but try autobauding on your Xenix box with the modems conspiring to play baud-rate roulette. Anyway, the executive summary is: AT&C1&D3 AT&W AT&C1 says that the modem should not lie to the host about carrier detect, but should indicate the true state of the carrier on pin 8. AT&D3 (this is the biggy) says that the modem should do an ATZ every time that DTR goes low-then-high. Hope this make someone's day/night. -- ---------------- Marty Connor Director of Innovation, The Entity mdc@mcp.entity.com, ...{harvard|uunet}!mit-eddie!spt!mcp!mdc
mikej@dasys1.UUCP (Mike Johnston) (07/25/88)
iThe command to accomplish this is AT&D3. Send it to the modem and save it with an AT&W. +-----------------------------------------------------------------------------+ |Michael R. Johnston / cpmain!mikej| |Career Employment Services Inc. \ mikej | | ".......but it was working just yesterday.........." | +-----------------------------------------------------------------------------+
fyl@ssc.UUCP (Phil Hughes) (07/26/88)
In article <273@mjbtn.UUCP>, root@mjbtn.UUCP (Mark J. Bailey) writes: > I have 1) Mitsuba 2400 Internal Hayes compat. modem and 2) Prometheus 2400P > External Modem and my Tandy 4000 '386 system running SCO Xenix 2.2.2. I have > my modems set to answer at 2400 baud and then cycle to 1200 on a CR and then > back to 2400. They are supposed to reset to 2400 baud at logoff, aren't > they? Well, what is happening is that on initial setup, they answer the > first calls just fine, and then when the user logs off, they answer the > next call properly at 2400 baud ... sometimes. At other times, they seems > to get "stuck" in a 1200 baud mode, and that is where they stay, regardless > of getty sending at 2400 (supposedly), they still answer at 1200 baud. Oh, yes, this one. I have been living with it for so long I almost forgot about it. I blame this on what I would consider a design error by Hayes in the control of the 2400 baud modem. If the last command you send the modem is at 1200 baud, it will stay at 1200 baud. What happens is that after a hangup, XENIX might send additional data to the modem. For example, the end of a logout message after the calling system has gone away. It carrier detect has left, the modem returns to command mode. If the data is at 1200 baud, the modem sets its baud rate to 1200. The only way to get it back to 2400 is to send a command at 2400. Getty won't do this until carrier detect returns and the modem will not connect at 2400 because it is "being commanded" at 1200. I never found a clean solution, but my dirty one almost works. Every hour, cron starts a shell script that disables all the 2400 baud lines that are not in use, sends commands to the modems (a few ATs or a reset are cool) to the modems and then enables them. Ugly, but it almost works. Hope this helps. Phil Hughes, SSC, Inc. P.O. Box 55549, Seattle, WA 98155 (206)FOR-UNIX uw-beaver!tikal!ssc!fyl or uunet!pilchuck!ssc!fyl or attmail!ssc!fyl -- Phil uunet!pilchuck!ssc!fyl
tif@cpe.UUCP (07/26/88)
Written 11:06 pm Jul 22, 1988 by mjbtn.UUCP!root in cpe:comp.unix.xenix >I have 1) Mitsuba 2400 Internal Hayes compat. modem and 2) Prometheus 2400P >External Modem ... >Well, what is happening is that on initial setup, they answer the >first calls just fine, and then when the user logs off, they answer the >next call properly at 2400 baud ... sometimes. At other times, they seems >to get "stuck" in a 1200 baud mode, and that is where they stay, regardless >of getty sending at 2400 (supposedly), they still answer at 1200 baud. !@#$%^&*() modem's. Haven't you heard? Even Hayes isn't Hayes compatible! Many modems make this brain-dead mistake. Once they shift to 1200, bye-bye. I haven't tried this but I suspect a cron job to call out at 2400, even if it fails, will fix the modem as often as you need to. Oh yea, I have been told that some modems have a special command that means "Don't be so stupid." Paul Chamberlain Computer Product Engineering, Tandy Corp. ihnp4!sys1!cpe!tif
jfh@rpp386.UUCP (John F. Haugh II) (07/28/88)
In article <5716@dasys1.UUCP> mikej@dasys1.UUCP (Mike Johnston) writes: |In article <273@mjbtn.UUCP> root@mjbtn.UUCP (Mark J. Bailey) writes: |>I am having an annoying problem that some of you may have also experienced. |>my modems set to answer at 2400 baud and then cycle to 1200 on a CR and then |>back to 2400. They are supposed to reset to 2400 baud at logoff, aren't |>they? | |I have had similar problems. A partial victory might be achieved by setting |your modems to reset on a dtr change. I.E. ATD0 I believe. Thus, when the |getty drops the line (dtr low) the modem performs an ATZ on itself and |resets back to 2400 baud. this has the nasty side effect for non-hayes modems of possibly resetting the D0 flag after the reset, which causes the next hangup to NOT reset the modem. for hayes modems you must remember to store the command into non-volatile memory so that the reset will not turn off that option. - john. -- John F. Haugh II +--------- Cute Chocolate Quote --------- HASA, "S" Division | "USENET should not be confused with UUCP: killer!rpp386!jfh | something that matters, like CHOCOLATE" DOMAIN: jfh@rpp386.uucp | -- with my apologizes
jfh@rpp386.UUCP (John F. Haugh II) (07/28/88)
In article <1373@ssc.UUCP> fyl@ssc.UUCP (Phil Hughes) writes: >I never found a clean solution, but my dirty one almost works. >Every hour, cron starts a shell script that disables all the 2400 >baud lines that are not in use, sends commands to the modems >(a few ATs or a reset are cool) to the modems and then enables them. >Ugly, but it almost works. okay. since we are sending out ugly solutions, how about an almost clean one which works flawlessly modulo 200 or some phone calls a day ... compile this, move /etc/getty to /etc/ogetty and copy the a.out to /etc/getty. don't forget to change a few things, like line number and so on. all you have to do is insure the modem is hung-up before invoking getty. this was just a simple hack i wrote some months ago and it has worked since. --- fkgetty.c --- main (argc, argv, envp) int argc; char *argv[], *envp[]; { if (argc < 2 || strcmp (argv[1], "tty1A") != 0) { execl ( "/etc/ogetty", argv[0], argv[1], argv[2], argv[3], (char *) 0 ); _exit (127); } sleep (1); system ("/usr/lib/uucp/dial -h /dev/tty1A 2400"); sleep (1); execl ("/etc/ogetty", argv[0], argv[1], argv[2], argv[3], (char *) 0); _exit (127); } --------------- -- John F. Haugh II +--------- Cute Chocolate Quote --------- HASA, "S" Division | "USENET should not be confused with UUCP: killer!rpp386!jfh | something that matters, like CHOCOLATE" DOMAIN: jfh@rpp386.uucp | -- with my apologizes
chip@ateng.UUCP (Chip Salzenberg) (07/30/88)
According to root@mjbtn.UUCP (Mark J. Bailey): >I am having an annoying problem that some of you may have also experienced. > >[Hayes-compatible modems] seems >to get "stuck" in a 1200 baud mode, and that is where they stay, regardless >of getty sending at 2400 (supposedly), they still answer at 1200 baud. A simple solution is to make sure that there is an "A" somewhere in the login prompt sent to your modem. Here is a piece of my /etc/gettydefs: 3 # B2400 HUPCL OPOST NL1 ECHOE # B2400 CS8 SANE HUPCL -CLOCAL TAB3 IXANY ECHOE #\r\nA T Engineering\r\nlogin: # 2 Notice the "A" in the prompt? Hayes-compatible modems key on that particular letter and automatically change to the correct baud rate. -- Chip Salzenberg <chip@ateng.uu.net> or <uunet!ateng!chip> A T Engineering My employer may or may not agree with me. You make me wanna break the laws of time and space You make me wanna eat pork
jfh@rpp386.UUCP (John F. Haugh II) (07/30/88)
In article <6800016@cpe> tif@cpe.UUCP writes: > >Oh yea, I have been told that some modems have a special command that >means "Don't be so stupid." >-- > Paul Chamberlain no, that's what got us in this fix in the first place. what we need is a command that says "don't be so smart!" one might assume having a 2400 baud modem reset to 2400 baud when it didn't have DTR assert might be a simple thing, no? -- John F. Haugh II +--------- Cute Chocolate Quote --------- HASA, "S" Division | "USENET should not be confused with UUCP: killer!rpp386!jfh | something that matters, like CHOCOLATE" DOMAIN: jfh@rpp386.uucp | -- with my apologizes