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:
Feedback welcome: Send Mail to kfr@suse.de (Please give the following subject: SDB-ppp_nt
)
Mainpage
Searchform
History
Versions
Categories
Contents
Deutsch