edwards@groucho (06/13/90)
I have an HP 350 with a Hayes compatible modem installed on my serial port. I am able to accept incoming calls without difficulty. However, if I make an outgoing call, I am unable to receive incoming calls after I hang up. I have to reboot in order to again receive incoming calls. Is this normal or can it be fixed? Keep answers simple since I'm not very smart. Thanks edwards@neon.chem.uidaho.edu Daniel Edwards /Department of Chemistry/ University of Idaho/ Moscow ID
eric@hpqtdla.HP.COM (Eric Percival) (06/14/90)
> I have an HP 350 with a Hayes compatible modem installed on my > serial port. I am able to accept incoming calls without difficulty. > However, if I make an outgoing call, I am unable to receive incoming > calls after I hang up. I have to reboot in order to again receive > incoming calls. Is this normal or can it be fixed? Keep answers > simple since I'm not very smart. > Do you have the modem set to ignore DTR ? If so then this could be part of your problem, although it shouldn't be necessary to reboot. Cycling the power on the modem should be enough. When you logout on a properly configured modem port, the DTR line is dropped. This tells the modem that the session is finished and it drops the phone connection. If DTR is forced on, if the Hayes modem is like an HP37212A/B, then even hanging up the phone will not return the modem to its command state. It stays in transparent mode unti either the power is cycled, an attention sequence is received or DTR is dropped. Eric Percival eric@hpsqf.sqf.hp.com # All opinions are those of me, myself and I
edwards@groucho (07/03/90)
Many thanks to those who replied to my original posting re modem not receiving incoming calls after I place an outgoing call. Most suggested checking the DTR setting and/or cycling the power to the modem. I have tried both and neither had any effect on the problem. The problem does not seem to be with the modem, which behaves quite normally. I connect to the modem from the console using cu -s1200 -l tty01 -m dir ATDT dials numbers, ATH hangs up the phone line, and all internal switches seem normal. If I exit from cu (tilde period) I get the normal disconnected message and the normal ksh prompt. If I then call the modem from a remote terminal, I get connected, and nothing happens; no login prompt, no response. If I again try cu from the console, I get a normal connection and then a listing of ringings and garbage that I typed from the remote terminal. The system stays in this state until I reboot. Any suggestions will be welcomed. Daniel Edwards/Department of Chemistry/University of Idaho/Moscow ID 83843 edwards@neon.chem.uidaho.edu
gentry@kcdev.UUCP (Art Gentry) (07/03/90)
In article <1990Jul02.173100.10477@groucho> edwards@neon.UUCP (Daniel Edwards) writes: =The problem does not seem to be with the modem, which behaves quite =normally. I connect to the modem from the console using =cu -s1200 -l tty01 -m dir =ATDT dials numbers, ATH hangs up the phone line, and =all internal switches seem normal. If I exit from cu (tilde period) =I get the normal disconnected message and the normal ksh prompt. =If I then call the modem from a remote terminal, I get connected, =and nothing happens; no login prompt, no response. If I again try =cu from the console, I get a normal connection and then a =listing of ringings and garbage that I typed from the remote terminal. =The system stays in this state until I reboot. Any suggestions will =be welcomed. I missed the original discussion, so this may have already been discussed, but it sounds suspiciously like you have 'getty' instead of 'uugetty' spawned on the port. getty does not know how to handle 2 way traffic gracefully. your /etc/inittab entry should look something like this: 01:2:respawn:/usr/lib/uucp/uugetty -r -t 60 tty01 2400 -- | R. Arthur Gentry AT&T Communications Kansas City, MO 64106 | | Email: gentry@kcdev.uucp ATTMail: attmail!kc4rtm!gentry | | The UNIX BBS: 816-221-0475 The Bedroom BBS: 816-637-4183 | | $include {std_disclaimer.h} "I will make a guess" - Spock - STIV |
paul@prcrs.UUCP (Paul Hite) (07/05/90)
In article <1131@kcdev.UUCP>, gentry@kcdev.UUCP (Art Gentry) writes: > I missed the original discussion, so this may have already been discussed, > but it sounds suspiciously like you have 'getty' instead of 'uugetty' > spawned on the port. getty does not know how to handle 2 way traffic > gracefully. > We had trouble getting two way traffic to work, so we contacted the Response Center. We were using uugetty, but they told us that uugetty is not intended for use with modems on HP-UX. This doesn't jive with what we know from other platforms, but we followed the advice anyway and we have two traffic working with just getty. The Response Center told us that uugetty is intended only for use with hard-wired links. We did not have a special file correctly set up and the Responce Center also found that. I suspect that once the special file was correct, we really could have gone back to uugetty on the modem port, but we want to do things HP's way. We asked for an explanation of how cu, uucp, and getty avoid colliding with each other. getty opens the callin special file and blocks waiting for carrier detect. If cu or getty want the port, they open the callout special file which doesn't block. They will cause cd to be raised, but getty's open will then fail because it wants exclusive access. cu and uucp (uucico) never interfer with each other because of lock files. Anyway, we are using getty on a two-way modem port and the Response Center did say that uugetty should not be used on a modem port. I would be interested in hearing a lab type confirm (or deny) that this is the official HP line. Paul Hite PRC Realty Systems McLean,Va uunet!prcrs!paul (703) 556-2243 DOS is a four letter word!
belkin@teecs.UUCP (Hershel Belkin) (07/10/90)
/ teecs:comp.sys.hp / paul@prcrs.UUCP (Paul Hite) / 11:12 am Jul 5, 1990 / >We had trouble getting two way traffic to work, so we contacted the Response >Center. We were using uugetty, but they told us that uugetty is not intended >for use with modems on HP-UX. This doesn't jive with what we know from other >platforms, but we followed the advice anyway and we have two traffic working >with just getty. The Response Center told us that uugetty is intended only >for use with hard-wired links. We did not have a special file correctly set >up and the Responce Center also found that. I suspect that once the special >file was correct, we really could have gone back to uugetty on the modem port, >but we want to do things HP's way. I also have been told that by the Response center, but I never really believed it! It just doesn't seem to make sense to me. Besides, I've been running bi-directionally with uugetty for over a year with no problems! Once and for all, could someone at HP clear up this confusion? If uugetty is "not intended for use with modems", then why not? All other unix versions I've seen provide uugetty for that exact reason! Even HPO's own manuals talk about uugetty with modems! (In fact, the only reference to uugetty on a direct line, is a warning that if there is a uugetty at each end of a direct line, the -r option must be used.) My personal feeling is that there is a lot of confusion about getty/uugetty within HP's ranks. If I'm wrong (and I hope I am), then please, let's hear a definitive answer on this. If HP does it differently than everyone else, let's understand why! -- +-----------------------------------------------+-------------------------+ | Hershel Belkin hp9000/825(HP-UX)| UUCP: teecs!belkin | | Test Equipment Engineering Computing Services | Phone: 416 246-2647 | | Litton Systems Canada Limited (Toronto) | FAX: 416 246-5233 | +-----------------------------------------------+-------------------------+
belkin@teecs.UUCP (Hershel Belkin) (07/11/90)
/ teecs:comp.sys.hp / paul@prcrs.UUCP (Paul Hite) / 11:12 am Jul 5, 1990 / >We had trouble getting two way traffic to work, so we contacted the Response >Center. We were using uugetty, but they told us that uugetty is not intended >for use with modems on HP-UX. This doesn't jive with what we know from other >platforms, but we followed the advice anyway and we have two traffic working >with just getty. The Response Center told us that uugetty is intended only >for use with hard-wired links. We did not have a special file correctly set >up and the Responce Center also found that. I suspect that once the special >file was correct, we really could have gone back to uugetty on the modem port, >but we want to do things HP's way. I also have been told that by the Response center, but I never really believed it! It just doesn't seem to make sense to me. Besides, I've been running bi-directionally with uugetty for over a year with no problems! Once and for all, could someone at HP clear up this confusion? If uugetty is "not intended for use with modems", then why not? All other unix versions I've seen provide uugetty for that exact reason! Even HP's own manuals talk about uugetty with modems! (In fact, the only reference to uugetty on a direct line, is a warning that if there is a uugetty at each end of a direct line, the -r option must be used.) My personal feeling is that there is a lot of confusion about getty/uugetty within HP's ranks. If I'm wrong (and I hope I am), then please, let's hear a definitive answer on this. If HP does it differently than everyone else, let's understand why! -- +-----------------------------------------------+-------------------------+ | Hershel Belkin hp9000/825(HP-UX)| UUCP: teecs!belkin | | Test Equipment Engineering Computing Services | Phone: 416 246-2647 | | Litton Systems Canada Limited (Toronto) | FAX: 416 246-5233 | +-----------------------------------------------+-------------------------+