belkin@teecs.UUCP (Hershel Belkin) (08/09/89)
Can anyone suggest a method (or where to find a method) of implementing a dial-back scheme that would work with a call-in terminal (as opposed to a computer)? I have a need to call my system while out of town, but for security (as well as long distance charge :-) reasons, I'd like to have the system call me back after the initial log on. (Yes, I know about "security modems", but I don't have one!) I thought there might be some way using "cu" to place the call-back, but I don't know how I'd then associate a getty with the connected line. (ie. "cu" calls, my modem answers, ... then what??) Any suggestions would be greatly appreciated!! Thanks (Email responses to "...!lsuc!teecs!belkin" ; I'll be glad to summarize and re-post any useful suggestions) +-----------------------------------------------+-------------------------+ | Hershel Belkin HP9000/825 (HP-UX) | ...!lsuc!teecs!belkin | | Test Equipment Engineering Computing Services | Phone: 416 246-2647 | | Litton Systems Canada Limited (Toronto) | FAX: 416 246-5233 | +-----------------------------------------------+-------------------------+
pcf@galadriel.bt.co.uk (Pete French) (08/11/89)
From article <960001@teecs.UUCP>, by belkin@teecs.UUCP (Hershel Belkin): > I thought there might be some way using "cu" to place the call-back, but > I don't know how I'd then associate a getty with the connected line. > (ie. "cu" calls, my modem answers, ... then what??) Forget cu - it does far more than you need. I had to do this once and the solution I came up with was to write a C program that called out on a hayes modem line and when it got a 'CONNECT' message it forked a getty. For this to work the process must attach stdin, stdout and stderr to the outgoing terminal line and then set itself to be the head of a process group. If not then /dev/tty will not point to the right device. I do not have the src available on my current machine however (and I never quite finished it anyway...) -Pete French.
belkin@teecs.UUCP (Hershel Belkin) (08/11/89)
In response to my query about how to implement a computer-to-terminal dial-back scheme (terminal calls computer, terminal hangs up, computer then calls terminal), I received a quick reply excerpted below: >From: uunet!idca.tds.PHILIPS.nl!willy (Willy Konijnenberg) >To: teecs!belkin@lsuc >Subject: Re: Can cu do call-backs to terminals? >Newsgroups: comp.unix.wizards >In-Reply-To: <960001@teecs.UUCP> >Organization: Philips Telecommunication and Data Systems, The Netherlands >cu is not the right program for this. It won't give you a shell. >There is the program 'ct', which is intended to be used for callback >setups, . . . [edited] Well, how simple! My previous system didn't have "ct", and I had never come across a reference to it. But having received this suggestion, I found that I do indeed have "ct", and it does exactly what I wanted!! In my case, after I dial in and log in, I simply exec a script which runs ct in the background, tells me to disconnect, and exits. I disconnect the modem, and wait a few seconds, until ct calls me back. When modem connection is established, ct starts a getty, and I can log in again! Fantastic. Thanks for your help, Willy! Hope this is of use to others as well. -- +-----------------------------------------------+-------------------------+ | Hershel Belkin hp9000/825 (HP-UX)| ...!lsuc!teecs!belkin | | Test Equipment Engineering Computing Services | Phone: 416 246-2647 | | Litton Systems Canada Limited (Toronto) | FAX: 416 246-5233 | +-----------------------------------------------+-------------------------+
mcr@julie.UUCP (Michael Richardson) (08/21/89)
Pete French writes: >Forget cu - it does far more than you need. I had to do this once and the >solution I came up with was to write a C program that called out on a hayes >modem line and when it got a 'CONNECT' message it forked a getty. For this to >work the process must attach stdin, stdout and stderr to the outgoing terminal On SVR3.2 (ICS 2.0.2 I think) I tried something like that. (Only it was for inbound. uugetty is junk, and uucico and cu don't seem to do CLOCAL right. I was sending an init string, waiting for `RING', sending `ATA' and waiting for `CONNECT' --- with a shell script and some timed read functions and stdin and stdout redirected to the tty opened in CLOCAL mode.) I wanted to `exec getty' from the shell script, which did work fine --- except that login wants the password from stderr. Okay, bypass this problem for the moment and enter it in from my test terminal, and then it dies --- the `/etc/utmp' entry points to the wrong pid. The on-site morning session was over and I left it doing inbound only... (Exec'ing the shell script never seemed to work --- the tty's file descriptor which I was dup()ing seemed to get screwed around by exec()..) >line and then set itself to be the head of a process group. If not then /dev/tty >will not point to the right device. I do not have the src available on my >current machine however (and I never quite finished it anyway...) Of course, he has SVR3.2, then he probably also has ct. :-) Has anyone else ever tried building better modem support into getty? I'll probably try again, and bit the bullet and do it in C. (Very difficult to debug programs when their stdin/stdout is not your terminal, and you need another machine, two phones lines, --- if there were two phone lines available, one would be outbound and the problem solved.) >-Pete French. -- :!mcr!: Michael Richardson Amiga v--------+ UUCP: uunet!attcan!lsuc!nrcaer!julie!mcr | INTERNET mcr@doe.carleton.ca Fido: Michael Richardson @ 1:163/109.10<--+ Alter @ 7:483/109.10
pcf@galadriel.bt.co.uk (Pete French) (08/29/89)
From article <0532.AA0532@julie>, by mcr@julie.UUCP (Michael Richardson): > Pete French writes: >>Forget cu - it does far more than you need. I had to do this once and the >>solution I came up with was to write a C program that called out on a hayes >>modem line and when it got a 'CONNECT' message it forked a getty. For this to >>work the process must attach stdin, stdout and stderr to the outgoing terminal > > I wanted to `exec getty' from the shell script, which did work fine --- > except that login wants the password from stderr. Okay, bypass this > problem for the moment and enter it in from my test terminal, and > then it dies --- the `/etc/utmp' entry points to the wrong pid. Oh god, this brings back bad memories ... yes, you do have to play with the /etc/utmp entry. A large chunk of my program was designed to set it up the way it would be before a getty was placed onto it in the normal manner. The login problem is sloved by making the getty head of the process group with all the stin,stdout,stderr pointing to the terminal. > I'll probably try again, and bit the bullet and do it in C. (Very difficult > to debug programs when their stdin/stdout is not your terminal, and > you need another machine, two phones lines, --- if there were two > phone lines available, one would be outbound and the problem solved.) I think that it can only be done in C - due to the need for setting process groups and playing with utmp. The comment about debugging is valid - the way that I did it was to connect a hardcopy terminal in place of the modem and then type the responses that the hayes would produce in on the keyboard. This also meant thatr I could test the logging in when the getty had been spawned. The interesting thing was that it all worked fine when connected to the terminal but when connected to the modem it did not work at all. I didnt have the time to finish playing with this. I will try and re-aquire the src this evening so if anyone wants to play with it they can. Mail me if your interested. -Pete. -- -Pete French. | British Telecom Research Labs. | "The carefree days are distant now, Martlesham Heath, East Anglia. | I wear my memories like a shroud..." All my own thoughts (of course) | -SIOUXSIE