michael@fe2o3.UUCP (Michael Katzmann) (09/06/90)
I have a Sys V.3 system with HDB uucp. The system is at home and
it shares the phoneline. So that it won't answer the phone every time,
I run a programme with cron that tells the modem (hayes 2400) to
enable auto answer only at specific times (a window that the machine
that rings me up knows about).
This programme looks to see if a lockfile is present /usr/spool/locks/LCK..tty1,
before blindly writting out to the line.
The problem:
uugetty seems to create a lockfile when a character is first received.
I dont know when it is removed (perhaps after uugetty is restarted after a
login), however if it was just noise and no login is successful the lockfile,
it seems, is never removed.
Thus the auto-answer enable programme will not enable the modem and because
no successful login will take place if the phone is not auto-answered the
lock file will not be removed.
Any ideas anyone?
B.T.W. if no garbage is received on the line things work ok.
Perhaps there is a better way to enable auto-answer from HDB uucp.
Thanks
---------------------------------------------------------------------
email to
UUCP: uunet!mimsy!{arinc,fe2o3}!vk2bea!michael
_ _ _ _
Amateur | VK2BEA (Australia) ' ) ) ) / //
Radio | G4NYV (United Kingdom) / / / o _. /_ __. _ //
Stations| NV3Z (United States) / ' (_<_(__/ /_(_/|_</_</_
Michael Katzmann
Broadcast Sports Technology.
2135 Espey Ct. #4
Crofton Md. 21114 USA
Ph: +1 301 721 5151dag@fciva.FRANKLIN.COM (Daniel A. Graifer) (09/07/90)
In article <384@fe2o3.UUCP> michael@fe2o3.UUCP (Michael Katzmann) writes: >The problem: > uugetty seems to create a lockfile when a character is first received. >I dont know when it is removed (perhaps after uugetty is restarted after a >login), however if it was just noise and no login is successful the lockfile, >it seems, is never removed. >Michael Katzmann Are you using the -h and -t timeout options to uugetty (does your uugetty have them)? These should cause the uugetty to quit and respawn after timeout seconds. Good luck Dan -- Daniel A. Graifer Franklin Mortgage Capital Corporation uunet!dag@fmccva.franklin.com 7900 Westpark Drive, Suite A130 (703)448-3300 McLean, VA 22102
root@ninja.dell.com (Randy Davis) (09/07/90)
In article <384@fe2o3.UUCP> michael@fe2o3.UUCP (Michael Katzmann) writes: |The problem: | uugetty seems to create a lockfile when a character is first received. |I dont know when it is removed (perhaps after uugetty is restarted after a |login), however if it was just noise and no login is successful the lockfile, |it seems, is never removed. However, the new login process started after the uugetty times out (you *do* have the timeout in effect, right?) will have a different process ID number which should invalidate the process ID number stored in the lockfile, despite its existance. |Thus the auto-answer enable programme will not enable the modem and because |no successful login will take place if the phone is not auto-answered the |lock file will not be removed. | |Any ideas anyone? Yeah, easy.... First make sure the uugetty timeout is enabled, then, in your progam, simply get the process ID number FROM the lockfile and check to see if the process exists. If the process does not exist, then remove the lockfile, since it is invalid. An easy way to do this is if ps -p `cat -s $LCKFILE` > /dev/null then : # don't remove lockfile else rm $LCKFILE fi For that matter, make sure that you are putting an active process ID in the lockfile, or the uucico, etc.. processes will remove your lockfile if they sense that the lockfile is invalid. The format of the process ID in the file is special. Here is a section of shell script that will show you what I mean: # Contents of the LCK file must be 11 characters in the following format: # leading spaces, process ID, newline (\n), null (\0). # E.g.: " 12345\n\0" # 1234567891011 # The following takes care of the space padding... PID=$$ # PID in the range of single digits up to 30000 (5 digits) if [ "$PID" -lt "10000" ] then PID=" $PID" if [ "$PID" -lt "1000" ] then PID=" $PID" if [ "$PID" -lt "100" ] then PID=" $PID" if [ "$PID" -lt "10" ] then PID=" $PID" fi fi fi fi PID=" $PID" echo "${PID}\n\0\c" > ${LCKFILE} /bin/chown uucp ${LCKFILE} /bin/chgrp uucp ${LCKFILE} /bin/chmod 444 ${LCKFILE} Hopefully this is correct. I use to work with HDB uucp ALL the time, then I got into networked systems and haven't touched it in almost a year. Good luck, Randy Davis UUCP: rjd@ninja.dell.com --
les@chinet.chi.il.us (Leslie Mikesell) (09/08/90)
In article <384@fe2o3.UUCP> michael@fe2o3.UUCP (Michael Katzmann) writes: >I have a Sys V.3 system with HDB uucp. The system is at home and >it shares the phoneline. So that it won't answer the phone every time, >I run a programme with cron that tells the modem (hayes 2400) to >enable auto answer only at specific times (a window that the machine >that rings me up knows about). >This programme looks to see if a lockfile is present > /usr/spool/locks/LCK..tty1, before blindly writting out to the line. >The problem: > uugetty seems to create a lockfile when a character is first received. >I dont know when it is removed (perhaps after uugetty is restarted after a >login), however if it was just noise and no login is successful the lockfile, >it seems, is never removed. First, be sure that your modem is set to pass the state of the carrier detect line to the computer instead of holding it up all the time. This should make uugetty recycle when the line drops. Note that this will require you to use O_NDELAY if you want to talk to the modem with your own program - you won't be able to just echo characters out the port from a shell script. Next, if the modem is set up to observe the state of the computer's DTR lead, then it won't answer unless uugetty is running. Thus you can make a cron entry that alters /etc/inittab and does an "init q" at appropriate time to control the times the machine will answer. Alternatively, if you really want to chat with the modem without a whole lot of work it can be done like this: Set up a Devices entry with a previously unused modem-class and dialer using the same device as your modem: ACU tty1,M - S2400 setup Set up a matching Dialer script with whatever you want (it doesn't need to dial anything) Make a Systems entry that requests this modem-class: setup Any ACU S2400 - Now you can just "echo ~. |cu setup" and the specified chat will occur with all the appropriate checks for the device being in use. A similar procedure works nicely for actually dialing systems that need more than the usual dialing script, like dialing up a packet switch and asking for a connection. Each physical device can be listed many times in the "Devices" file with different modem-classes and dialer types. The modem-class entry in the System file controls which entry is matched and thus which dialer chat script will be used to connect to that system. Les Mikesell les@chinet.chi.il.us
mdv@comtst.UUCP (Mike Verstegen) (09/12/90)
In article <9422@uudell.dell.com> rjd@ninja.dell.com writes: [ stuff deleted...] > > Yeah, easy.... First make sure the uugetty timeout is enabled, then, in >your progam, simply get the process ID number FROM the lockfile and check to >see if the process exists. If the process does not exist, then remove the >lockfile, since it is invalid. > >An easy way to do this is > >if ps -p `cat -s $LCKFILE` > /dev/null >then > : # don't remove lockfile > else > rm $LCKFILE >fi On our system, /usr/spool/locks is owned by uucp, group uucp, with drwxr-xr-x permissions. (As best I can tell, this is standard for AT&T 3B2 V.3.1 and ISC 2.0.2) To me, it appears that this script will only work for scripts run as uucp or the permissions on /usr/spool/locks have been changed. We have a software application that needs direct access to modems and does not use cu or uucp. We tried dial(3), but it's broken (still makes reference to L.sys for a HDB uucp environment -- AT&T Hotline says it's not going to be fixed). Our solution was to write a small program that is suid to uucp and does nothing but create (with the correct format) and remove lock files. We had to take this approach because our original solution (chmod o+w /usr/spool/locks raised the ire of some administrators). I'd like to know what the permissions are on other systems (both the installation permssions and what most administrators change them to) and if anyone else has a better solution to the problem. > [ shell script deleted ] > >Good luck, > >Randy Davis UUCP: rjd@ninja.dell.com > -- Mike Verstegen Domain Systems, Inc Voice +1 407 686-7911 ..!uunet!comtst!mdv 5840 Corporate Way #100 Fax +1 407 478-2542 mdv@domain.com West Palm Beach, FL 33407
mmengel@cuuxb.ATT.COM (~XT6561110~Marc Mengel~C25~M27~6184~) (09/12/90)
In article <384@fe2o3.UUCP> michael@fe2o3.UUCP (Michael Katzmann) writes: >This program looks to see if a lockfile is present /usr/spool/locks/LCK..tty1, >before blindly writting out to the line. > >The problem: > uugetty seems to create a lockfile ... >Any ideas anyone? Your confusion is common; actually a uucp lock file is only valid if the process whose id is written in the lock file is still running. What usually happens is that a uugetty sees some data, locks the port to let someone log in, then times out and exits, and a new uugetty is respawned. The LCK..ttyxx file lis left there, but has the process id of the old uugetty in it. This is important to have happen because a uugetty will exec a login who will exec a shell, none of whom have any idea the lock file is there; but they still need it locked. Since they are exec-ed however, they will have the same process id and the lock will be valid. To check if a uucp lock file is valid you have to read the pid from the file, and try a kill(pid,0) to see if the process exists. If it doesn't, you unlink() the lock file and open(...O_EXCL) your own, and write your own pid in it. On the other hand, to do things like chat with a modem, you can write a real simple shell script with "cu" (which knows all the lock file conventions, etc.) by just doing something like: +----------------------- |cu -l /dev/ttyxx <<EOF |ATS0=1 |~!sleep 1 |EOF +----------------------- and save yourself lots of programming... -- Marc Mengel mmengel@cuuxb.att.com attmail!mmengel ...!{lll-crg|att}!cuuxb!mmengel