SuSE Support Database

Title: PPP at NT server, howto

---

Mainpage ---- Searchform ---- History ---- Versions ---- Categories ---- Contents
Deutsch
---

PPP at NT server, howto

Best thanks to Sigi Schön (sigi@f30x.erl.scn.de), which has made the following howto. (At present still not nicely formatted, but coming soon...)
_______________________________________________________________________________ 
... not by PaPPe  - a whole bloke thanks to CHAP :

LINUX PPP client on PAP/CHAP at WINDOWS NT server
_______________________________________________________________________________ 

Behind PPP ('Point to Point Protocol') hides a mechanism,
that makes possible to build IP (Internet Protocol) connections between 2 
computers on a modem connection.

The Linux's Kernel operating system contains a driver for the PPP proto-
col that must be mostof the times activated first. The real PPP
connections are established under Linux on an own daemon, the 'pppd'.

The conditions for the PPP support under Linux as well as the fundamental
PPP connection establishment between 2 computers are explained among 
others in [1], the Linux User's Handbook [2], the Linux Network Administrator
Guide [3] and in Linux PPP HOWTO document [4].

PPP makes theoretically possible not only a connection between Unix Hosts, 
but as well a bond between a Linux computer and a Windows NT server
(Windows NT 3.51) on the so-called 'Remote Access Service' (RAS).

To establish such a connection, some fundamental conditions are to be 
observed: 

- of course it is needed a valid userlogin on the Windows NT Server. 
- Windows NT offers different functionalities in its RAS:
         - PPP access with any authentication system
           (Clear text, MS-CHAP, MD-CHAP, SPAP, PAP),
            where the protocols to be mentioned here are
             PAP  ('Password Authentication Protocol') and
             MS-CHAP, a Microsoft CHAP extension
                  ('Challenge Handshake Authentication Protocol').
         - 'Callback Feature' (Callback through Windows NT server):
             Many Windows NT servers use the so-called "Microsoft Call 
             Back Configuration Protocol' (CBCP) to reach an additonal 
             security standard: the concerning Windows NT
             server will pass during the contact establishment a 
             phone number, at which it calls back.
         - Limitation on MS-CHAP authentication:
             The access to Windows NT server only contains clients, that can 
	     authenticate themselves on MS-CHAP.

If such a PPP connection situation arrives, the following 
activities should be able to be regulated:
         - Client IP address's static allocation; i.e. the Windows NT 
	   server does not allocate any dynamic IP addresses.
         - Access of the Linux systems connected with the Windows NT on 
	   PPP to another Unix computers, that are located together with the
           Windows NT server in the same net. 
         - The use of the 'Domain Name Services" (DNS), available in this 
	   net through the Linux system.

To fulfill the current security demands, a corresponding
dialling procedure use should be found:
         - MS-CHAP authentication with Callback Feature's use.

The question of whether and in which way such a connection can be 
established between Linux and Windows NT, arises now.

The 'easiest' case (PPP access with any authentication system)
appears at the first sight realizable without much of an effort, since Linux
has already prepared the required module in the system.

First the Windows NT system manager must be convinced to configure TCP/IP
in the Windows NT Remote Access Service under 'Network Configuration' at
'Server settings' and to activate at the 'Encryption settings'
the option 'Allow any authentication including clear text'.

Once this hurdle is taken, it must be explained, that
Windows NT-RAS uses for the clients' logging in (Linux clone) PAP/CHAP for 
authentication instead of the "Login:/Password:" algorithm as the usual 
way. A look at the 'pppd' man pages
convinces of it, that PAP/CHAP is supported by this. 

However, another picture arises at the Callback Feature's use
by Windows NT: 'pppd' does not deliver any hint supporting this
option.

Luckily, a couple of the corresponding patches are located in the 'pppd' 
packages' sources, to inform to the Windows NT server during the PPP 
connection establishment about the corresponding phone number, at which
the callback takes place.
To use this Callback Feature the patch README.cbcp, enclosed in the package, 
must be recorded. Unfortunately this patch is not applicable to the 
'pppd' version (ppp-2.2-0f) enclosed in the used Linux distribution.
Therefore an automatic recording is only partly possible. The rest is to 
be carried out by hand. 

Unfortunately this 'pppd' version does not support by default the 
MS-CHAP protocol either. A patch (README.mschap80) enclosed in the package, 
that makes possible a "cient-only" MS-CHAP implementation, should 
compensate this deficiency.

MS-CHAP uses a combination of "MD4 hashing" and DES encoding.
To be able to use the MS-CHAP extension with 'pppd' a special
DES library: Eric Youngs's DES library is required. To be found in 
ftp://ftp.psy.uq.oz.au/pub/Crypto/DES/libdes-3.06.tar.gz.

After this library's creation and installation, the 'pppd' daemon can 
be translated again after the mentioned patches' recording.  
At this point is to be observed, along with the instructions in the file 
README.mschap80 under "BUILDING THE PPPD" (use absolutely option 
-DUSER_MSCAHP), the chapter INSTALLATION in the file README.linux: The 
listed points 2 until 4 (kernel compilation) are not executed, since the 
current 'ppp' driver of the 'pppd' is already available as loadable 
kernel modul (kernel 2.0.0).

However, we are not yet done with the patches' recording: It must be 
ensured, that a system's arriving callback is detected, examined,
evaluated and the 'pppd' process is activated during a detected PPP demand.

The supervision of a communication port on demand for a connection 
establishment (by a terminal or a modem) is executed in the rule of the
so-called 'getty' processes, at which for every communication port
on which a login is allowed, an own separated
'getty' process is required.
By 'getty' it is meant a programme that is called by the system's init 
routine (init (1)). It is the second process in
the serie "init-getty-login-shell", with which a user is finally 
connected to a Unix system: 'getty' gives first away a login message,
reads the user's login name and then calls the command   
login(1), to which the username is passed as parameter. 'login'
demands as well a password entry. By reading the names
'getty' tries to adjust the system to the 
entered communication partner's speed and model.

Since, as mentioned, Windows NT does not use the 
"Login:/Password:" algorithm, this method cannot be used. It is necessary 
for this an intelligent 'getty' programme, that controls the modem 
communication, detects a call, uses the PPP and can activate the 'pppd' 
process automatically.

Concerning this, a package named 'mgetty+sendfax 
distribution' (shortly 'mgetty'), that fulfills this demand, is located 
in the Linux sources. The current (Beta) version (mgetty099-Aug07) is in 
http://www.leo.org/~doering/mgetty/index.html.
During the new compilation is to be ensured to activate the PPP mode 
explicitly
(by giving in the makefile for the CFLAGS the option -DAUTO_PPP), in 
order to define the used 'mgetty' configuration directories' path (Definition
 'prefix=' in the makefile) and to adjust the lock file name to 
the 'pppd' one ( Parameter LOCK in policy.h). 
On this lock file the processes 'mgetty' and 'pppd', competing around the 
serial interface for the exclusive access to this device, synchronize.
For this reason the physical device name (e.g.: ttyS0 for COM1) should be 
always declared for the device name defined by these programmes. The lock 
file is in the directory /var/lock and has the name LCK.. 
(i. e. for stty0 LCK..ttyS0). 
With this file, 'mgetty' can take an arrived callback correctly. The 
'AUTOANSWER' mode is to be absolutely deactivated at the connected modem.
 
Before it is got into the required configuration steps under Linux in 
detail, first a description of the available Linux system and 
surrounding configuration:
_______________________________________________________________________________
System description:
-SuSE Linux aktuell! (June '96) with kernel 2.0.0
-Kernel Feature kernelmodule enabled
-Modem connection at UART16550A   sttyS0 (COM1)
-Modem type USR Sportster Vi 28.8
-System name Linux Host          linux
-System name Windows NT          win_nt
-local IP Address (Linux)      152.3.60.1  (static;. i.e. both IP-Addresses  
-remote IP Address (Windows NT) 152.3.60.2   are entered in the local 
-Windows NT User Account        my_login     /etc/hosts file) 
-Windows NT User Password       my_passw
-Windows NT Host Phone Nr.    555222
-Linux Host Phone Nr.         555111
-DNS domain name                 my_office.my_plant.com
-DNS name server address         152.3.60.4
-DNS name server address         152.3.60.5
_______________________________________________________________________________
(Remark: - all identifications, system names, IP addresses etc. are 
ficticious)

_______________________________________________________________________________

Configuration 1: PPP connection in Windows NT with PAP authentication
_______________________________________________________________________________

In this variation the Linux Distribution's enclosed standard 'pppd' 
package can be used. I.e. no changes at all are needed to be done in the 
Linux system installed by default!

For the dialling process a simple script, that starts the 'pppd' process, 
is used.
_______________________________________________________________________________
#!/bin/sh
# Establishing a PPP connection to a Windows NT Server
/usr/sbin/pppd 38400 connect '/usr/sbin/chat -v -f $HOME/win_nt.chat' lock
_______________________________________________________________________________
File: dial_win_nt
_______________________________________________________________________________
Parameter description file dial_win_nt :
38400                   : sets the used port speed
connect '...'           : Modem connection configuration and login in
                          on the programme 'chat', whereas the required 
			  information for the connection establishment are taken
                          from the file declared on the parameter -f. 
                          The 'chat' parameter -v causes a connection 
			  establishment protocolization on 'syslogd' 
                          (file /var/log/messages)
lock                    : The use of a "UUCP conformed" lock file (in
                          /var/lock/LCK..ttyS0)
_______________________________________________________________________________

The parameters for the 'chat' programme are deposited in an own file.
_______________________________________________________________________________
TIMEOUT  60
ABORT "NO CARRIER"
ABORT BUSY
ABORT "NO DIALTONE"
ABORT ERROR
"" +++ATZ 
OK ATE1Q0&C1&S0DT555222
CONNECT ""
_______________________________________________________________________________
File: win_nt.chat

Notticeable at this file is that the usual "Login:/Password:"
system, that is not used by Windows NT, is missing. A wait for the 'Login:'
call after the 'CONNECT' message makes no sense !!

To establish a connection with Windows NT, the PAP authentication system 
must be used. The 'pppd' expects the parameters and identifications required 
for it in the file /etc/ppp/pap-secrets:
_______________________________________________________________________________ 
# Secrets for authentication using PAP
# client        server     secret      IP addresses
my_login        win_nt     my_passw
_______________________________________________________________________________
File: /etc/ppp/pap-secrets

Typically this file should contain for a line (without leading blanks) for 
a PPP connection, although is nearly always mentioned that two entries 
(with similar 'server'/'client' parameters) are required for a PPP 
connection.
As it however turns out, a parameters' set is enough with a Windows NT 
connection (authentication by Linux at Windows NT Server), because
a Windows NT computer's authentication either does not take place, or an 
order for it is refused with 'Authentication refused' by Windows NT. 

The Windows NT computer is referred as 'server', to which is called.
The 'secret' contains the assigned password for the entered Windows 
NT user identification under 'client' in plaintext. Under 'client'
the local computer name is not to be declared, but the user 
identification.

To use the combination PAP/PPP in connection with Windows NT, the 
concerning Windows NT server's system name is to be informed to the 
'pppd' on the option 'remotename'. With it the corresponding 
pap-secrets-entry can be used. Microsoft PPP server unfortunately does not 
send its system name during the PPP/PAP connection establishment. 
This is why this must be defined by option.

As local system name ('pppd' option name) is compatible with the Windows 
NT user identification.

The used 'pppd' option's set consists on the following parameters and 
is in the file /etc/ppp/options. 
_______________________________________________________________________________
/dev/ttyS0
crtscts
152.3.60.1:152.3.60.2
defaultroute
debug
modem
name my_login
remotename win_nt
_______________________________________________________________________________
File: /etc/ppp/options
_______________________________________________________________________________
Parameter description file /etc/ppp/options :     
/dev/ttyS0              : Port to which the modem is connected 
                          ( ttyS0 = COM1 )
crtscts                 : Use of the hardware flow control (RTS/CTS) 
			              to control the data traffic in the 
                          serial port
152.3.60.1:152.3.60.2   : Definition of the IP addresses to be used in the 
                          form : 
defaultroute            : Use of the remote host as standard route
                          connection:
                          the PPP connection is entered by default in
                          kernel's routing table
debug                   : activates the debug mode. The
                          informations are written in the file 
		          /var/log/messages 
modem                   : declares, that it is a question of a modem 
			  connection
name          : sets the local system name according to man page 
			  for authentication's purposes. 
                          The Windows NT user 
			  identification to be used is declared!!!
remotename  : sets the elected Windows NT
                          server's system name for authentication's 
			  purposes
_______________________________________________________________________________

The definitions that have taken place up to now should be enough to make 
the first connection trial with the Windows NT Server.

Before the connection scripts' call, the serial interface's speed is 
still set to 115200 Baud (28.8k compressed):
      setserial /dev/ttyS0 spd_hi

The transactions of the 'chat' as well as of the 'pppd' programmes can be
protocoled on the screen by 
      tail -f /var/log/messages
during the connection construction.

An -uncommented- protocol of a successful PPP connection establishment
via PAP authentication looks as follows like:
_______________________________________________________________________________
 kernel: PPP: version 2.2.0 (dynamic channel allocation)
 kernel: PPP Dynamic channel allocation code copyright 1995 Caldera, Inc.
 kernel: PPP line discipline registered.
 kernel: registered device ppp0
 pppd: pppd 2.2.0 started by root, uid 0
 chat: timeout set to 60 seconds
 chat: abort on (NO CARRIER) 
 chat: abort on (BUSY) 
 chat: abort on (NO DIALTONE) 
 chat: abort on (ERROR) 
 chat: send (+++ATZ^M) 
 chat: expect (OK) 
 chat: +++ATZ^M^M 
 chat: OK -- got it 
 chat: send (ATE1Q0&C1&S0S0=0DT555222^M) 
 chat: expect (CONNECT) 
 chat: ^M 
 chat: ATE1Q0&C1&S0S0=0DT555222^M^M 
 chat: CONNECT -- got it 
 chat: send (^M) 
 pppd: Serial connection established.
 pppd: Using interface ppp0
 pppd: Connect: ppp0 <--> /dev/ttyS0
 pppd: sent [LCP ConfReq id=0x1    ]
 pppd: sent [LCP ConfReq id=0x1    ]
 pppd: rcvd [LCP ConfReq id=0x0               \
         ]
 pppd: sent [LCP ConfNak id=0x0 ]
 pppd: rcvd [LCP ConfAck id=0x1    ]
 pppd: rcvd [LCP ConfReq id=0x1        \
         ]
 pppd: sent [LCP ConfNak id=0x1 ]
 pppd: rcvd [LCP ConfReq id=0x2        \
         ]
 pppd: sent [LCP ConfNak id=0x2 ]
 pppd: rcvd [LCP ConfReq id=0x3         \
        ]
 pppd: sent [LCP ConfAck id=0x3         \
        ]
 pppd: sent [PAP AuthReq id=0x1 user="my_login" password="my_passw"]
 pppd: rcvd [PAP AuthAck id=0x1msg=""]
 pppd: Remote message: 
 pppd: sent [IPCP ConfReq id=0x1  ]
 pppd: rcvd [CCP ConfReq id=0x4 < 12 06 00 00 00 01>]
 pppd: sent [CCP ConfReq id=0x1]
 pppd: sent [CCP ConfRej id=0x4 < 12 06 00 00 00 01>]
 pppd: rcvd [proto=0x803f] 01 06 00 17 03 05 00 05 01 02 0e 00 01 00 01      \
       00 00 52 32 30 30 32 00
 pppd: Unknown protocol (0x803f) received
 pppd: sent [LCP ProtRej id=0x2 80 3f 01 06 00 17 03 05 00 05 01 02 0e       \
       00 01 00 01 00 00 52 32 30 30 32 00]
 pppd: rcvd [IPCP ConfAck id=0x1  ]
 pppd: rcvd [CCP ConfAck id=0x1 < fe 02>]
 pppd: rcvd [CCP TermReq id=0x7 00 00 02 dc]
 pppd: sent [CCP TermAck id=0x7]
 pppd: sent [IPCP ConfAck id=0xd ]
 pppd: local  IP address 152.3.60.1
 pppd: remote IP address 152.3.60.2
 pppd: sent [CCP ConfReq id=0x1]
 pppd: rcvd [CCP TermAck id=0x1]
 pppd: sent [CCP TermReq id=0x2]
 pppd: rcvd [CCP TermAck id=0x2]
 ... 
 ...   Connection's start
 ...   Waiting for connection signal
 ...
 pppd: Terminating on signal 2.
 pppd: sent [LCP TermReq id=0x3]
 pppd: rcvd [LCP TermAck id=0x3]
 pppd: Connection terminated.
 pppd: Exit.
 kernel: PPP: ppp line discipline successfully unregistered
_______________________________________________________________________________
Exit protocol /var/log/messages : Establishing PAP/PPP connection

In it, the client's reaction to the PAP 
authentication's request is interesting 
 pppd: rcvd [ LCP ConfReq  ...   ... ]
This request is quickly replied with
 pppd: sent [LCP ConfAck ...  ... ] 
 pppd: sent [PAP AuthReq  user="my_login" password="my_passw"]
This leads finally into a successful connection establishment.

As it is clear from the protocol, the password is also transferred to 
clear text during the PAP authentication system along with the user 
identification, what can be looked at under certain circumstances as a
security risk. To increase the security standard, at least a password 
encoding is demanded in addition.

_______________________________________________________________________________

Configuration 2: PPP connection in Windows NT with CHAP authentication
_______________________________________________________________________________

For this purpose the CHAP authentication method is used: the main difference
to PAP is among others in the password's encoded transfer.
'pppd' passes this on to the /etc/ppp/chap secrets file, that in 
principle has the same construction as the pap secrets file (pap secrets 
can be copied to chap secrets).

The Windows NT server's dialling takes place according to 
the preceding pattern. The above mentioned patched 'pppd' version is set up.

An -uncommented- protocol of a successful PPP connection establishment
via CHAP authentication looks like as follows (the 'chat' connection
establishment and the 'pppd' connection dismantling are not performed any 
more):
_______________________________________________________________________________
 pppd: Using interface ppp0
 pppd: Connect: ppp0 <--> /dev/ttyS0
 pppd: sent [LCP ConfReq id=0x1    ]
 pppd: sent [LCP ConfReq id=0x1    ]
 pppd: rcvd [LCP ConfReq id=0x0                \
         ]
 pppd: sent [LCP ConfAck id=0x0                \
         ]
 pppd: rcvd [LCP ConfAck id=0x1    ]
 pppd: cbcp_lowerup
 pppd: want: 2
 pppd: phone no: (null)
 pppd: rcvd [CHAP Challenge id=0x2e , name = ""]
 pppd: sent [CHAP Response id=0x2e <0000000000000000000000000000000000000      \
       00000000000ee0cecf8c969e78c01e80aa8f28dcd0aa5a835287d0fa32d01>,         \
       name = "my_login"]
 pppd: rcvd [CHAP Success id=0x2e ""]
 pppd: sent [IPCP ConfReq id=0x1  ]
 pppd: rcvd [CCP ConfReq id=0x1 < 12 06 00 00 00 01>]
 pppd: sent [CCP ConfReq id=0x1]
 pppd: rcvd [proto=0x803f] 01 03 00 17 03 05 00 05 01 02 0e 00 01 00 01        \
       00 00 52 32 30 30 32 00
 pppd: Unknown protocol (0x803f) received
 pppd: sent [LCP ProtRej id=0x2 80 3f 01 03 00 17 03 05 00 05 01 02 0e         \
       00 01 00 01 00 00 52 32 30 30 32 00]
 pppd: rcvd [IPCP ConfAck id=0x1  ]
 pppd: rcvd [CCP ConfAck id=0x1 < fe 02>]
 pppd: rcvd [CCP TermReq id=0x4 00 00 02 dc]
 pppd: sent [CCP TermAck id=0x4]
 pppd: sent [IPCP ConfAck id=0xa ]
 pppd: local  IP address 152.3.60.1
 pppd: remote IP address 152.3.60.2
 pppd: sent [CCP ConfReq id=0x1]
 pppd: rcvd [CCP TermAck id=0x1]
 pppd: sent [CCP TermReq id=0x2]
 pppd: rcvd [CCP TermAck id=0x2]
_______________________________________________________________________________
Exit protocol /var/log/messages : Establishing a CHAP/PPP connection

In it, the client's reaction to the 
CHAP authentication's request is interesting
 pppd: rcvd [LCP ConfReq ...  ... ]
This request is quickly replied with
 pppd: sent [LCP ConfAck ...  ... ]   
The following "CHAP Challenge" demand is answered with the encoded
password and the login identification in clear text
 pppd: rcvd [CHAP Challenge ... , name = ""]
 pppd: sent [CHAP Response  ... <0000000000000000000000000000000000000      \
       00000000000ee0cecf8c969e78c01e80aa8f28dcd0aa5a835287d0fa32d01>,      \
       name = "my_login"]
 pppd: rcvd [CHAP Success ... ]
This leads finally to a successful connection establishment.

As it is clear from the protocol, the password is also transferred to
clear text during the PAP authentication system along with the user
identification. This should be considered a positive security aspect. To 
furtherly increase the security standard, the possibility of 
an automatic callback through the Windows NT Server is still demanded.

_______________________________________________________________________________

Configuration 3: PPP connection in Windows NT with CHAP authentication and
                 automatic callback through the Windows NT Server
_______________________________________________________________________________

It is set the above mentioned patched 'pppd' version and used in addition
the Callback Feature.

The Windows NT server's dialling takes place according to
the preceding pattern. To activate the automatic callback, the 'pppd' 
must be informed about the -variable- user-defined phone number under the 
Windows NT callback. This takes place with the option "cb", that is 
installed in the dialling script:
_______________________________________________________________________________
#!/bin/sh
# Establishing a PPP connection
# to a Windows NT Server under CALLBACK mode use
phone="cb 555111"
/usr/sbin/pppd 38400 connect '/usr/sbin/chat -v -f $HOME/win_nt.chat' \
    lock $phone
_______________________________________________________________________________
file: dial_win_nt.callback

To take the arrived callback correctly, a corresponding 'mgetty' 
process for the interface must be defined for this purpose through an 
entry to the file /etc/inittab. This 'mgetty' process is activated in the 
next system start and takes the 'pppd' programmes' call in an arrived PPP 
connection.
_______________________________________________________________________________
mo:23:respawn:/usr/sbin/mgetty -x 6 -s 38400 ttyS0
_______________________________________________________________________________
Exit file /etc/inittab
_______________________________________________________________________________
Parameter description exit file /etc/inittab :
-s            :   sets the port speed to be used 
                         e.g.: 38400 Baud
ttyS0                :   defines the interface to be addressed
                         ( ttyS0 = COM1 ) 
-x 6                 :   sets the debug mode. The debug informations 
			 are filed in the file /tmp/log.mg.
                         (/tmp/log.mg.ttyS0)
_______________________________________________________________________________

In the 'mgetty' configuration file /usr/etc/mgetty+sendfax/mgetty.config 
is fixed to use only the modem mode in an arrived connection.
_______________________________________________________________________________
# ----- port specific section -----
# Here you can put things that are valid only for one line, not the others
# USR Sportster Vi 28.8, connected to ttyS0: don't do fax
port ttyS0
data-only y
rings 2
_______________________________________________________________________________
Exit file /usr/etc/mgetty+sendfax/mgetty.config
_______________________________________________________________________________
Parameter description exit file /usr/etc/mgetty+sendfax/mgetty.config :
 port ttyS0           : Specific interface definitions for
                        port ttyS0 ( = COM1 )
 data-only y          : specifies the class of the modem connected to the 
			declared port:  
                        no use from FAX mode, only data mode
 rings             : defines the RING messages' number that are 
			waited for until 'mgetty' lifts the modem up
_______________________________________________________________________________

Finally, in the file /usr/etc/mgetty+sendfax/login.config, is still to be 
announced to the 'mgetty' process to start automatically the 'pppd' 
process at a recognized PPP command.
_______________________________________________________________________________
# Automatic PPP startup on receipt of LCP configure request.
#  mgetty has to be compiled with "-DAUTO_PPP" for this to work.
#  Warning: Case is significant, AUTOPPP or autoppp won't work!
/AutoPPP/ -	ppp	/usr/sbin/pppd 38400 
_______________________________________________________________________________
Exit file /usr/etc/mgetty+sendfax/login.config
_______________________________________________________________________________
Parameter description exit file /usr/etc/mgetty+sendfax/mgetty.config :
38400                   : sets the port speed to be used
                          (38400 Baud)
_______________________________________________________________________________

An -uncommented- protocol of a successful PPP connection establishment
via CHAP authentication with callback through the Windows NT server looks
like as follows (the 'chat' connection establishment is not performed any 
more):
_______________________________________________________________________________
 pppd: Using interface ppp0
 pppd: Connect: ppp0 <--> /dev/ttyS0
 pppd: sent [LCP ConfReq id=0x1                    \
       06 6c ce 1f 62 07 02 08 02 00]
 pppd: sent [LCP ConfReq id=0x1                    \
       06 6c ce 1f 62 07 02 08 02 00]
 pppd: rcvd [LCP ConfReq id=0x0                \
         ]
 pppd: sent [LCP ConfAck id=0x0                \ 
         ]
 pppd: rcvd [LCP ConfAck id=0x1                     \
       06 6c ce 1f 62 07 02 08 02 07]
 pppd: cbcp_lowerup
 pppd: want: 6
 pppd: rcvd [CHAP Challenge id=0x10 <349d61d2af2f5f75>, name = ""]
 pppd: sent [CHAP Response id=0x10 <0000000000000000000000000000000           \
       000000000000000004ee80271f4ad6170bfb6ffa5a866883f5bdf739e596162db01>,  \
       name = "my_login"]
 pppd: rcvd [CHAP Success id=0x10 ""]
 pppd: cbcp_open
 pppd: rcvd [CBCP Request id=0x1 < NoCallback> 02 05 00 01 00]
 pppd: length: 7
 pppd: no callback allowed
 pppd: length: 5
 pppd: user callback allowed
 pppd: cbcp_resp cb_type=6
 pppd: cbcp_resp CONF_USER
 pppd: sent [CBCP Response id=0x1 < UserDefined delay = 5 number = 555111>]   \
       35 35 35 31 31 31
 pppd: rcvd [CBCP Ack id=0x1 < UserDefined delay = 5 number =  555111>]       \
       35 35 35 31 31 31
 pppd: peer will call: 555111
 pppd: sent [LCP TermReq id=0x2]
 pppd: rcvd [LCP TermAck id=0x2]
 pppd: Connection terminated.
 pppd: Exit.
_______________________________________________________________________________
Exit protocol /var/log/messages : Establishing a CHAP/PPP connection with
callback

In it, the client's reaction still before the CHAP authentication's 
request by sending a "Callback Requests" is interesting
 pppd: sent [LCP ConfReq ...  ... ]
This request is quickly answered with
 pppd: rcvd [LCP ConfAck ...  ... ]
to announce later on after the CHAP 
authentication the phone number to the Windows NT server  
 pppd: sent [CBCP Response ...  number = 555111>]   ...
This announcement is taken by the Windows NT server
 pppd: rcvd [CBCP Ack      ...  number =  555111>]  ...
The existing connection is now interrupted by the client and is waited 
for the callback.
If the callback takes place, the 'pppd' modul is called again on the 
'mgetty' process, where now no phone number can be given.
The CHAP/PPP connection establishment takes place analoguely to the 
pattern already shown above (configuration 2).

With this procedure the starts are fulfilled with the mentioned security 
aspects (MS-CHAP authentication and "Callback" pattern).

To prevent again the insecure PAP/PPP access, the option
 'Require Microsoft encrypted authentication', that only allows CHAP/PPP 
connections via MS-CHAP authentication, can now be activated on the
Windows NT server in the Windows NT Remote Access Service under 'Network
Configuration' in the 'Encryption settings'.

The 'mgetty' processes' transactions can be protocoled on the screen by 
      tail -f /tmp/log_mg.ttyS0 
during the connection establishment.

Following, an -uncommented- protocol of a successful PPP connection 
establishment on the 'mgetty' process via CHAP authentication
with callback throug the Windows NT Server.
_______________________________________________________________________________
 yS0  mgetty: experimental test release 0.99-May31
 yS0   reading configuration data for port 'ttyS0'
 yS0  check for lockfiles
 yS0   checklock: stat failed, no file
 yS0  locking the line
 yS0   makelock(ttyS0) called
 yS0   do_makelock: lock='/var/lock/LCK..ttyS0'
 yS0   lock made
 yS0  lowering DTR to reset Modem
 yS0   tss: set speed to 38400 (017)
 yS0   tio_set_flow_control( HARD )
 yS0   waiting for line to clear (VTIME), read: [0d][0a]NO CARRIER[0d][0a]
 yS0  send: \d\d\d+++\d\d\d[0d]\dATQ0V1H0[0d]
 yS0  waiting for ``OK''
 yS0   got: +++[0d]
 yS0    CND: +++[0a]RING[0d]
 yS0    CND: RING[0a][0d]ATQ0V1H0[0d]
 yS0    CND: ATQ0V1H0[0d][0a]OK ** found **
 yS0  send: ATS0=0Q0&D3&C1[0d]
 yS0  waiting for ``OK''
 yS0   got: [0d]
 yS0    CND: OK[0a]ATS0=0Q0&D3&C1[0d]
 yS0    CND: ATS0=0Q0&D3&C1[0d][0a]OK ** found **
 yS0   waiting for line to clear (VTIME), read: [0d][0a]
 yS0   removing lock file
 yS0  waiting...
 yS0    select returned 1
 yS0   checking lockfiles, locking the line
 yS0   makelock(ttyS0) called
 yS0   do_makelock: lock='/var/lock/LCK..ttyS0'
 yS0   lock made
 yS0  waiting for ``RING''
 yS0   got: [0d]
 yS0    CND: OK[0a]RING ** found **
 yS0  send: ATA[0d]
 yS0  waiting for ``CONNECT''
 yS0   got: [0d]
 yS0    CND: RING[0a]ATA[0d]
 yS0    CND: ATA[0d][0a]CONNECT ** found **
 yS0  send: 
 yS0  waiting for ``
''
 yS0   got:  28800/ARQ/V34/LAPM[0d]
 yS0    CND: CONNECT 28800/ARQ/V34/LAPM
 yS0    CND: found: 28800/ARQ/V34/LAPM[0a] ** found **
 yS0   waiting for line to clear (VTIME), read: 
 yS0    looking for utmp entry... (my PID: 2412)
 yS0   utmp + wtmp entry made
 yS0   tio_set_flow_control( HARD )
 yS0   getlogname, read:~[ff][03]
 yS0   getlogname, read:[c0]!
 yS0   input finished with '\r', setting ICRNL ONLCR
 yS0    login: use login config file /usr/etc/mgetty+sendfax/login.config
 yS0   match: user='/AutoPPP/', key='/FIDO/'
 yS0   match: user='/AutoPPP/', key=''
 yS0   match: user='/AutoPPP/', key='/AutoPPP/'*** hit!
 yS0   login: utmp entry: ppp
 yS0    looking for utmp entry... (my PID: 2412)
 yS0   utmp + wtmp entry made
 yS0   calling login: cmd='/usr/sbin/pppd', argv[]='pppd 38400 '             \
       08/28 19:23:14 ##### data dev=ttyS0, pid=2412, caller=none,           \
       conn='28800/ARQ/V34/LAPM', name='', cmd='/usr/sbin/pppd',             \
       user='/AutoPPP/'
...
...  ... call from pppd to the happened callbck
...  ... and waiting for the connection signal
...
 yS0  check for lockfiles
 yS0   checklock: no active process has lock, will remove
 yS0  locking the line
 yS0   makelock(ttyS0) called
 yS0   do_makelock: lock='/var/lock/LCK..ttyS0'
 yS0   lock made
 yS0  lowering DTR to reset Modem
 yS0   tss: set speed to 38400 (017)
 yS0   tio_set_flow_control( HARD )
 yS0   waiting for line to clear (VTIME), read: [0a][0a]NO CARRIER           \
       [0a][0a][0a][0a][0a][0a]NO CARRIER[0a][0a]......                      \
       [0a]NO CARRIER[0a][0a][0a][0a][0a][0a][0a][0a]
 yS0  clean_line: only 500 of 3124 bytes logged
 yS0  send: \d\d\d+++\d\d\d[0d]\dATQ0V1H0[0d]
 yS0  waiting for ``OK''
 yS0   got: +++[0d]
 yS0    CND: +++ATQ0V1H0[0d]
 yS0    CND: ATQ0V1H0[0d][0a]OK ** found **
 yS0  send: ATS0=0Q0&D3&C1[0d]
 yS0  waiting for ``OK''
 yS0   got: [0d]
 yS0    CND: OK[0a]ATS0=0Q0&D3&C1[0d]
 yS0    CND: ATS0=0Q0&D3&C1[0d][0a]OK ** found **
 yS0   waiting for line to clear (VTIME), read: [0d][0a]
 yS0   removing lock file
 yS0  waiting...
_______________________________________________________________________________
Exit protocol /tmp/log_mg.ttyS0 :  mgetty with PPP protocol identification


The PPP connection was successfully established, the used IP addresses and 
the 'ppp' interface situation can be found out by the command
    ifconfig ppp0.
_______________________________________________________________________________
ppp0      Link encap:Point-Point Protocol  
          inet addr:152.3.60.1  P-t-P:152.3.60.2  Mask:255.255.0.0
          UP POINTOPOINT RUNNING  MTU:1500  Metric:1
          RX packages:124 errors:0 dropped:0 overruns:0
          TX packages:123 errors:0 dropped:0 overruns:0
_______________________________________________________________________________
Configuration of the ppp interface on a established connection 
(ifconfig)

The entry 'inet addr' reflects again the own local IP address.
The address at 'P-t-P' refers to the Windows NT Server.

Usually such a PPP connection serves to access to further available 
(UNIX) hosts in the network.
For this purpose, the corresponding route entry on 
the Linux client, that is automatically generated by the 'pppd' process
(Option defaultroute), is of course required.

The existing route connections are shown by the command
    netstat -r.
_______________________________________________________________________________
Kernel IP routing table
Destination     Gateway         Genmask         Flags   MSS Window  irtt Iface
win_nt          *               255.255.255.255 UH     1500 0          0 ppp0
loopback        *               255.0.0.0       U      3584 0          0 lo
default         win_nt          0.0.0.0         UG     1500 0          0 ppp0
_______________________________________________________________________________
Routing table at the established PPP connection (netstat -r)

The two available entries for the ppp interface (Spalte Iface) are of 
decissive meaning.

The first entry sets a HOST route (marked with the flag H), that leads 
only to the connected host computer (destination field) - and no more -.

The second entry defines the 'default' route: the Linux host is told to 
forward to the Windows NT Server all packages which are not specific for 
the local net (for this exist own network routes).This is then 
responsible for the going on of the package to other hosts and from these 
hosts back to the Linux host.

It is available in the net in which one has dialled the "Domain Name 
Service", so this can of course be used for name's cancellation.
The corresponding entries (domain name and the corresponding name server) 
are defined in the file /etc/resolv.conf.
Now the corresponding hosts are also symbolically addressable on their 
DNS names.
_______________________________________________________________________________
domain my_office.my_plant.com
nameserver 152.3.60.4
nameserver 152.3.60.5
_______________________________________________________________________________
Configuration file /etc/resolv.conf

The name's cancellation's sequence (Converting host name <--> IP 
address) is set in the file /etc/host.conf:
_______________________________________________________________________________
order hosts, bind
_______________________________________________________________________________
File /etc/host.conf configuration

The appropiate resolver routine for the name's cancellation is informed 
to look for the corresponding entries only in the local file /etc/hosts. 
If no cancellation can take place, the name's 
cancellation is activated on DNS.

_______________________________________________________________________________ 
List of the necessary and used files:
/usr/sbin/pppd             : 'pppd' binary
/usr/sbin/chat             : 'chat' binary
/etc/ppp/pap-secrets       : PAP authentication parameter configuration
/etc/ppp/chap-secrets      : CHAP authentication parameter configuration
/etc/ppp/options           : Paremeter for 'pppd' connections
dial_win_nt                : Dialling script for 'pppd'
dial_win_nt.callback       : Dialling script for 'pppd' in the
                             automatic callback option use
win_nt.chat                : Dialling script for 'chat'
/usr/sbin/mgetty           : Process to forward an arrived callback to 
			     'pppd' 
/usr/etc/mgetty+sendfax/
mgetty.config              : File 'mgetty' process configuration
/usr/etc/mgetty+sendfax/
login.config               : File 'mgetty' process configuration
/etc/host.conf             : Sequence's fixture for the name's 
			     cancellation
/etc/resolv.conf           : Configuration for DNS name's cancellation
_______________________________________________________________________________ 

_______________________________________________________________________________
Bibliography

[1] Bodo Bauer; 
    Magic Connection; 
    With the Point to Point Protocol into Internet;
    iX 1/96, S.154
[2] S. Hetze and others;
    LinuX User's Handbook and System's Administration Guide,
    5th extended and actualised edition, page 329
    LunetIX Softfair
    ISBN 3-929764-04-0
[3] Olaf Kirch;
    Linux Network Administrator Guide;
    1996;
    O'Reilly
    ISBN 3-930673-18-5
[4] Al Longyear;
    Linux PPP HOWTO;
    12th July 1995;
    http://www.suse.de/doku.howto/NET-2-HOWTO.html 
_______________________________________________________________________________

---

See also:

---

Keywords: PPP, PAP, CHAP, NT

---

Feedback welcome: Send Mail to kfr@suse.de (Please give the following subject: SDB-ppp_nt)

---

Mainpage ---- Searchform ---- History ---- Versions ---- Categories ---- Contents
Deutsch
---

SDB-ppp_nt, Copyright SuSE GmbH, Nuremberg, Germany - Version:
Impressum - Last generated: 24. Feb 1999 15:18:57 by maddin with sdb_gen 1.00.0