quest. When it is necessary for us to (Affordable web design)
quest. When it is necessary for us to send our credentials to the peer, pppd uses the secret that has a user field equal to the local username and the server field equal to the remote hostname. A sample PAP secrets file might look like this: # /etc/ppp/pap-secrets # # user server secret addrs vlager-pap c3po cresspahl vlager.vbrew.com c3po vlager DonaldGNUth c3po.lucas.com The first line is used to authenticate ourselves when talking to c3po. The second line describes how a user named c3po has to authenticate itself with us. The name vlager-pap in the first column is the username we send to c3po. By default, pppd picks the local hostname as the username, but you can also specify a different name by giving the user option followed by that name. When picking an entry from the pap-secrets file to identify us to a remote host, pppd must know the remote host’s name. As it has no way of finding that out, you must specify it on the command line using the remotename keyword followed by the peer’s hostname. To use the above entry for authentication with c3po, for example, we must add the following option to pppd’s command line: # pppd … remotename c3po user vlager-pap In the fourth field of the PAP secrets file (and all following fields), you can specify what IP addresses are allowed for that particular host, just as in the CHAP secrets file. The peer will be allowed to request only addresses from that list. In the sample file, the entry that c3po will use when it dials in — the line where c3po is the client -allows it to use its real IP address and no other. Note that PAP is a rather weak authentication method, you should use CHAP instead whenever possible. We will therefore not cover PAP in greater detail here; if you are interested in using it, you will find more PAP features in the pppd(8) manual page. Debugging Your PPP Setup By default, pppd logs any warnings and error messages to syslog’s daemon facility. You have to add an entry to syslog.conf that redirects these messages to a file or even the console; otherwise, syslog simply discards them. The following entry sends all messages to /var/log/ppp-log: daemon.* /var/log/ppp-log If your PPP setup doesn’t work right away, you should look in this log file. If the log messages don’t help, you can also turn on extra debugging output using the debug option. This output makes pppd log the contents of all control packets sent or received to syslog. All messages then go to the daemon facility. Finally, the most drastic way to check a problem is to enable kernel-level debugging by invoking pppd with the kdebug option. It is followed by a numeric argument that is the sum of the following values: 1 for general debug messages, 2 for printing the contents of all incoming HDLC frames, and 4 to make the driver print all outgoing HDLC frames. To capture kernel debugging messages, you must either run a syslogd daemon that reads the /proc/kmsg file, or the klogd daemon. Either of them directs kernel debugging to the syslogkernel facility. More Advanced PPP Configurations While configuring PPP to dial in to a network like the Internet is the most common application, there are those of you who have more advanced requirements. In this section we’ll talk about a few of the more advanced configurations possible with PPP under Linux. PPP Server Running pppd as a server is just a matter of configuring a serial tty device to invoke pppd with appropriate options when an incoming data call has been received. One way to do this is to create a special account, say ppp,