Chapter 4 Editing the Configuration Files
This chapter describes the format and syntax of each of the configuration files associated with Solstice PPP, and explains how to modify these files to generate more complex network configurations.
Configuration Files for Solstice PPP
Solstice PPP uses the information contained in the following files to establish IP connections over synchronous and asynchronous PPP links:
PPP Path Configuration File (ppp.conf)
The PPP path configuration file (/etc/opt/SUNWconn/ppp/ppp.conf) describes the synchronous and asynchronous (or dialup) paths used for IP connections over Solstice PPP links. It includes the ifconfig(1M) commands that establish the logical IP interfaces for Solstice PPP.
See "Editing the PPP Path Configuration File (ppp.conf)" for a detailed description of the parameters set in this file.
Link Configuration File (link.conf)
The link configuration file (/etc/opt/SUNWconn/ppp/link.conf) describes the synchronous and asynchronous devices used to create the PPP link. It includes dialing information for initiating asynchronous links to remote hosts.
See "Editing the Link Configuration File (link.conf)" for a detailed description of the parameters set in this file.
Modems Database File (modems)
The modems database file (/etc/opt/SUNWconn/ppp/modems) contains a description of the modems recognized by Solstice PPP, including the AT commands used by Solstice PPP to initialize the modems for incoming and outgoing connections.
See "Editing the Modem Database File (modems)" for instructions on how to add new modem descriptions to this file.
CHAT (or Connect) Scripts
The CHAT (or connect) scripts define exchange of information between the endpoints, which occurs during the link establishment phase. By default, the CHAT scripts are located in the directory /etc/opt/SUNWconn/ppp/script. You can change the location of the scripts by editing the location definition in the file link.conf and moving the files. CHAT scripts may be non-interactive (all the information to be exchanged is contained in the script) or interactive (the script prompts for user input).
You must create one CHAT script for each remote host to which the local host will initiate calls. Some of the information contained the CHAT script is dependent on the operating system running on the remote host. The PPP initialization script (pppinit) can create a template file for connecting to hosts running a Solaris environment. See "Editing the CHAT (or Connect) Scripts" for instructions modify the template file for other operating systems.
User Account Files (/etc/passwd and /etc/shadow)
To accept asynchronous PPP connections initiated by a remote host, there must be a corresponding user account created on the local machine. Use admintool(1M) to add the entries of the type shown in Figure 4-1 to the local user account files /etc/passwd and /etc/shadow.
Figure 4-1 PPP Login Entry in /etc/passwd
Combining the Configuration Files
Figure 4-2 shows how the files ppp.conf and link.conf are combined to define a point-to-point IP connection over a synchronous PPP link.
Figure 4-2 Configuration Files for Synchronous Connections
Figure 4-3 shows the relationship between the files ppp.conf, link.conf, and the CHAT script used to initiate a point-to-point IP connection to a remote host over an asynchronous PPP link.
Figure 4-4 shows the relationship between the files ppp.conf, link.conf, and the user account used to accept a point-to-point IP connection from a remote host over an asynchronous PPP link.
Figure 4-3 Configuration Files for Initiating Asynchronous Connections
Figure 4-4 Configuration Files for Accepting Asynchronous Connections
Editing the PPP Path Configuration File (ppp.conf)
The PPP path configuration file (/etc/opt/SUNWconn/ppp/ppp.conf) describes the synchronous and asynchronous (or dialup) paths used for IP over Solstice PPP. It includes the ifconfig(1M) commands that establish the logical IP interfaces for Solstice PPP.
Defining IP Interfaces using ifconfig
The ifconfig(1M) commands that are contained in the PPP configuration file establish the point-to-point (ipdptpn) and point-to-multipoint (ipdn) IP interfaces for Solstice PPP. These commands are executed when Solstice PPP is started, to assign a network address to each interface and to configure the network parameters.
Synopsis
The ifconfig commands used to establish the IP interfaces for Solstice PPP have the general form:
ifconfig interface plumb source [dest] netmask mask mtu mtu up |
Arguments
interface
The name and type of the IP interface. The IP interfaces for Solstice PPP are ipdptpn (point-to-point) and ipdn (point-to-multipoint), where n is a number. By convention, IP interfaces are numbered sequentially from zero.
For example, ipdptp0, ipdptp1, ipdptp2, or ipd0, ipd1, ipd2
plumb
Opens the device associated with the interface name, and sets up the STREAMS that enable TCP/IP to use the device.
source
An IP address (dot notation) or hostname that represents the source address, or point of attachment, for point-to-point and point-to-multipoint IP interfaces.
dest
Point-to-point interfaces only. An IP address (dot notation) or hostname that represents the destination address for a point-to-point IP interface.
netmask mask
Specifies how much of the IP address to reserve for dividing networks into subnetworks. The mask can be entered in dot notation, or in hexadecimal when preceded by 0x.
mtu mtu
Sets the maximum transmission unit (MTU) for the interface. The MTU must be in the range 60 to 8232 bytes, and is usually set to 1500, which is the optimum value for Ethernet networks.
up
Marks the interface up--that is, active. You can disable an interface temporarily by marking it down. The IP interfaces associated with synchronous PPP links are usually marked up by default. If the IP interface associated with an asynchronous PPP link is marked up, the link manager will attempt to establish the link automatically when the IP layer passes an IP datagram to the interface.
Examples
To establish a point-to-multipoint IP interface for Solstice PPP, include an ifconfig command of the form:
ifconfig ipd0 plumb papyrus netmask 255.255.255.0 mtu 1500 up |
To establish a point-to-point IP interface for Solstice PPP, include an ifconfig command of the form:
ifconfig ipdptp0 plumb ifconfig ipdptp0 papyrus epic netmask 255.255.255.0 mtu 1500 up |
Note that the interface can be fully defined by concatenating multiple ifconfig commands, as shown in the previous example.
Defining a Pool of IP Interfaces for Dynamic IP Address Allocation
To configure a server to support dynamic IP address allocation, you must define a pool of point-to-point IP interfaces that will be assigned to the clients as required. These interfaces are always marked down by default.
For example, to create a pool of n point-to-point IP interfaces for dynamic IP address allocation:
ifconfig ipdptp0 plumb ifconfig ipdptp0 local rem1 netmask 255.255.255.0 mtu 1500 down ifconfig ipdptp1 plumb ifconfig ipdptp1 local rem2 netmask 255.255.255.0 mtu 1500 down ifconfig ipdptp2 plumb ifconfig ipdptp2 local rem3 netmask 255.255.255.0 mtu 1500 down . . ifconfig ipdptpn plumb ifconfig ipdptpn local remn netmask 255.255.255.0 mtu 1500 down |
The number of interfaces in the pool should equal the number of asynchronous devices (modems) attached to the server, and the maximum number of interfaces in the pool is 512. The total number of clients supported by the server may be much greater.
If you have a small number of clients, or the same number of clients and modems, you can assign the interfaces statically. In this case, when a client requests an IP address, it is always assigned the same one from the pool.
If you have a large number of clients, or many more clients than modems, you can assign the interfaces dynamically. In this case, when a client requests an IP address, it is assigned one from the pool, but there is no guarantee that it will always receive the same one.
See "Defining Asynchronous Paths (dialup_path)" for instructions on how to assign static and dynamic IP interfaces.
Defining Synchronous Paths (sync_path)
Synchronous paths are identified in the file ppp.conf by the keyword sync_path, which starts each definition. They are always associated with point-to-point IP interfaces.
Synopsis
Synchronous path definitions have the following general form:
sync_path ip_interface ipdptpn unix_device device_name . . . |
Keywords
sync_path
Mandatory parameter for synchronous paths. Indicates the start of a synchronous path definition.
Mandatory parameter for synchronous paths. Associates the synchronous path with one of the point-to-point IP interfaces defined in the ifconfig section of the file. Load-sharing is enabled if two or more synchronous paths share the same IP interface.
Mandatory parameter for synchronous paths. Associates the synchronous path with one of the synchronous devices defined in the file link.conf. The value device must correspond to a synchronous serial interface installed in your machine.
For example, the device names of the form zshn associate the path with one of the on-board serial interfaces. The device names of the form hihn, associate the path with a high-speed serial interface (HSI).
Optional parameter for synchronous paths. Adds the route to the routing table as the default destination. The route is removed when the IP interface is marked down.
Optional parameter for synchronous paths. Accepts the IP addresses provided by the remote host, even if they differ from the IP addresses assigned to the interface locally.
The value state can be on (enabled) or off (disabled). The default value is off.
Optional parameter for synchronous paths. Indicates the current state of the link monitor. When enabled, the link monitor sends periodic echo requests to the remote host. If the remote host fails to respond after a specified number of requests, the link monitor assumes that the link has failed for some reason. It marks the IP interface associated with the synchronous path down to stop the transmission of more IP datagrams across the failed link.
The value state can be on (enabled) or off (disabled). The default value is off.
Optional parameter for synchronous paths. Specifies the number of seconds which elapse between consecutive echo requests generated by the link monitor.
The value seconds can be any integer greater than zero. The default value is 5 seconds.
link_monitor_retries max_retries
Optional parameter for synchronous paths. Specifies the number of unanswered echo requests generated by the link monitor before the remote host is considered unreachable and the IP interface is disabled.
The value max_retries can be any integer greater than zero. The default value is 12.
Optional parameter for synchronous and asynchronous paths. Assigns a name that is used by ppptrace and pppstat to identify the link. The value name can be any character string.
Optional parameter for synchronous and asynchronous paths. Indicates the current state of the header compression facility, which uses Van Jacobsen compression to improve performance over slow links.
The value state can be vj (enabled) or off (disabled). The default value is vj.
Optional parameter for synchronous and asynchronous paths. Specifies the maximum receive unit (MRU) for the local machine. This parameter is carried in the LCP Configure-request frame, and sets the maximum transmission unit (MTU) for the remote host. See Appendix A, PPP Link Operation for more information.
By default, the value mru is set to 1500 bytes for Ethernet networks.
Optional parameter for synchronous and asynchronous paths. Specifies the number of seconds which elapse between consecutive LCP Configure-request frames. Increasing the LCP restart timer may be necessary when connecting over long delay networks, such as satellite connections. See Appendix A, PPP Link Operation for more information.
The value seconds can be any integer greater than zero. The default value is 3 seconds.
Optional parameter for synchronous and asynchronous paths. Specifies the number of unanswered LCP Configure-request frames generated before the endpoint is considered unreachable and the IP interface is marked as down. See Appendix A, PPP Link Operation for more information.
The value max_restart can be any integer in the range 1 to 255. The default value is 10. If the value max_restart is set to 255, LCP Configure-request frames are generated periodically until the remote host finally responds.
Optional parameter for synchronous and asynchronous paths. Indicates that the local host will request authentication from remote hosts, and the authentication protocol to be used. If authentication is enabled, remote hosts must authenticate themselves successfully, or the connection is closed.
The value mode can be off (no authentication), pap (authentication using PAP), chap (authentication using CHAP), or pap|chap (authentication using both PAP and CHAP). The default value is off.
If both PAP and CHAP are enabled, CHAP authentication is performed first. If the remote host does not support CHAP authentication, it is allowed to participate in PAP authentication only.
Mandatory parameter, if the local host requests PAP authentication. Specifies the PAP identifier expected from a remote host. The value pap_id can be any string between 0 and 255 characters in length. A zero length value is represented by: expect_pap_id ""
Mandatory parameter, if the local host requests PAP authentication. Specifies the PAP password expected from a remote host. The value pap_passwd can be any string, between 0 and 255 characters in length. A zero length value is represented by: expect_pap_passwd ""
Mandatory parameter, if the local host requests CHAP authentication. Specifies the CHAP name expected from a remote host. The value chap_name can be any string, between 1 and 255 characters in length.
Mandatory parameter, if the local host requests CHAP authentication. Specifies the CHAP secret that is used with the challenge value to generate the response expected from the remote host. The value chap_secret can be any string, between 1 and 255 characters in length.
Optional parameter. Indicates whether the local host will participate in authentication negotiation requested by remote hosts, and the authentication protocol used.
The value mode can be off (no authentication), pap (authentication using PAP), chap (authentication using CHAP), or pap|chap (authentication using both PAP and CHAP). The default value is off.
Mandatory parameter, if the remote host requests PAP authentication. Specifies the PAP identifier sent to a remote host when it requests authentication. The value pap_id can be any string, between 0 and 255 characters in length. A zero length value is represented by: expect_pap_id ""
Mandatory parameter, if the remote host requests PAP authentication. Specifies the PAP password sent to a remote host when it requests authentication. The value pap_passwd can be any string, between 0 and 255 characters in length. A zero length value is represented by: expect_pap_passwd ""
Mandatory parameter, if the remote host requests CHAP authentication. Specifies the CHAP name sent to a remote host when it requests authentication. The value chap_name can be any string, between 1 and 255 characters in length.
Mandatory parameter, if the remote host requests CHAP authentication. Specifies the CHAP secret that is used with the challenge value to generate the response sent to the remote host. The value chap_secret can be any string, between 1 and 255 characters in length.
Examples
The following synchronous path definition shows that the local host will request both PAP and CHAP authentication from remote hosts, but will only participate in PAP negotiation when authentication is requested by a remote host:
sync_path
ip_interface ipdptp0
unix_device zsh0
expect_authentication pap|chap
expect_pap_id epic_id
expect_pap_passwd epic_passwd
expect_chap_name epic_name
chap_peer_secret epic_secret
send_authentication pap
send_pap_id papyrus_id
send_pap_passwd papyrus_passwd
|
The following synchronous path definitions show load-sharing enabled between two synchronous paths that use the same IP interface:
sync_path
ip_interface ipdptp2
unix_device hih0
sync_path
ip_interface ipdptp2
unix_device hih1
|
Defining Asynchronous Paths (dialup_path)
Asynchronous paths are identified in the file ppp.conf by the keyword dialup_path, which starts each definition. They can be associated with point-to-point and point-to-multipoint IP interfaces. Dynamic IP address allocation is supported over asynchronous paths only.
Synopsis
Asynchronous path definitions have the following general forms:
# Dialup path using static point-to-point IP interface dialup_path ip_interface ipdptpn expect_login_id user_name . . # Dialup path using dynamic point-to-point IP interface dialup_path ip_interface ipdptp* expect_login_id user_name . . # Dialup path using point-to-multipoint IP interface dialup_path ip_interface ipdn expect_login_id user_name remote_ip_addr ip_addr . . |
Keywords
Mandatory parameter for asynchronous paths. Indicates the start of an asynchronous (or dialup) path definition.
Mandatory parameter for asynchronous paths. Associates the asynchronous path with one of the point-to-point (ipdptpn) or point-to-multipoint (ipdn) IP interfaces defined in the ifconfig section of the file.
Point-to-point IP interfaces may be static or dynamic. Static point-to-point IP interfaces are identified by a number (ipdptp0, ipdptp1, ..., ipdptpn), and associate the dialup path with exactly one pair of source and destination IP addresses. For example:
dialup_path
ip_interface ipdptp0
|
Dynamic IP interfaces are used for dynamic IP address allocation on the server side, and are identified by an asterisk (ipdptp*). An interface is assigned on demand, for as long as there are interfaces available in the pool. For example:
dialup_path
ip_interface ipdptp*
|
Mandatory parameter for asynchronous paths used to initiate calls. Associates the asynchronous path with the name of one of the remote hosts defined in the file link.conf. The value name can be any character string.
Mandatory parameter for point-to-multipoint connections. Not required for point-to-point connections. Specifies the IP address of the remote host associated with the asynchronous path. The value ip_addr can be an IP address (expressed using dot notation) or a hostname that appears in the file /etc/hosts.
Mandatory parameter for asynchronous paths used to accept incoming calls. Specifies the login id expected from the remote host. This parameter is used to associate an incoming call with a specific asynchronous path; therefore each remote host must have a unique login id.
The value login can be any lowercase string, between 1 and 8 characters in length. It must correspond to the login id which appears in the relevant connect script on the remote host.
You must also create a user account with this login id, using admintool(1M). See "Adding User Accounts for Incoming Connections" for detailed instructions.
Optional parameter for point-to-point IP interfaces. When the IP interface is marked up, the route is added to the routing table automatically as the default destination. It is removed from the routing table when the IP interface is marked down. This parameter is most commonly used in client configurations--that is, links configured for outgoing calls only. It should never be used in conjunction with a routing daemon running on the machine, because this generates unnecessary network traffic.
Optional parameter for asynchronous paths. Specifies the number of seconds of inactivity that elapse before an asynchronous connection is closed automatically.
The value seconds can be any integer. The default value is 120 seconds (2 minutes). If the value seconds is set to zero, the connection remains open until closed explicitly.
Optional parameter for asynchronous paths. Enables dynamic IP address allocation at the client side only. When the value state is set to on, the client requests an IP address from a pool of interfaces assigned at the server side.
The value state can be on (enabled) or off (disabled). The default value is off.
Optional parameter for asynchronous paths. Hides the specified IP interface from the interface pool defined for dynamic IP address allocation on the server side. Can be used to reserve point-to-point IP interfaces so they can be used for synchronous connections.
Optional parameter for asynchronous paths. Accepts the IP addresses provided by the remote host, even if they differ from the IP addresses assigned to the interface locally.
The value state can be on (enabled) or off (disabled). The default value is off.
Optional parameter for asynchronous paths. Specifies the LCP asynchronous map used by the remote host. The LCP asynchronous map is a negotiated parameter that defines which control characters are transposed for transmission in PPP frames.
Control characters in the range 0x00 to 0x1f, such as CTRL-S and CTRL-Q, are used by some devices to implement software flow control. These devices may interpret the control characters transmitted in PPP frames, and close the link as a result. To avoid problems interoperating with these devices, all 32 control characters are automatically transposed for transmission, so that they appear outside of the significant range. Encoding and decoding the control characters incurs a processing overhead at both ends of the link.
The LCP asynchronous map defines which of the control characters is transposed by the remote host. A bit set to 1 in the value mask tells the remote host to transpose the corresponding control character; a bit set to zero tells the remote host to leave the control character unchanged. Provided you can predict how each device in the link will respond to the control characters it receives in PPP frames, you can tell the remote host to transpose a subset of the control characters, by specifying a different mask value. For example, a mask value of 0x0000ffff tells the remote host to transpose the first 16 control characters only.
By default, the value mask is set to 0xffffffff, which tells the remote host to transpose all 32 control characters. A value of 0x0 leaves all control characters unchanged.
Optional parameter for asynchronous paths. Indicates whether the Address and Protocol fields in the PPP frame are compressed. See Appendix A, PPP Link Operation for more information.
The value state can be on (enabled) or off (disabled). The default value is on.
Optional parameter for synchronous and asynchronous paths. Specifies the maximum receive unit (MRU) for the local machine. This parameter is carried in the LCP Configure-request frame, and sets the maximum transmission unit (MTU) for the remote host. See Appendix A, PPP Link Operation for more information.
By default, the value mru is set to 1500 bytes for Ethernet networks.
Optional parameter for synchronous and asynchronous paths. Specifies the number of seconds which elapse between consecutive LCP Configure-Request frames. Increasing the LCP restart timer may be necessary when connecting over long delay networks, such as satellite connections. See Appendix A, PPP Link Operation for more information.
The value seconds can be any integer greater than zero. The default value is 3 seconds.
Optional parameter for synchronous and asynchronous paths. Specifies the number of unanswered LCP Configure-Request frames generated before the endpoint is considered unreachable and the IP interface is marked as down. See Appendix A, PPP Link Operation for more information.
The value max_restart can be any integer in the range 1 to 255. The default value is 10. If the value max_restart is set to 255, LCP Configure-Request frames are generated periodically until the remote host finally responds.
Optional parameter for synchronous and asynchronous paths. Assigns a name to the link, which is used by ppptrace and pppstat. The value name can be any character string.
Optional parameter for synchronous and asynchronous paths. Indicates the current state of the header compression facility, which uses Van Jacobsen compression to improve performance over slow links. See Appendix A, PPP Link Operation for more information.
The value state can be vj (enabled) or off (disabled). The default value is vj.
expect_authentication mode
Optional parameter for synchronous and asynchronous paths. Indicates that the local host will request authentication from remote hosts, and the authentication protocol to be used. If authentication is enabled, remote hosts must authenticate themselves successfully, or the connection is closed.
The value mode can be off (no authentication), pap (authentication using PAP), chap (authentication using CHAP), or pap|chap (authentication using both PAP and CHAP). The default value is off.
If both PAP and CHAP are enabled, CHAP authentication is performed first. If the remote host does not support CHAP authentication, it is allowed to participate in PAP authentication only.
expect_pap_id pap_id
Mandatory parameter, if the local host requests PAP authentication. Specifies the PAP identifier expected from a remote host. The value pap_id can be any string between 0 and 255 characters in length. A zero length value is represented by: expect_pap_id ""
expect_pap_passwd pap_passwd
Mandatory parameter, if the local host requests PAP authentication. Specifies the PAP password expected from a remote host. The value pap_passwd can be any string, between 0 and 255 characters in length. A zero length value is represented by: expect_pap_passwd ""
expect_chap_name chap_name
Mandatory parameter, if the local host requests CHAP authentication. Specifies the CHAP name expected from a remote host. The value chap_name can be any string, between 1 and 255 characters in length.
chap_peer_secret chap_secret
Mandatory parameter, if the local host requests CHAP authentication. Specifies the CHAP secret that is used with the challenge value to generate the response expected from the remote host. The value chap_secret can be any string, between 1 and 255 characters in length.
send_authentication mode
Optional parameter. Indicates whether the local host will participate in authentication negotiation requested by remote hosts, and the authentication protocol used.
The value mode can be off (no authentication), pap (authentication using PAP), chap (authentication using CHAP), or pap|chap (authentication using both PAP and CHAP). The default value is off.
send_pap_id pap_id
Mandatory parameter, if the remote host requests PAP authentication. Specifies the PAP identifier sent to a remote host when it requests authentication. The value pap_id can be any string, between 0 and 255 characters in length. A zero length value is represented by: expect_pap_id ""
send_pap_passwd pap_passwd
Mandatory parameter, if the remote host requests PAP authentication. Specifies the PAP password sent to a remote host when it requests authentication. The value pap_passwd can be any string, between 0 and 255 characters in length. A zero length value is represented by: expect_pap_passwd ""
send_chap_name chap_name
Mandatory parameter, if the remote host requests CHAP authentication. Specifies the CHAP name sent to a remote host when it requests authentication. The value chap_name can be any string, between 1 and 255 characters in length.
chap_own_secret chap_secret
Mandatory parameter, if the remote host requests CHAP authentication. Specifies the CHAP secret that is used with the challenge value to generate the response sent to the remote host. The value chap_secret can be any string, between 1 and 255 characters in length.
Examples
The following asynchronous path definition shows a point-to-multipoint IP interface, and that the local host will request CHAP authentication from the remote host odyssey:
dialup_path
ip_interface ipd0
expect_login_id odyssey-login
remote_host odyssey
remote_ip_addr 129.xxx.xxx.119
inactivity_timeout 120
expect_authentication chap
expect_chap_name odyssey_name
chap_peer_secret odyssey_secret
|
The following asynchronous path definition shows dynamic IP address allocation enabled at the client side:
dialup_path
ip_interface ipdptp0
remote_host odyssey
request_ip_addr on
|
The following asynchronous path definitions show dynamic IP interfaces assigned to three dialup paths:
dialup_path
ip_interface ipdptp*
expect_login_id remote1
dialup_path
ip_interface ipdptp*
expect_login_id remote2
dialup_path
ip_interface ipdptp*
expect_login_id remote3
|
Assigning Path Defaults
The keyword defaults is used to define a list of default parameters that are applied to all subsequent synchronous and asynchronous path definitions. Any optional parameter may appear in the list of defaults. Mandatory parameters such as ip_interface or unix_device, or parameters used to create associations between files, such as remote_host or expect_login_id, must not be used as defaults.
Take care when combining defaults for both synchronous and asynchronous paths. In particular, do not attempt to enable dynamic IP addressing for synchronous paths. To avoid errors, it is better to define separate defaults for each type of path.
For example, the following path definitions show defaults set independently for both synchronous and asynchronous paths:
defaults
link_monitor on
lcp_mru 4352
sync_path
ip_interface ipdptp0
unix_device hih0
sync_path
ip_interface ipdptp1
unix_device hih1
defaults
inactivity_timeout 180
request_ip_addr on
dialup_path
ip_interface ipdptp2
remote_host server0
dialup_path
ip_interface ipdptp3
remote_host server1
|
Editing the Link Configuration File (link.conf)
The link configuration file (/etc/opt/SUNWconn/ppp/link.conf) describes the synchronous and asynchronous devices used to establish the PPP link, and includes dialing information for asynchronous links.
The first section in the link configuration file is used to define the location of the modem configuration file and the directory that contains the connect (or CHAT) scripts. By default, the modem configuration file is /etc/opt/SUNWconn/ppp/modems and the connect (or CHAT) scripts are contained in the directory /etc/opt/SUNWconn/ppp/script.
Defining Synchronous Devices
Synchronous devices are identified in the file link.conf by the keyword sync_device, which starts each definition.
Synopsis
Synchronous device definitions have the following general form:
sync_device syncdevn
unix_device device_name
line_speed line_speed
tx_clock txc
rx_clock rxc
|
Keywords
Mandatory parameter for synchronous devices. Indicates the start of a synchronous device definition, and assigns a name to the device.
Mandatory parameter for synchronous devices. Identifies the serial port used for synchronous communication, and associates the synchronous device with one of the synchronous paths defined in the file ppp.conf. The value device_name must be the device name of a synchronous serial interface installed in your machine.
For example, device names of the form zshn associate the path with one of the on-board serial interfaces. The device names of the form hihn, associate the path with a high-speed serial interface (HSI).
Mandatory parameter for synchronous devices when internal clocking is selected. The optimum line speed is dependent on the serial device selected. The default value proposed is the optimum line speed for one of the onboard serial interfaces (zsh). Refer to the manufacturer's documentation, if you are using a different serial device.
Mandatory parameter for synchronous devices. Specifies the source of the transmit clock signal. The value txc can be baud (internal clocking using system baud rate), txc (external clocking using the signal on the transmit pin), or rxc (external clocking using the signal on the receive pin). The transmit clock is most commonly set to baud (internal clocking), or txc (external clocking).
Mandatory parameter for synchronous devices. Specifies the source of the receive clock signal. The value rxc can be baud (internal clocking using system baud rate), txc (external clocking using the signal on the transmit pin), or rxc (external clocking using the signal on the receive pin). The receive clock is most commonly set to rxc, for both internal and external clocking.
Examples
The following synchronous device definition uses a high-speed serial interface (hih) and external clocking:
sync_device syncdev0
qqunix_devicee hih0
line_speed 0
tx_clock txc
rx_clock rxc
|
The following synchronous device definition uses one of the onboard serial interfaces (zsh) and internal clocking:
sync_device syncdev0
unix_device zsh0
line_speed 19200
tx_clock baud
rx_clock rxc
|
Defining Asynchronous Devices
Asynchronous devices are identified in the file link.conf by the keyword dialup_device, which starts each definition.
Synopsis
Asynchronous device definitions have the following general form:
dialup_device pppdevn
unix_device device_name
line_speed speed
modem modem_id
calls call_type
|
Keywords
Mandatory parameter for asynchronous devices. Indicates the start of an asynchronous device definition, and assigns a name to the device.
Mandatory parameter for asynchronous devices. Specifies the serial port used to connect between the host and the modem.
Mandatory parameter for asynchronous devices. Specifies the line speed for the connection between the host and the modem. For optimum performance, the line speed should be equal to, or greater than, the baud rate of the modem. The option ctsrts enables software flow control using Clear to Send and Ready to Send signals.
Mandatory parameter for asynchronous devices. Specifies the type of modem connected to the serial port, and associates the asynchronous device with one of the definitions in the modem database, which is the file /etc/opt/SUNWconn/ppp/modems by default. This parameter is set to none for a null modem configuration.
Mandatory parameter for asynchronous devices. Specifies the behavior of the device during the call setup phase. The value call_type can be answer (device accepts calls only), dial (device makes initiates calls only), or both (device accepts and initiates calls).
Examples
The following asynchronous device definitions use a BocaModem V.34 DataFax modems, and a line speed of 38400. The first device accepts and initiates calls; the second device initiates calls only:
dialup_device pppdev0
unix_device ttya
line_speed 38400
modem BocaModem V.34 DataFax
call_setup both
dialup_device pppdev1
unix_device ttyb
line_speed 38400
modem BocaModem V.34 DataFax
call_setup dial
|
The following asynchronous device definition accepts calls in a null modem configuration:
dialup_device pppdev0
unix_device ttya
line_speed 38400
modem none
call_setup answer
|
Defining a Pool of Asynchronous Devices
If you create more than one asynchronous device definition in the file link.conf, you can define a pool of asynchronous devices.
A pool of devices is associated with one or more remote hosts, in exactly the same way as an individual device. When an incoming or outgoing connection request for one of these hosts is processed, an asynchronous device is selected from the pool automatically, for as long as there are devices available in the pool.
Synopsis
A device pool definition has the following general form:
pool_device pooln pppdevn pppdevn+1 ... |
Keywords
pool_device pooln
Mandatory parameter to enable device pooling. Indicates the start of a device pool definition, and assigns a name to the device.
pppdevn pppdevn+1 ...
Mandatory parameters to enable device pooling. Specifies a list of asynchronous devices included in the device pool. Device names must be separated by spaces or commas.
Examples
The following example shows a device pool that consists of four asynchronous devices:
pool_device pool0 pppdev0 pppdev1 pppdev2 pppdev3 |
Defining Remote Hosts
The link configuration file (link.conf) also contains a list of the remote hosts to which the local host can initiate asynchronous connections. All remote host definitions must be entered after the synchronous and asynchronous device definitions.
Synopsis
A remote host definition has the following general form:
remote_host name
phone_number number
chat_script filename
use_device pppdevn
|
Keywords
Mandatory parameter for remote host definitions. Indicates the start of a remote host definition, and associates it with one of the asynchronous paths defined in the PPP path configuration file (ppp.conf).
Mandatory parameter for remote host definitions. Specifies the telephone number used to call the remote host. This can be an extension number if the call is within the same private branch exchange. Assign a "dummy" telephone number for null modem configurations. Telephone numbers can include both digits and characters, including special characters such as # and *. A comma (,) is used to insert a pause. The duration of the pause is usually 2 seconds, but is programmable on most modems. Telephone numbers that are prefixed by the letter P indicate that pulse dialing mode should be used.
Mandatory parameter for remote host definitions. Specifies the name of the file that contains the CHAT script, which defines the dialog used to set up the connection.
Optional parameter for remote hosts. Specifies a device, or pool of devices, to be used for this remote host.
Editing the Modem Database File (modems)
The modem database file (by default, /etc/opt/SUNWconn/ppp/modems) contains a description of the modems recognized by Solstice PPP, including the AT commands used by Solstice PPP and the pppsetmod(1M) command to initialize the modems for incoming and outgoing connections.
A list of the modems with which the current version of Solstice PPP has been tested is contained in the Solstice PPP 3.0.1 Installation Guide and Release Notes, which accompanies this product. Configuration information for these modems is contained in the modem database file /etc/opt/SUNWconn/ppp/modems.
The pppsetmod(1M)command scans the contents of the modem configuration file and sends the appropriate AT command to initialize the modems for a server configuration--that is, to wait for incoming calls. Modems used in a client configuration are initialized by the link manager each time a call is initiated.
By default, the modem is reset to a default mode each time it is switched off and back on again. You can also save the configuration to the modem, so that it is reinitialized in server mode when it is switched back on.
To initialize the modem, without saving the configuration, type:
prompt# /usr/bin/pppsetmod |
To initialize a modem, and save the configuration, type:
prompt# /usr/bin/pppsetmod --s |
You can modify the modems database file to add configuration information for your own modems, if they are not supported already. Refer to the documentation that you received from the manufacturer for details of the AT commands used to configure your modem.
For outgoing (client) connections, you must enable:
For incoming (server) connections, you must enable:
To add a new modem definition to the modem configuration file:
-
Edit the standard modem list to add a pointer to the command definition for your modem.
-
Add a command definition for your modem, including an init command (for outgoing connections), a reset command, and a server command (for incoming connections).
Note that some short buffer modems, such as the USRobotics Sporter 288, accept a restricted number of characters in each AT command. The commands can be concatenated as follows:
server = AT command1 AT command2 AT command3 ... AT commandN
Editing the CHAT (or Connect) Scripts
The CHAT (or connect) scripts define the exchange of information between the endpoints, which occurs during the link establishment phase. By default, the CHAT scripts are located in the directory /etc/opt/SUNWconn/ppp/script. You can change the location of the scripts by editing the location definition in the file link.conf, and moving the files.
You must create one CHAT script for each remote host to which the local host will initiate calls. It must contain a unique login id, which must correspond to a user account on the remote machine. If the remote host is running Solstice PPP, the login id must also appear as the value of the parameter expect_login_id associated with one of the dialup paths in the file ppp.conf on this machine.
CHAT scripts may be non-interactive (all the information to be exchanged is contained in the script) or interactive (the script prompts for user input).
The following example shows a simple CHAT script used to log in to remote hosts running a Solaris operating system. It is based on the template CHAT script delivered with Solstice PPP.
# Chat script for ppp login # # Set the line regarding the remote site configuration # Due to UUCP limitations some systems only accept cs7 # setline cs7 parodd # Start dialog with the remote host send RETURN # Set expected response, retry 3 times at 10 second intervals expect "ogin:" 10 onerror send BREAK repeat 3 # Set login id sent to remote host send "ppp1" # Set response expected from remote host expect "word: " 40 # Set the login password sent to the remote host send "okppp1" |
Changing the Login Id and Password
The login id and login password are used for the login sequence at the remote host. This sequence and the restrictions it imposes on the login dialog is operating system dependent.
If the remote host is running a Solaris environment, the login id must be all lowercase, and between 1 and 8 characters in length. The login password can contain both uppercase and lowercase characters, and must be equal to, or greater than, 6 characters in length; however, only the first 6 characters are significant.
Note -
To accept the call, there must be a user account with this login id and password on the remote host. If the remote host is running Solstice PPP the login id must also appear as the value of the expect_login_id parameter for one of the dialup paths in the file ppp.conf.
Edit the default CHAT script to replace the login id and the login password with the strings expected by the remote host. For example, the following CHAT script is used to establish a link with a login id mylogin and login password mypasswd.
# Chat script for ppp login # # Set the line regarding the remote site configuration # Due to UUCP limitations some systems only accept cs7 # setline cs7 parodd # Start dialog with the remote host send RETURN # Set expected response, retry 3 times at 10 second intervals expect "ogin:" 10 onerror send BREAK repeat 3 # Set login id (mylogin) sent to remote host send "mylogin" # Set response expected from remote host, wait up to 40 seconds expect "word: " 40 # # Set the login password (my passwd) of the remote host send "mypasswd" |
Changing the Number of Call Initiation Attempts
When the call is first initiated, the local host waits for a response from the remote host to begin the login sequence. The length of time the local host waits and the number of times the local host attempts to initiate the call are defined by the following entry:
expect "ogin:" 10 onerror send BREAK repeat 3 |
The first figure (10) defines the wait period, and the second figure (3) defines the number of call initiation attempts. You can modify both of these parameters.
For example, to retry the call initiation once every 5 seconds for a total of 10 attempts, change the line in the file to:
expect "ogin:" 5 onerror send BREAK repeat 10 |
Changing the Login Dialog
The default CHAT script assumes that a link is to be established between two Solaris systems. If you are connecting to a machine running operating system you may need to change the expected login dialog.
For example, to connect to an OpenVMS system running PPP, modify the connect script as follows:
send RETURN # Change "ogin:" to "name:" for OpenVMS expect "name:" 10 onerror send BREAK repeat 3 send "ppp" expect "word:" 40 # # Set the ppp password of the remote host here # send "xxxxx" |
The template CHAT script supports a simple method of logging in to a remote host. You can also modify and expand the CHAT script to create a more complex login dialog. Note that to initiate connections to a remote host running Solstice PPP, you must include a login id that is recognized by the remote host, and provide a way to start the Solstice PPP login service.
For example, the following CHAT script could be used to log in to a remote host running a Solaris environment, invoke mailx(1) to send an email message to indicate that the operation was successful, and start the Solstice PPP login service. Note that, in this case, the user account on the remote host that corresponds to the login id sent by the script must use /usr/bin/csh as the default shell.
# Chat script to invoke mailx on remote # # Set the line regarding the remote site configuration # Due to UUCP limitations some systems only accept cs7 # setline cs7 parodd # Start dialog with the remote host send RETURN # Set expected response, retry 3 times at 10 second intervals expect "ogin:" 10 onerror send BREAK repeat 3 # Set login id (mylogin) sent to remote host send "mylogin" # Set response expected from remote host, wait up to 40 seconds expect "word: " 40 # # Set the login password (my passwd) of the remote host send "mypasswd" # Set response expected from remote host (C-shell prompt) expect "%" # Set command sent to invoke mailx send "echo Login to remote successful | /usr/bin/mailx alias" # Set response expected from remote host (C-shell prompt) expect "%" # Start PPP login service (pppls) on remote send "/usr/sbin/pppls" |
The following CHAT script could be used to log in to a telnet terminal server:
# Chat script to login to telnet server # # Set the line regarding the remote site configuration # Due to UUCP limitations some systems only accept cs7 # setline cs7 parodd send RETURN expect "sername:" 10 onerror send RETURN repeat 5 send "your_username" expect "assword:" 35 send "your_password" expect "pc>" 10 onerror send RETURN repeat 2 send "terminal flowcontrol hardware" expect "pc>" 10 onerror send RETURN repeat 2 send "terminal databits 8" expect "pc>" 10 onerror send RETURN repeat 2 send "terminal parity none" expect "pc>" 10 onerror send RETURN repeat 2 send "terminal escape-character 0" expect "pc>" 10 onerror send RETURN repeat 2 send "terminal telnet-transparent" expect "pc>" 10 onerror send RETURN repeat 2 send "telnet your_own_machine" expect "ogin:" onerror send RETURN repeat 5 send "your_login_for_PPP" expect "assword:" 35 send "your_password _for_PPP" |
Interactive CHAT Scripts
Interactive CHAT scripts use echo and read keywords to display prompts and to acquire user input. The user input is stored as variables, which are identified by the $ prefix. For example, an interactive version of the previous script could be:
# Interactive Chat Script Example 1 # # Set the line regarding the remote site configuration # Due to UUCP limitations some systems only accept cs7 # setline cs7 parodd send RETURN expect "ogin:" 10 onerror send BREAK repeat 3 # Display prompt for login id echo "Enter your PPP login id: " # Read the login id from standard input and store in $login read $login # Send the login id to the remote host send "$login" # Set expected response, wait up to 40 seconds expect "word: " 40 # Display prompt for password echo "Enter your PPP password: " # Read the password from standard input and store in $password read $password # Send the password to the remote host send "$password" |
A more complex example shows a CHAT script used to manage the interaction between the user and a dynamic challenge-response authentication system:
# Interactive Chat Script Example 2
#
# Set the line regarding the remote site configuration
# Due to UUCP limitations some systems only accept cs7
# setline cs7 parodd
send RETURN
expect "ID:" 10 onerror send BREAK repeat 3
# Display prompt for user number id
echo "Enter your user ID number: "
# Read the user number id from standard input and store in $id
read $id
# Send the user number id to the remote host
send "$id"
# Set expected response, wait up to 10 seconds
# Receive the 6 character challenge code
expect "Challenge: ${challenge,6}" 10
# Display prompt for the challenge response
echo "Enter the response for Challenge ${challenge}: "
# Read the user number id from standard input
# and store in $response
read $response
# Send the challenge response to the remote host
send "$response"
# Set expected response, wait up to 20 seconds
expect "${host}:" 20
# Display status and name of remote host on successful connection
echo "Connected to ${host}\n"
# Start dialog with remote PPP
send "ppp"
|
In this example, the script reads a user id and sends it to the server. It waits for 10 seconds for a response from the server that starts with the string Challenge: and then reads the next six characters which represent the challenge value.
The script then displays the challenge value, waits for the user to enter the corresponding response, and sends this to the server. If the response is accepted, the connection is completed.
The {} brackets are used to delimit a variable when it appears with other characters as part of a character string.
CHAT Script Syntax
The CHAT script syntax, as described using BNF, is as follows:
<chat_script> ::= <script_cmd> | <chat_script> <script_cmd>
<script_cmd> ::= <send_cmd> | <expect_cmd> | <echo_cmd> |
<read_cmd>
<send_cmd> ::= "send" <quoted_string> | "send RETURN" | "send
BREAK"
<expect_cmd> ::= "expect" <quoted_string> <number>
<expect_error>
<expect_error> ::= "" | "onerror" <send_repeat>
<send_repeat> ::= <send_cmd> <repeat> | <send_cmd> | <repeat>
<repeat> ::= "repeat" <number> | "repeat"
<echo_cmd> ::= "echo" <quoted_string>
<read_cmd> ::= "read" <string>
<quoted_string> ::= "((<string>|<number>)[ ]*)+"
<string> ::= ([a-zA-Z/_-&.%#@~+*\(){}$;:?><!]+[0-9"']*)+
<number> ::= ([0-9,@*#$]*.)?[0-9,@*#$]+
|
- © 2010, Oracle Corporation and/or its affiliates