[comp.unix.microport] Dropping DTR?

mdm@cocktrice.UUCP (Mike Mitchell) (01/22/89)

Does anyone have a fancy trick for lowering DTR going to a modem attached
to tty0? I have my modem set up to auto answer, however there are times
that I do not want the modem to answer the phone.

I can start a getty running on /dev/ttyM0 and the DTR comes up. When I kill
the getty, the DTR drops for a moment and then comes up again. The modem
still answers the phone, but there is nothing running to accept logins.

If I do not run a getty, the DTR behaves "properly" when making outgoing
calls. UUCP will dial out and connect and when it is finished the DTR is
dropped when /dev/tty0 is closed.
-- 
Mike Mitchell				BELL:	(505) 471-7639
2020 Calle Lorca #43			ARPA:	mdm@cocktrice.UUCP
Santa Fe, NM 87505			UUCP:	...!uunet!dmk3b1!cocktrice!mdm

rick@pcrat.UUCP (Rick Richardson) (01/23/89)

In article <362@cocktrice.UUCP> mdm@cocktrice.UUCP (Mike Mitchell) writes:
>Does anyone have a fancy trick for lowering DTR going to a modem attached
>to tty0? I have my modem set up to auto answer, however there are times
>that I do not want the modem to answer the phone.

I timeshare a line for voice (daytime) and data (nightime).  What I
do is to leave getty running all the time.  But, twice a day, I
have cron fire off a program which sends the turn on/off auto answer
sequence to the modem.  The program, of course, obeys the same
locking protocol as UUCP, so that there won't be any conflicts.

This works well, and since the modem has non-volatile memory I
don't have to worry what state the modem is in should the power
fail.

Come to think of it, you could probably come up with a solution
which involved only a special Dialer type and two phony System
entries.  The UUCP Poll file would fire off a "call" to
the phony systems to turn on/off the autoanswer.  No programming
necessary.

-- 
Rick Richardson | JetRoff "di"-troff to LaserJet Postprocessor|uunet!pcrat!dry2
PC Research,Inc.| Mail: uunet!pcrat!jetroff; For anon uucp do:|for Dhrystone 2
uunet!pcrat!rick| uucp jetroff!~jetuucp/file_list ~nuucp/.    |submission forms.
jetroff Wk2200-0300,Sa,Su ACU {2400,PEP} 12013898963 "" \d\r\d ogin: jetuucp

bill@ssbn.WLK.COM (Bill Kennedy) (01/23/89)

I started to mail this but I thought that it might be useful since some
might be sharing a voice line with a modem.

In article <362@cocktrice.UUCP> mdm@cocktrice.UUCP (Mike Mitchell) writes:
>Does anyone have a fancy trick for lowering DTR going to a modem attached
>to tty0? I have my modem set up to auto answer, however there are times
>that I do not want the modem to answer the phone.

The obvious things would be to unplug either the phone line or serial cable
from the modem, but those leave you vulnerable to forgetting to plug them
back in.  You could also arm and disarm with

echo "ATQ1S0=0" > /dev/ttyM0      to disarm it and the reverse to rearm it.

If you're going to do it this way, make sure that you use the Q1 so that the
modem doesn't torture the getty with result codes that the phone is ringing.

>I can start a getty running on /dev/ttyM0 and the DTR comes up. When I kill
>the getty, the DTR drops for a moment and then comes up again. The modem
>still answers the phone, but there is nothing running to accept logins.

That's odd.  The first part is quite understandable because init spawns a
new getty when the old one dies, but it should prompt for a login, i.e. it
should be a shiny new getty ready to go.

>If I do not run a getty, the DTR behaves "properly" when making outgoing
>calls. UUCP will dial out and connect and when it is finished the DTR is
>dropped when /dev/tty0 is closed.

You need to alter the inittab to not respawn the getty and then you need
to kill the getty itself, see below.

>-- 
>Mike Mitchell				BELL:	(505) 471-7639
>2020 Calle Lorca #43			ARPA:	mdm@cocktrice.UUCP
>Santa Fe, NM 87505			UUCP:	...!uunet!dmk3b1!cocktrice!mdm

I have the same problem from time to time when I need the voice line to do
double duty, particularly at night.  It's also rather handy to have the
modem to answer late night calls when I don't want to be disturbed.  I run
a job with cron that arms and disarms a modem on the voice line.  Using the
following inittab line as an example -

T0:23:respawn:/etc/getty ttyM0 2400

#
# disarm ttyM0, runs from cron at 0630 each morning
#
#   Start by changing the /etc/inittab line from respawn to off
#
TMP=/tmp/tty$$
chmod u+w /etc/inittab
ed - /etc/inittab <<'EOF'
/T0/s;respawn;off;
w
q
EOF
chmod u-w /etc/inittab
#
#   Now find and kill the getty, this is modified from
#   what I use to kill all uugetty's that are active.
#
ps -e | grep getty > $TMP
if [ -s $TMP ]
then
	cat $TMP | while read pid tty time command
	do
		if [ "ttyM0" = "$tty" -a "getty" = "$command" ]
		then
			set - $pid; pid=$1; kill -9 $pid
		fi
	done
fi
rm -f $TMP
chmod /etc/inittab u-w

Now something similar to arm the port.

#
#   arm ttyM0, run from cron at 2330
#
#   All we have to do is change off to respawn and
#   tell init to look at inittab again.
#
chmod u+w /etc/inittab
ed - /etc/inittab <<'EOF'
/T0/s;off;respawn;
w
q
EOF
chmod u-w /etc/inittab
/etc/telinit q

Since it requires root permissions to modify /etc/inittab I will leave
the cron line up to the reader.  I'm ASSuming that Mike's system is like
mine, a small one where the owner can pretty much do as they please.
There are probably some undesirable side effects to such brute force in
a different environment but the technique has worked well on my systems.
-- 
Bill Kennedy  usenet      {killer,att,cs.utexas.edu,sun!daver}!ssbn!bill
              internet    bill@ssbn.WLK.COM

vjs@calcite.UUCP (Vernon Schryver) (01/23/89)

In article <362@cocktrice.UUCP>, mdm@cocktrice.UUCP (Mike Mitchell) writes:
> Does anyone have a fancy trick for lowering DTR going to a modem attached
> to tty0? I have my modem set up to auto answer, however there are times
> that I do not want the modem to answer the phone.
> 
> I can start a getty running on /dev/ttyM0 and the DTR comes up. When I kill
> the getty, the DTR drops for a moment and then comes up again.

There seem to be bugs in the 3.0e driver.  If you ever use tty[Mm][01], the
driver decides that you want DTR high forever after.  Other bugs include a
failure to flush input buffers on the last close.  Worse is a failure to
forget about XOFF (^S) on the last close.  The latter means that noise
which looks like ^S during cu(1) (which follows the stupid SVR3 practice of
absolutely insisting on setting IXON -IXANY IXOFF) can lock up a port
permanently, until you reboot or until you run a program which does an
ioctl(TCXONC).  You can't fix it with ioctl(TCSETA), turning off IXON &
IXOFF; the TCSETA will hang!  The absense of RTS/CTS flow control should
be considered a bug today, no matter what RS-232-C said 15(?) years ago.

For the DTR bug, I found the enclosed hack/kludge/script works.  It bangs
on the port enough times to convince the driver.  Not having seen the
driver source, I can only guess why it works.  All of its weirdness seem to
be necessary in various cases.  It seems to work on an Everex 386/20 and a
no-name 16MHz.  I've used it to run getty only at night.  It is run by cron
every 15 minutes at night (don't ask) and once in the morning.  It could
obviously stand some cleaning and generalizing, but it would be better to
spend the time fixing the driver.  If you use it as is, you'll want to
create the extra inittab's.

If you have something simpler (like a reasonable driver for 3.0e+DOSMerge),
please let me know.

Vernon Schryver
{sgi,pyramid}!calcite!vjs


#!/bin/sh  #(wishing we had a real csh and/or the uts/*/os/exec.c hacks)
#
# turn modem off or on

usage="usage: $0 {on | off}"

set -e
if test $# != 1; then
	echo "$usage"
	exit 1
fi

trap "" 1

case $1 in
'on')
	cp /etc/inittab.on /etc/inittab
	/etc/telinit q
	;;

'off')
	if cmp -s /etc/inittab.off /etc/inittab; then 
		exit 0
	fi
	cp /etc/inittab.off /etc/inittab
	set +e

	/etc/telinit q
	sleep 4

	#reset DTR
	PORT=01
	exec > /dev/null 2>&1

	stty < /dev/ttyM$PORT &
	sleep 1; kill -9 $!; wait 2> /dev/null; sleep 2

	stty < /dev/ttyM$PORT &
	sleep 1; kill -9 $!; wait 2> /dev/null; sleep 2

	stty < /dev/tty$PORT

	stty < /dev/ttyM$PORT &
	sleep 1; kill -9 $! 2> /dev/null; wait 2> /dev/null; sleep 2

	stty < /dev/tty$PORT
	;;

*)
	echo "$usage"
	exit 1
	;;
esac

mdm@cocktrice.UUCP (Mike Mitchell) (01/23/89)

In article <916@ssbn.WLK.COM> bill@ssbn.WLK.COM (Bill Kennedy) writes:
>In article <362@cocktrice.UUCP> mdm@cocktrice.UUCP (Mike Mitchell) writes:
>>Does anyone have a fancy trick for lowering DTR going to a modem attached
>>to tty0? I have my modem set up to auto answer, however there are times
>>that I do not want the modem to answer the phone.
>
>The obvious things would be to unplug either the phone line or serial cable
>from the modem, but those leave you vulnerable to forgetting to plug them
>back in.  You could also arm and disarm with

Not a good solution. I would forget.

>>I can start a getty running on /dev/ttyM0 and the DTR comes up. When I kill
>>the getty, the DTR drops for a moment and then comes up again. The modem
>>still answers the phone, but there is nothing running to accept logins.
>
>That's odd.  The first part is quite understandable because init spawns a
>new getty when the old one dies, but it should prompt for a login, i.e. it
>should be a shiny new getty ready to go.

Init is not envolved yet at this stage. I was hand spawining the getty as
an exercise from the console to insure that it works.

>I have the same problem from time to time when I need the voice line to do
>double duty, particularly at night.  It's also rather handy to have the
>modem to answer late night calls when I don't want to be disturbed.  I run
>a job with cron that arms and disarms a modem on the voice line.  Using the
>following inittab line as an example -

A little more elegant way of doing this is to have the getty run at run
state 3 only and just 'telinit 3' to fire it up, and 'telinit 2' to get
rid of it. However this is not the mode I have been using (yet). The getty
was spawned from the root login on the console. It behaved properly for a
single login (to be expected) and when the login was terminated, the DTR
only dropped for a moment. A new getty was not spawned, however the DTR
came back up.

This exercise is to allow me to share the single phone line for voice and
data. I want my calls in the evening, however I would like to be able to
dial in from work during the day.

The brute force solution for this problem is in the works... Open /dev/mem
and perform a couple of ioctls which would dump the magic modem bytes to the
UART line control register to disable the DTR. Calls to this program would
then be made from the 'gettyoff' shell script. This is not a real pretty 
solution though. I kind of feel like the kernel should do this for me.
(And maybe it can--I am not sure how to massage it into happiness).




-- 
Mike Mitchell				BELL:	(505) 471-7639
2020 Calle Lorca #43			ARPA:	mdm@cocktrice.UUCP
Santa Fe, NM 87505			UUCP:	...!uunet!dmk3b1!cocktrice!mdm

learn@igloo.UUCP (william vajk) (01/24/89)

> >In article <362@cocktrice.UUCP> mdm@cocktrice.UUCP (Mike Mitchell) writes:

> >>Does anyone have a fancy trick for lowering DTR going to a modem attached
> >>to tty0? I have my modem set up to auto answer, however there are times
> >>that I do not want the modem to answer the phone.

It is an easy matter to reset most modems to ignore auto answer. I only
buy modems which have S0 as a software settable function.

If someone is on the line when cron strikes get_off, there is at least
one PD pkill routine (kill process by name) that can be run as part of
a script called by cron.

If your modem has S0 writable, there's probably no good reason to
use dropping DTR as a means of locking out the system from incoming 
calls.


Bill Vajk            |  Eventually SOMEBODY's going to put SOMETHING
learn@igloo          |  I SAY in a .sig.  -Allen Gwinn

jiii@visdc.UUCP (John E Van Deusen III) (01/26/89)

Intelligent modems like the TB+ have a command mode, and you can write a
supervisor program that is respawned by init and deals with the modem at
the command level.  You can allow the modem to answer a call and, upon
establishing a connection, exec(2) getty(1M), and so on.  If you don't
want to answer the line, the program could sleep and periodically check
a status file, (this assumes that there exists some method to prevent
the modem from answering the line.  With the TB+ the S0 register is
assigned the value 0).

The supervisor program can also be written to support the resource
locking facilities of uucp.  The line can be available for login and
still used for outgoing calls.  Since the supervisor program doesn't
exec getty until a connection is made, you don't have the problem of
getty trying to assert login.  This also would work on serial ports
that don't support DTR.
--
John E Van Deusen III, PO Box 9283, Boise, ID  83707, (208) 343-1865

uunet!visdc!jiii

jr@oglvee.UUCP (Jim Rosenberg) (01/28/89)

In article <362@cocktrice.UUCP> mdm@cocktrice.UUCP (Mike Mitchell) writes:
>I can start a getty running on /dev/ttyM0 and the DTR comes up. When I kill
>the getty, the DTR drops for a moment and then comes up again. The modem
>still answers the phone, but there is nothing running to accept logins.

The "book" way of dropping DTR is supposed to be stty 0.  On our Altos 2000
with Xenix System V I have to do this to zap DTR after a uucico dial-out.  What
happens when you try

stty 0 </dev/ttyM0

??  If this doesn't work then for my $.02-worth I'd say the driver's broke.
-- 
Jim Rosenberg                        pitt
Oglevee Computer Systems                 >--!amanue!oglvee!jr
151 Oglevee Lane                      cgh
Connellsville, PA 15425                                #include <disclaimer.h>

chuck@laffu.UUCP (Chuck Sites) (01/28/89)

In article <362@cocktrice.UUCP>, mdm@cocktrice.UUCP (Mike Mitchell) writes:
> Does anyone have a fancy trick for lowering DTR going to a modem attached
> to tty0? I have my modem set up to auto answer, however there are times
> that I do not want the modem to answer the phone.
This is what I've been doing to toggle between an auto answer, and
dial-in on Hayes type modems with uPORT. There is no Makefile with
this program, but It should be pretty easy to set up.  Look at the
shell scripts dismdm & enamdm for the directories to place
the programs modemctl, tty.on & tty.off.  To compile modemctl.c
a simple:

cc -O modemctl.c -o modemctl

will do.  You may need to change some of the parameters in
modemctl.c when setting up the ioctl call. Look at the program
if you need baud rates other than 2400.  The shell scripts I'm
using here are pretty laim, so you may want to beef these up.
At work, we are using the same modemctl.c program, but with some
much improved shell scripts to control seven different modems.
With the addition of a cron job or two, it's pretty easy to have
one of these Hayes type modems doing all kinds of wierd things
in the middle of the night :-)
----------------------- CUT HERE-----------------------------
#! /bin/sh
# This is a shell archive, meaning:
# 1. Remove everything above the #! /bin/sh line.
# 2. Save the resulting text in a file.
# 3. Execute the file with /bin/sh (not csh) to create the files:
#	dismdm
#	enamdm
#	modemctl.c
#	tty.off
#	tty.on
# This archive created: Fri Jan 27 19:17:30 1989
export PATH; PATH=/bin:$PATH
if test -f 'dismdm'
then
       echo shar: will not over-write existing file "'dismdm'"
else
cat << \SHAR_EOF > 'dismdm'
#Disable modem port from logins
/etc/tty.off t0
/usr/lib/uucp/modemctl "AT,ATE1,ATS0=0"
chown uucp /dev/tty0
chgrp bin /dev/tty0
echo "** Disable Modem at `date '+%r on %D'` **" >> /usr/spool/uucp/LOGFILE
SHAR_EOF
chmod +x 'dismdm'
fi # end of overwriting check
if test -f 'enamdm'
then
       echo shar: will not over-write existing file "'enamdm'"
else
cat << \SHAR_EOF > 'enamdm'
#Enable modem for logins
/usr/lib/uucp/modemctl -c "ATE0,ATS0=1"
/etc/tty.on t0
echo "** Enable Modem at `date '+%r on %D'` **" >> /usr/spool/uucp/LOGFILE
SHAR_EOF
chmod +x 'enamdm'
fi # end of overwriting check
if test -f 'modemctl.c'
then
       echo shar: will not over-write existing file "'modemctl.c'"
else
cat << \SHAR_EOF > 'modemctl.c'
#include <stdio.h>
#include <errno.h>
#include <fcntl.h>
#include <termio.h>
extern int errno;

/* #define DEBUG  /* envoke debug outbut */

#ifndef TRUE
#define TRUE 1
#define FALSE 0
#endif

typedef int bool;

char device[40]="/dev/tty0";
char wakeup[]="\r\rAT\r\rAT\r\r";
char command[132];
char cm[40];

main(argc,argv) int argc; char *argv[]; {

        struct termio buf,obuf;
        int fd,argcnt;
        int i,j,issue;
        bool clocal;

        char c;
        
        if (argc<2) {
                fprintf(stderr,"USAGE: modemctl [-c] [-T/dev/tty##] \"Hayse AT command string\"\n");
                exit(1);
        }
        argcnt=1;
        if(*(argv[1]+0)=='-' && *(argv[1]+1)=='c') {
                ++argcnt; 
                clocal=TRUE;
        } else
                clocal=FALSE;

                
        if(*(argv[argcnt]+0)=='-' && *(argv[argcnt]+1)=='T') {
                strncpy(device,argv[argcnt]+2,40);
                ++argcnt;
        }               
#ifdef DEBUG
        printf("%s\n%s\n%s\n",argv[1],device,argv[2]);
#endif  
        fd=open(device,O_NDELAY);
        sleep(2);                       /* Toggle DTR line ON/OFF */
        close(fd);                      /* to wakeup modem.       */
        sleep(1);

        if ((fd=open(device,O_NDELAY|O_RDWR))<0) {
                perror("Modemctl error");
                exit(1);
        }
        ioctl(fd,TCGETA,&buf);
        ioctl(fd,TCGETA,&obuf);
#ifdef DEBUG
        printf("iflag=%o\noflag=%o\ncflag=%o\nlflag=%o\n\n",buf.c_iflag,buf.c_oflag,buf.c_cflag,buf.c_lflag);
#endif

        buf.c_iflag = (IGNBRK | IGNPAR | IXON | IXOFF);
        buf.c_oflag = 0;
        buf.c_cflag = (B2400 | CS8 | CREAD | CLOCAL | HUPCL);
        buf.c_lflag = 0;
        ioctl(fd,TCSETA,&buf);
        ioctl(fd,TCFLSH,2);
        close(fd);
        sleep(1);

/* second pass at opening file */ 

        if ((fd=open(device,O_NDELAY|O_RDWR))<0) {
                perror("Modemctl error");
                exit(1);
        }
        ioctl(fd,TCGETA,&buf);
        ioctl(fd,TCGETA,&obuf);

#ifdef DEBUG
        printf("iflag=%o\noflag=%o\ncflag=%o\nlflag=%o\n\n",buf.c_iflag,buf.c_oflag,buf.c_cflag,buf.c_lflag);
#endif

        buf.c_iflag = (IGNBRK | IGNPAR | IXON | IXOFF);
        buf.c_oflag = 0;
        buf.c_cflag = (B2400 | CS8 | CREAD | CLOCAL | HUPCL);
        buf.c_lflag = 0;

        ioctl(fd,TCSETA,&buf);
        ioctl(fd,TCGETA,&buf);

#ifdef DEBUG
        printf("iflag=%o\noflag=%o\ncflag=%o\nlflag=%o\n\n",buf.c_iflag,buf.c_oflag,buf.c_cflag,buf.c_lflag);
#endif
        sleep(1);
        /* issue command to modem */
        write(fd,wakeup,strlen(wakeup));
        ioctl(fd,TCFLSH,0);

        sleep(3);
        strcpy(command,argv[argcnt]);
#ifdef DEBUG
        printf("command=%s\n",command);
#endif
        i=0,j=0;
        issue=0;
        
        while (command[i] != 0) {
                cm[j]=command[i];
                if (cm[j]==',') {
                        cm[j]='\r';
                        cm[++j]=0;
                        write(fd,cm,j);
                        sleep(2);
                        ioctl(fd,TCFLSH,0);
#ifdef DEBUG
                        sleep(1);
                        printf("issue(%d)=%s\n",++issue,cm);
#endif
                        j=0;
                } else 
                        ++j;

                ++i;
        }
        cm[j]='\r';
        cm[++j] = 0;
        write(fd,cm,j);
        sleep(2);
        ioctl(fd,TCFLSH,0);
#ifdef DEBUG
        printf("issue(%d)=%s\n",++issue,cm);
#endif

        buf.c_iflag = ( BRKINT | IGNPAR | IXON | ICRNL | ISTRIP);       /* make the tty sane */
        buf.c_oflag = (OPOST | TAB3 | ONLCR );
        buf.c_lflag = (ISIG | ICANON | ECHO | ECHOE | ECHOK );
        if (clocal != TRUE) buf.c_cflag &= ~CLOCAL;

        ioctl(fd,TCSETA,&buf); 
        sleep(1);
        close(fd);
        sleep(2);
        
        fd=open(device,O_NDELAY);
        sleep(2);                       /* Toggle DTR line ON/OFF */
        close(fd);                      /* to wake up modem.      */
        sleep(1);
        
}       
SHAR_EOF
chmod +x 'modemctl.c'
fi # end of overwriting check
if test -f 'tty.off'
then
       echo shar: will not over-write existing file "'tty.off'"
else
cat << \SHAR_EOF > 'tty.off'
# TTY.OFF turns respawn of terminal line off.
# 1.1(1987) Copper Electronics Inc.
#

if [ $# -eq 0 ]
then
   echo "Usage: $0 tty#"
   echo "Example: 09=tty9, mo=modem, ect."
   exit 1
fi

trap "" 1 2 3 15
/bin/sed /$1:/s/respawn/off/g /etc/inittab > /etc/inittab.old
mv /etc/inittab.old /etc/inittab
chmod +r /etc/inittab
/bin/telinit q
trap 1 2 3 15
SHAR_EOF
chmod +x 'tty.off'
fi # end of overwriting check
if test -f 'tty.on'
then
       echo shar: will not over-write existing file "'tty.on'"
else
cat << \SHAR_EOF > 'tty.on'
# TTY.ON turns respawn of terminal line on.
# 1.1(1987) Copper Electronics Inc.
#

if [ $# -eq 0 ]
then
   echo "Usage: $0 tty#"
   echo "Example: 09=tty9, mo=modem, ect."
   exit 1
fi

trap "" 1 2 3 15
/bin/sed /$1:/s/off/respawn/g /etc/inittab > /etc/inittab.old
mv /etc/inittab.old /etc/inittab
chmod +r /etc/inittab
/bin/telinit q
trap 1 2 3 15

SHAR_EOF
chmod +x 'tty.on'
fi # end of overwriting check
#	End of shell archive
exit 0

-- 
   "Nothing can be made fool proof because fools are just too damned clever"  
______________________________________________________________________________
  . . . .  AUTHOR: Chuck Sites @ The Louisville Area Forum For Unix  . . . .  
 o o o o o   UUCP: {mit-eddie}!bloom-beacon!coplex!chuck            o o o o o 
O O O O O O   ATT: (502)454-7218               \laffu!chuck        O O O O O O
______________________________________________________________________________

mdm@cocktrice.UUCP (Mike Mitchell) (02/01/89)

In article <461@oglvee.UUCP> jr@.UUCP (Jim Rosenberg) writes:
>In article <362@cocktrice.UUCP> mdm@cocktrice.UUCP (Mike Mitchell) writes:
>>I can start a getty running on /dev/ttyM0 and the DTR comes up. When I kill
>>the getty, the DTR drops for a moment and then comes up again. The modem
>>still answers the phone, but there is nothing running to accept logins.
>
>The "book" way of dropping DTR is supposed to be stty 0.  On our Altos 2000
>with Xenix System V I have to do this to zap DTR after a uucico dial-out.  What
>happens when you try
>
>stty 0 </dev/ttyM0
>
Tried this one second... Doesn't work. However, someone mailed me a script
that they use to hammer on the port. It performs this quite a few times
in order to bash the port into submission. I have not tried the script
as I am looking for something less fiendish.

Does anyone have an alternate device driver available? (If someone needs
a alpha site for a driver to test 16550A's, I have one port equipped with
one.)


-- 
Mike Mitchell				BELL:	(505) 471-7639
2020 Calle Lorca #43			ARPA:	mdm@cocktrice.UUCP
Santa Fe, NM 87505			UUCP:	...!uunet!dmk3b1!cocktrice!mdm