Mainpage
Searchform
History
Versions
Categories
Contents
Deutsch
_______________________________________________________________________________
... 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:
PPP: Authentication on PAP, CHAP
PPP: adjusting the chat script
PPP and shadow password
Feedback welcome: Send Mail to kfr@suse.de (Please give the following subject: SDB-ppp_nt)
Mainpage
Searchform
History
Versions
Categories
Contents
Deutsch