Path: utzoo!attcan!utgpu!watserv1!watmath!uunet!wuarchive!psuvax1!rutgers!att!cbnewsh!hos2cad!wjc From: wjc@ho5cad.ATT.COM (Bill Carpenter) Newsgroups: unix-pc.general Subject: Re: Submission for Unix-PC Message-ID: Date: 8 Dec 89 08:12:26 GMT References: <8912080450.AA20987@ames.arc.nasa.gov> Sender: bill@cbnewsh.ATT.COM Reply-To: william_j_carpenter@ATT.COM (Bill Carpenter) Organization: AT&T Bell Laboratories Lines: 93 In-reply-to: gatelist@zorch.SF-Bay.ORG's message of 8 Dec 89 00:39:38 GMT On 8 Dec 89 00:39:38 GMT, gatelist@zorch.SF-Bay.ORG said: gatelist> In order for me to be able to use this, I need a program gatelist> that is somewhat like cu, but instead of placing a call, it gatelist> waits around for an incoming call. I guess it also need to I ran into dialback modems a while back. Below is what I did. This was using HDB "cu". I have never tried it with stock "cu". If anyone does, perhaps they could post the result, good or bad. -- Bill Carpenter att!ho5cad!wjc or attmail!bill ================================================================ Date: Fri, 5 Feb 88 09:18 EST From: wjc >From wjc Fri Feb 5 09:18:56 1988 To: ... Subject: answering calls with "cu" A couple months ago, we were jointly wondering how we could answer an incoming data call on the UnixPC and end up in terminal emulation. We discussed this in the context of using the "ct" utility from another Unix host (we're apparently still waiting for the new secure version of "ct" to be issued). Well, here's good news. At OCW, they don't use a modem password; instead, they use a dialback modem. That is, you call in, type your security ID, it hangs up and calls you back on a pre-programmed phone number. That means that I had to attack with fervor the problem of answering an incoming call for terminal emulation. This method works for the UnixPC with the latest HDB uucp and cu from The Store! It seems like it would probably work with other uucp versions and other types of machines that have modems directly connected to them, but I'm conjecturing a little. A. File stuff. Make an entry like this in your uucp Systems file: hullo Any hullo Any - There is nothing magic about the token "hullo". You just need something that isn't otherwise special or built-in for uucp. Make an entry like this in your uucp Devices file: hullo ph1,M - Any direct Again, nothing special about "hullo" except that it must match the token in the Systems file. The token "direct" is special to uucp. The entry "ph1,M" identifies the Unix device, so you could use "ph0" or "tty000" (if you had an external modem on /dev/tty000), etc. The ",M" is an undocumented item used by the dialing routines. It means the port has modem control. When uucp or cu opens the device, the open() call won't return until it sees Carrier Detect or some similar modem magic. B. Command stuff. Imagine that your phone is just about to ring with that incoming data call. You can answer it by using: getoff.sh ph1 # kills the uugetty on the line cu hullo # will tell you it's "connected" right away geton.sh ph1 # optional, restores the uugetty If you do the "cu" while the phone is ringing, it will be answered as soon as "cu" kicks in. If you "cu" before it rings, then it will be answered quickly (first ring). In either case, bang a few CR's or whatever, since you're connected to the line and it might need autobauding on the other end. When you exit "cu", the connection won't be broken right away. It takes 30 seconds or so. This is due to the normal mechanisms in the phone, but we don't normally see it with "cu" since we normally inititate the call. What you get is a race condition between the phone network disconnecting you and Datakit (or whatever) timing out and hanging up. I guess it doesn't matter much. NOTES: I'm not completely sure how some of this works, so there are possibly some better combinations of things to do, especially with the uucp file entries. I also tried doing this via the Office phone stuff. It claims that if you don't use a phone number, it will spawn async_main in what looks like an answer mode. Alas, you can't get past the error message that it gives you about the missing phone number, so I guess we'll never know. Yes, I did find out about the ",M" by reading the uucp source code. I guess you could consider that a form of documentation. Bill Carpenter (AT&T gateways)!ho5cad!wjc