HardenedBSD/usr.bin/chat

I run PPP between crappie.morningstar.com (137.175.6.3, my home
machine) and remora.morningstar.com (137.175.2.7, my workstation at
the office).  This document describes how I use it.  The installation
of PPP itself is covered in the PPP distribution.

I put a line like this in remora's /etc/passwd:

 Pkarl:2y4613BDaQD3x:51:10:Karl's PPP login:/tmp:/usr/local/etc/pppstart

I created a login shell script on remora called
/usr/local/etc/pppstart:

 #!/bin/sh
 /usr/bin/mesg n
 stty -tostop
 exec /usr/local/etc/ppp 137.175.2.7:

I use the ppp-on command to bring up a connection, and ppp-off to shut
it down.  These shell scripts, plus the unlock and fix-cua scripts and
the source to the chat program are included.  You will need to heavily
modify these to suit your own situation, including Internet addresses,
machine names, telephone numbers, modem dialing commands, baud rates,
login names and passwords.  Make the "ppp..." command in the ppp-on
script look something like this:

 ppp 137.175.6.3: /dev/cua &

The "137.175.6.3:" is of the format "local-addr:remote-addr" with the
remote address null (it will be negotiated by PPP).  Look at the login
shell script above; it can be common to all dial-in PPP users on your
machine because it only specifies the address of the remora
(receiving) end of the link.

If you use the enclosed chat and unlock programs, be sure they are
suid uucp, and fix-cua should be suid root.  The ppp-on script should
be chmod 700, owner yourself, to keep the password (semi-) secure.

I use the following eeprom settings and /dev and /etc/ttytab entries
in order to support dial-in and dial-out on a single phone line:

 crappie 12% eeprom | grep ttya
 ttya-mode=19200,8,1,n,h
 ttya-rts-dtr-off=false
 ttya-ignore-cd=false
 crappie 13% ls -lg /dev/cua /dev/ttya
 crw-rw-rw-  1 root     staff     12, 128 Nov 20 09:14 /dev/cua
 crw--w--w-  1 root     wheel     12,   0 Nov 20 08:25 /dev/ttya
 crappie 14% grep ttya /etc/ttytab
 ttya    "/usr/etc/getty std.19200"      unknown         on
 crappie 15%

On SunOS 4.1 and later, make sure that the /etc/ttytab line for ttya
doesn't say "local":

  ttya	"/usr/etc/getty std.38400"	unknown		on

Make sure your modem passes data transparently; watch out especially
for ^S, ^Q, ^P (UUCP spoofing) and parity problems.  I have a Telebit
Trailblazer+ attached to /dev/ttya with the following register
settings:

 aaatz
 OK
 aat&n
 E1 F1 M1 Q6 P V1 X0     Version BA4.00
 S00=001 S01=000 S02=043 S03=013 S04=010 S05=008 S06=002 S07=060 S08=002 S09=006
 S10=007 S11=070 S12=050 
 S45=000 S47=004 S48=000 S49=000
 S50=000 S51=005 S52=002 S53=003 S54=001 S55=000 S56=017 S57=019 S58=002 S59=000
 S60=000 S61=000 S62=003 S63=001 S64=000 S65=000 S66=001 S67=000 S68=255 
 S90=000 S91=000 S92=001 S95=000 
 S100=000 S101=000 S102=000 S104=000 
 S110=001 S111=030 S112=001 
 S121=000 
 N0:
 N1:
 N2:
 N3:
 N4:
 N5:
 N6:
 N7:
 N8:
 N9:
 OK

And, the following entry is in /etc/gettytab:

 #
 # 19200/2400 dialin for Telebit Trailblazer+ modem
 #
 T|T19200:dial-19200:\
         :nx=T2400:sp#19200:
 T2400|dial-2400:\
         :nx=T19200:sp#2400:

My chat script dialing command looks like "ATs50=255s111=0DT4515678"
instead of just "ATDT4515678" in order to force a PEP mode connection
and to disable the UUCP spoofing (otherwise, the modem swallows or
delays ^P characters).

I run /usr/etc/in.routed on crappie (the calling end) and have this in
my /etc/gateways file:

 net 0.0.0.0 gateway remora metric 1 passive
 host crappie gateway crappie metric 0 passive

Routed is started in /etc/rc.local.  This way, I don't have to
manually add or delete routes when links come up.  I ifconfig the ppp0
interface on crappie at boot time like this (in /etc/rc.local with the
other ifconfig's):

 ifconfig ppp0 crappie remora netmask 0xffffff00 down

I put "init ppp_attach" in my /sys/sun4c/conf/CRAPPIE file so that the
above ifconfig down will work:

 pseudo-device   ppp1 init ppp_attach # Point-to-Point Protocol, 1 line

Routed now keeps my routes sane at the crappie.MorningStar.Com end.

My ethernet (le0) and PPP (ppp0) interfaces are configured with the
same address and netmask.  IP is smart enough to figure out (via the
routes in /etc/gateways) that everything useful needs to go out ppp0.
Also, the remora end of my PPP link is configured the same way -- the
ppp0 interface there is configured with the same address and netmask
as remora's le0 ethernet.  This means that separate interface names
like "remora-ppp" are not needed; point-to-point links (whether PPP,
Xerox Synchronous Point-to-Point Protocol, SLIP, IGP or whatever) have
(apparently) been used this (seemingly bizarre) way for some time.
This works because when IP looks at a POINTOPOINT link it ignores the
local address (unlike an ethernet interface) and only looks at the
remote address.

Here's what netstat shows for me:

 crappie 109% netstat -r
 Routing tables
 Destination          Gateway              Flags    Refcnt Use        Interface
 localhost            localhost            UH       0      0          lo0
 crappie              crappie              UH       1      11339      le0
 default              remora               UG       0      1266       ppp0
 mstar-net-ppp-remora crappie              U        0      0          le0
 crappie 110% netstat -rn
 Routing tables
 Destination          Gateway              Flags    Refcnt Use        Interface
 127.0.0.1            127.0.0.1            UH       0      0          lo0
 137.175.6.3          137.175.6.3          UH       1      11339      le0
 default              137.175.2.7          UG       0      1266       ppp0
 137.175.6.0          137.175.6.3          U        0      0          le0
 crappie 111% 

The default route to remora is a result of the first line in the
/etc/gateways file ("default" can't be used there; you have to say
"0.0.0.0").

On the network at work, I add a static route in our gateway machine's
/etc/rc.local file:

 /usr/etc/route add net 137.175.6 remora 1

All the other machines in the office have default routes pointing at
the gateway machine, and all PPP-connected external machines are on the
137.175.6 subnet.

Send me mail or post to the newsgroup comp.protocols.ppp if you have
any questions.

Karl Fox <karl@MorningStar.Com>