head 1.1; branch 1.1.1; access; symbols netbsd-11-0-RC4:1.1.1.4 netbsd-11-0-RC3:1.1.1.4 netbsd-11-0-RC2:1.1.1.4 netbsd-11-0-RC1:1.1.1.4 perseant-exfatfs-base-20250801:1.1.1.4 netbsd-11:1.1.1.4.0.2 netbsd-11-base:1.1.1.4 ppp-2-5-2:1.1.1.4 netbsd-10-1-RELEASE:1.1.1.3 perseant-exfatfs-base-20240630:1.1.1.3 perseant-exfatfs:1.1.1.3.0.28 perseant-exfatfs-base:1.1.1.3 netbsd-8-3-RELEASE:1.1.1.3 netbsd-9-4-RELEASE:1.1.1.3 netbsd-10-0-RELEASE:1.1.1.3 netbsd-10-0-RC6:1.1.1.3 netbsd-10-0-RC5:1.1.1.3 netbsd-10-0-RC4:1.1.1.3 netbsd-10-0-RC3:1.1.1.3 netbsd-10-0-RC2:1.1.1.3 netbsd-10-0-RC1:1.1.1.3 netbsd-10:1.1.1.3.0.26 netbsd-10-base:1.1.1.3 netbsd-9-3-RELEASE:1.1.1.3 cjep_sun2x-base1:1.1.1.3 cjep_sun2x:1.1.1.3.0.24 cjep_sun2x-base:1.1.1.3 cjep_staticlib_x-base1:1.1.1.3 netbsd-9-2-RELEASE:1.1.1.3 cjep_staticlib_x:1.1.1.3.0.22 cjep_staticlib_x-base:1.1.1.3 ppp-2-4-9:1.1.1.3 netbsd-9-1-RELEASE:1.1.1.3 phil-wifi-20200421:1.1.1.3 phil-wifi-20200411:1.1.1.3 is-mlppp:1.1.1.3.0.20 is-mlppp-base:1.1.1.3 phil-wifi-20200406:1.1.1.3 netbsd-8-2-RELEASE:1.1.1.3 netbsd-9-0-RELEASE:1.1.1.3 netbsd-9-0-RC2:1.1.1.3 netbsd-9-0-RC1:1.1.1.3 phil-wifi-20191119:1.1.1.3 netbsd-9:1.1.1.3.0.18 netbsd-9-base:1.1.1.3 phil-wifi-20190609:1.1.1.3 netbsd-8-1-RELEASE:1.1.1.3 netbsd-8-1-RC1:1.1.1.3 pgoyette-compat-merge-20190127:1.1.1.3 pgoyette-compat-20190127:1.1.1.3 pgoyette-compat-20190118:1.1.1.3 pgoyette-compat-1226:1.1.1.3 pgoyette-compat-1126:1.1.1.3 pgoyette-compat-1020:1.1.1.3 pgoyette-compat-0930:1.1.1.3 pgoyette-compat-0906:1.1.1.3 netbsd-7-2-RELEASE:1.1.1.1 pgoyette-compat-0728:1.1.1.3 netbsd-8-0-RELEASE:1.1.1.3 phil-wifi:1.1.1.3.0.16 phil-wifi-base:1.1.1.3 pgoyette-compat-0625:1.1.1.3 netbsd-8-0-RC2:1.1.1.3 pgoyette-compat-0521:1.1.1.3 pgoyette-compat-0502:1.1.1.3 pgoyette-compat-0422:1.1.1.3 netbsd-8-0-RC1:1.1.1.3 pgoyette-compat-0415:1.1.1.3 pgoyette-compat-0407:1.1.1.3 pgoyette-compat-0330:1.1.1.3 pgoyette-compat-0322:1.1.1.3 pgoyette-compat-0315:1.1.1.3 netbsd-7-1-2-RELEASE:1.1.1.1 pgoyette-compat:1.1.1.3.0.14 pgoyette-compat-base:1.1.1.3 netbsd-7-1-1-RELEASE:1.1.1.1 matt-nb8-mediatek:1.1.1.3.0.12 matt-nb8-mediatek-base:1.1.1.3 perseant-stdc-iso10646:1.1.1.3.0.10 perseant-stdc-iso10646-base:1.1.1.3 netbsd-8:1.1.1.3.0.8 netbsd-8-base:1.1.1.3 prg-localcount2-base3:1.1.1.3 prg-localcount2-base2:1.1.1.3 prg-localcount2-base1:1.1.1.3 prg-localcount2:1.1.1.3.0.6 prg-localcount2-base:1.1.1.3 pgoyette-localcount-20170426:1.1.1.3 bouyer-socketcan-base1:1.1.1.3 pgoyette-localcount-20170320:1.1.1.3 netbsd-7-1:1.1.1.1.0.14 netbsd-7-1-RELEASE:1.1.1.1 netbsd-7-1-RC2:1.1.1.1 netbsd-7-nhusb-base-20170116:1.1.1.1 bouyer-socketcan:1.1.1.3.0.4 bouyer-socketcan-base:1.1.1.3 pgoyette-localcount-20170107:1.1.1.3 netbsd-7-1-RC1:1.1.1.1 pgoyette-localcount-20161104:1.1.1.3 netbsd-7-0-2-RELEASE:1.1.1.1 localcount-20160914:1.1.1.3 netbsd-7-nhusb:1.1.1.1.0.12 netbsd-7-nhusb-base:1.1.1.1 pgoyette-localcount-20160806:1.1.1.3 pgoyette-localcount-20160726:1.1.1.3 pgoyette-localcount:1.1.1.3.0.2 pgoyette-localcount-base:1.1.1.3 netbsd-7-0-1-RELEASE:1.1.1.1 netbsd-7-0:1.1.1.1.0.10 netbsd-7-0-RELEASE:1.1.1.1 netbsd-7-0-RC3:1.1.1.1 netbsd-7-0-RC2:1.1.1.1 netbsd-7-0-RC1:1.1.1.1 PPP2_4_7:1.1.1.3 tls-maxphys-base:1.1.1.1 tls-maxphys:1.1.1.1.0.8 netbsd-7:1.1.1.1.0.6 netbsd-7-base:1.1.1.1 yamt-pagecache:1.1.1.1.0.4 yamt-pagecache-base9:1.1.1.1 tls-earlyentropy:1.1.1.1.0.2 tls-earlyentropy-base:1.1.1.1 riastradh-xf86-video-intel-2-7-1-pre-2-21-15:1.1.1.1 riastradh-drm2-base3:1.1.1.1 ppp-2-4-5:1.1.1.1 MACKERRAS:1.1.1; locks; strict; comment @# @; 1.1 date 2013.11.28.21.53.41; author christos; state Exp; branches 1.1.1.1; next ; commitid Esxn9c33hEocM5fx; 1.1.1.1 date 2013.11.28.21.53.41; author christos; state Exp; branches 1.1.1.1.4.1 1.1.1.1.8.1; next 1.1.1.2; commitid Esxn9c33hEocM5fx; 1.1.1.2 date 2014.10.25.18.43.25; author christos; state Exp; branches; next 1.1.1.3; commitid B9XxzXYxGfla5CVx; 1.1.1.3 date 2014.10.25.18.47.46; author christos; state Exp; branches 1.1.1.3.28.1; next 1.1.1.4; commitid ZmZx9IQVjp9I6CVx; 1.1.1.4 date 2025.01.08.19.54.36; author christos; state Exp; branches; next ; commitid akeeBvxAosn3EIEF; 1.1.1.1.4.1 date 2013.11.28.21.53.41; author yamt; state dead; branches; next 1.1.1.1.4.2; commitid K94L62dsYauo9yBx; 1.1.1.1.4.2 date 2014.05.22.15.51.08; author yamt; state Exp; branches; next ; commitid K94L62dsYauo9yBx; 1.1.1.1.8.1 date 2013.11.28.21.53.41; author tls; state dead; branches; next 1.1.1.1.8.2; commitid jTnpym9Qu0o4R1Nx; 1.1.1.1.8.2 date 2014.08.19.23.52.11; author tls; state Exp; branches; next ; commitid jTnpym9Qu0o4R1Nx; 1.1.1.3.28.1 date 2025.08.02.05.23.13; author perseant; state Exp; branches; next ; commitid 23j6GFaDws3O875G; desc @@ 1.1 log @Initial revision @ text @Starting with version 2.3.10, pppd includes support for `plugins' - pieces of code which can be loaded into pppd at runtime and which can affect its behaviour in various ways. The idea of plugins is to provide a way for people to customize the behaviour of pppd without having to either apply local patches to each version or get their patches accepted into the standard distribution. A plugin is a standard shared library object, typically with a name ending in .so. They are loaded using the standard dlopen() library call, so plugins are only supported on systems which support shared libraries and the dlopen call. At present pppd is compiled with plugin support only under Linux and Solaris. Plugins are loaded into pppd using the `plugin' option, which takes one argument, the name of a shared object file. The plugin option is a privileged option. If the name given does not contain a slash, pppd will look in the /usr/lib/pppd/ directory for the file, where is the version number of pppd, for example, 2.4.2. I suggest that you either give the full path name of the shared object file or just the base name; if you don't, it may be possible for unscrupulous users to substitute another shared object file for the one you mean to load, e.g. by setting the LD_LIBRARY_PATH variable. Plugins are usually written in C and compiled and linked to a shared object file in the appropriate manner for your platform. Using gcc under Linux, a plugin called `xyz' could be compiled and linked with the following commands: gcc -c -O xyz.c gcc -shared -o xyz.so xyz.o There are some example plugins in the pppd/plugins directory in the ppp distribution. Currently there is one example, minconn.c, which implements a `minconnect' option, which specifies a minimum connect time before the idle timeout applies. Plugins can access global variables within pppd, so it is useful for them to #include "pppd.h" from the pppd source directory. Every plugin must contain a global procedure called `plugin_init'. This procedure will get called (with no arguments) immediately after the plugin is loaded. Every plugin should also contain a variable called pppd_version declared as follows: char pppd_version[] = VERSION; If this declaration is included, pppd will not load the module if its version number differs from that compiled into the plugin binary. Plugins can affect the behaviour of pppd in at least four ways: 1. They can add extra options which pppd will then recognize. This is done by calling the add_options() procedure with a pointer to an array of option_t structures. The last entry in the array must have its name field set to NULL. 2. Pppd contains `hook' variables which are procedure pointers. If a given hook is not NULL, pppd will call the procedure it points to at the appropriate point in its processing. The plugin can set any of these hooks to point to its own procedures. See below for a description of the hooks which are currently implemented. 3. Plugin code can call any global procedures and access any global variables in pppd. 4. Plugins can register procedures to be called when particular events occur, using the `notifier' mechanism in pppd. The differences between hooks and notifiers are that a hook will only call one function, whereas a notifier can call an arbitrary number, and that a hook usually returns some value to pppd, whereas a notifier function returns nothing. Here is a list of the currently implemented hooks in pppd. int (*idle_time_hook)(struct ppp_idle *idlep); The idle_time_hook is called when the link first comes up (i.e. when the first network protocol comes up) and at intervals thereafter. On the first call, the idlep parameter is NULL, and the return value is the number of seconds before pppd should check the link activity, or 0 if there is to be no idle timeout. On subsequent calls, idlep points to a structure giving the number of seconds since the last packets were sent and received. If the return value is > 0, pppd will wait that many seconds before checking again. If it is <= 0, that indicates that the link should be terminated due to lack of activity. int (*holdoff_hook)(void); The holdoff_hook is called when an attempt to bring up the link fails, or the link is terminated, and the persist or demand option was used. It returns the number of seconds that pppd should wait before trying to reestablish the link (0 means immediately). int (*pap_check_hook)(void); int (*pap_passwd_hook)(char *user, char *passwd); int (*pap_auth_hook)(char *user, char *passwd, char **msgp, struct wordlist **paddrs, struct wordlist **popts); void (*pap_logout_hook)(void); These hooks are designed to allow a plugin to replace the normal PAP password processing in pppd with something different (e.g. contacting an external server). The pap_check_hook is called to check whether there is any possibility that the peer could authenticate itself to us. If it returns 1, pppd will ask the peer to authenticate itself. If it returns 0, pppd will not ask the peer to authenticate itself (but if authentication is required, pppd may exit, or terminate the link before network protocol negotiation). If it returns -1, pppd will look in the pap-secrets file as it would normally. The pap_passwd_hook is called to determine what username and password pppd should use in authenticating itself to the peer with PAP. The user string will already be initialized, by the `user' option, the `name' option, or from the hostname, but can be changed if necessary. MAXNAMELEN bytes of space are available at *user, and MAXSECRETLEN bytes of space at *passwd. If this hook returns 0, pppd will use the values at *user and *passwd; if it returns -1, pppd will look in the pap-secrets file, or use the value from the +ua or password option, as it would normally. The pap_auth_hook is called to determine whether the username and password supplied by the peer are valid. user and passwd point to null-terminated strings containing the username and password supplied by the peer, with non-printable characters converted to a printable form. The pap_auth_hook function should set msg to a string to be returned to the peer and return 1 if the username/password was valid and 0 if not. If the hook returns -1, pppd will look in the pap-secrets file as usual. If the username/password was valid, the hook can set *paddrs to point to a wordlist containing the IP address(es) which the peer is permitted to use, formatted as in the pap-secrets file. It can also set *popts to a wordlist containing any extra options for this user which pppd should apply at this point. The pap_logout_hook is called when the link is terminated, instead of pppd's internal `plogout' function. It can be used for accounting purposes. This hook is deprecated and will be replaced by a notifier. int (*chap_check_hook)(void); int (*chap_passwd_hook)(char *user, char *passwd); int (*chap_verify_hook)(char *name, char *ourname, int id, struct chap_digest_type *digest, unsigned char *challenge, unsigned char *response, char *message, int message_space) These hooks are designed to allow a plugin to replace the normal CHAP password processing in pppd with something different (e.g. contacting an external server). The chap_check_hook is called to check whether there is any possibility that the peer could authenticate itself to us. If it returns 1, pppd will ask the peer to authenticate itself. If it returns 0, pppd will not ask the peer to authenticate itself (but if authentication is required, pppd may exit, or terminate the link before network protocol negotiation). If it returns -1, pppd will look in the chap-secrets file as it would normally. The chap_passwd_hook is called to determine what password pppd should use in authenticating itself to the peer with CHAP. The user string will already be initialized, by the `user' option, the `name' option, or from the hostname, but can be changed if necessary. This hook is called only if pppd is a client, not if it is a server. MAXSECRETLEN bytes of space are available at *passwd. If this hook returns 0, pppd will use the value *passwd; if it returns -1, pppd will fail to authenticate. The chap_verify_hook is called to determine whether the peer's response to our CHAP challenge is valid -- it should return 1 if valid or 0 if not. The parameters are: * name points to a null-terminated string containing the username supplied by the peer, or the remote name specified with the "remotename" option. * ourname points to a null-terminated string containing the name of the local machine (the hostname, or the name specified with the "name" option). * id is the value of the id field from the challenge. * digest points to a chap_digest_type struct, which contains an identifier for the type of digest in use plus function pointers for functions for dealing with digests of that type. * challenge points to the challenge as a counted string (length byte followed by the actual challenge bytes). * response points to the response as a counted string. * message points to an area of message_space bytes in which to store any message that should be returned to the peer. int (*null_auth_hook)(struct wordlist **paddrs, struct wordlist **popts); This hook allows a plugin to determine what the policy should be if the peer refuses to authenticate when it is requested to. If the return value is 0, the link will be terminated; if it is 1, the connection is allowed to proceed, and in this case *paddrs and *popts can be set as for pap_auth_hook, to specify what IP addresses are permitted and any extra options to be applied. If the return value is -1, pppd will look in the pap-secrets file as usual. void (*ip_choose_hook)(u_int32_t *addrp); This hook is called at the beginning of IPCP negotiation. It gives a plugin the opportunity to set the IP address for the peer; the address should be stored in *addrp. If nothing is stored in *addrp, pppd will determine the peer's address in the usual manner. int (*allowed_address_hook)(u_int32_t addr) This hook is called to see if a peer is allowed to use the specified address. If the hook returns 1, the address is accepted. If it returns 0, the address is rejected. If it returns -1, the address is verified in the normal away against the appropriate options and secrets files. void (*snoop_recv_hook)(unsigned char *p, int len) void (*snoop_send_hook)(unsigned char *p, int len) These hooks are called whenever pppd receives or sends a packet. The packet is in p; its length is len. This allows plugins to "snoop in" on the pppd conversation. The hooks may prove useful in implmenting L2TP. void (*multilink_join_hook)(); This is called whenever a new link completes LCP negotiation and joins the bundle, if we are doing multilink. A plugin registers itself with a notifier by declaring a procedure of the form: void my_notify_proc(void *opaque, int arg); and then registering the procedure with the appropriate notifier with a call of the form add_notifier(&interesting_notifier, my_notify_proc, opaque); The `opaque' parameter in the add_notifier call will be passed to my_notify_proc every time it is called. The `arg' parameter to my_notify_proc depends on the notifier. A notify procedure can be removed from the list for a notifier with a call of the form remove_notifier(&interesting_notifier, my_notify_proc, opaque); Here is a list of the currently-implemented notifiers in pppd. * pidchange. This notifier is called in the parent when pppd has forked and the child is continuing pppd's processing, i.e. when pppd detaches from its controlling terminal. The argument is the pid of the child. * phasechange. This is called when pppd moves from one phase of operation to another. The argument is the new phase number. * exitnotify. This is called just before pppd exits. The argument is the status with which pppd will exit (i.e. the argument to exit()). * sigreceived. This is called when a signal is received, from within the signal handler. The argument is the signal number. * ip_up_notifier. This is called when IPCP has come up. * ip_down_notifier. This is called when IPCP goes down. * auth_up_notifier. This is called when the peer has successfully authenticated itself. * link_down_notifier. This is called when the link goes down. ## Id: PLUGINS,v 1.8 2008/06/15 07:02:18 paulus Exp ## @ 1.1.1.1 log @Import ppp-2.4.5 from git://ozlabs.org/~paulus/ppp.git @ text @@ 1.1.1.2 log @import new pppd: * Fixed a potential security issue in parsing option files (CVE-2014-3158). * There is a new "stop-bits" option, which takes an argument of 1 or 2, indicating the number of stop bits to use for async serial ports. * Various bug fixes. @ text @d287 1 a287 1 ## $Id: PLUGINS,v 1.8 2008/06/15 07:02:18 paulus Exp $ ## @ 1.1.1.3 log @* Fixed a potential security issue in parsing option files (CVE-2014-3158). * There is a new "stop-bits" option, which takes an argument of 1 or 2, indicating the number of stop bits to use for async serial ports. * Various bug fixes. @ text @d287 1 a287 1 ## Id: PLUGINS,v 1.8 2008/06/15 07:02:18 paulus Exp ## @ 1.1.1.3.28.1 log @Sync with HEAD @ text @d38 1 a38 3 them to #include "pppd.h" from the pppd source directory. Other header files can be included such as chap.h, mppe.h, and upap.h as needed per project. d45 1 a45 1 char pppd_version[] = PPPD_VERSION; d53 1 a53 1 done by calling the ppp_add_options() procedure with a pointer to an d244 1 a244 1 void (ppp_notify_fn)(void *opaque, int arg); d249 1 a249 4 ppp_add_notify(ppp_notify_t, ppp_notify_fn, opaque); The ppp_notify_t is an enumerated type that describes which notifier to attach the function to. Example: NF_EXIT, NF_SIGNALED, NF_IP_UP d258 1 a258 1 ppp_del_notify(ppp_notify_t, ppp_notify_fn, opaque); d262 1 a262 1 * NF_PID_CHANGE. This notifier is called in the parent when pppd has d267 1 a267 1 * NF_PHASE_CHANGE. This is called when pppd moves from one phase of d270 1 a270 1 * NF_EXIT. This is called just before pppd exits. The argument is d273 1 a273 1 * NF_SIGNALED. This is called when a signal is received, from within d276 1 a276 5 * NF_IP_UP. This is called when IPCP has come up. * NF_IP_DOWN. This is called when IPCP goes down. * NF_IPV6_UP. This is called when IP6CP has come up. d278 1 a278 1 * NF_IPV6_DOWN. This is called when IP6CP goes down. d280 1 a280 1 * NF_AUTH_UP. This is called when the peer has successfully d283 1 a283 27 * NF_LINK_DOWN. This is called when the link goes down. * NF_FORK. Called for each time pppd exists as a new process (child). Regarding MPPE keys and key-material for 2.5.0 release Sometimes it is necessary for a plugin to access details related to the authentication process. The NF_AUTH_UP callback notifier (client only) allows a plugin to inspect e.g. key details after authentication has been completed, but before the key material is cleared from memory for security reasons. There are in particularly 3 functions that allow one to inspect these keys: * bool mppe_keys_isset() * int mppe_get_recv_key(unsigned char *key, int length) * int mppe_get_send_key(unsigned char *key, int length) The first function indicates whether or not the key material is set and is valid. The two latter functions will allow one to obtain a copy of the respective receive and send keys. The return value of these functions is the length of the valid key material. For security reasons, one should take care to clear these copies when work is complete. The max length of MPPE receive ands send keys are up to 32 bytes long, or of MPPE_MAX_KEY_SIZE length. a284 3 The previous definitions of MPPE_MAX_KEY_LEN is the maximum length in which the Linux kernel will accept for MPPE key lengths. Plugins would access the MPPE keys directly via the: a285 2 extern u_char mppe_send_key[MPPE_MAX_KEY_LEN] extern u_char mppe_recv_key[MPPE_MAX_KEY_LEN] d287 1 a287 3 variables. The 2.5.0 release prohibits the direct access of these variables by making them static and private in favor of using the new API. @ 1.1.1.4 log @Import ppp-2.5.2, previous was 2.4.9 What's new in ppp-2.5.2 *********************** * Some old and probably unused code has been removed, notably the pppgetpass program and the passprompt plugin, and some of the files in the sample and scripts directories. * If a remote number has been set, it is available to scripts in the REMOTENUMBER environment variable. * The Solaris port has been updated, including updated installation instructions in README.sol2. * Various other bug fixes and minor enhancements. What was new in ppp-2.5.1 ************************* * The files copied to /etc/ppp (or /ppp) now have ".example" appended to their filenames, so as to indicate that they are just examples, and to avoid overwriting existing configuration files. * Pppd can now measure and log the round-trip time (RTT) of LCP echo-requests and record them in a binary file structured as a circular buffer. Other programs or scripts can examine the file and provide real-time statistics on link latency. This is enabled by a new "lcp-rtt-file" option. * New scripts net-init, net-pre-up and net-down are executed in the process of bringing the network interface up and down. They provide additional, more deterministic ways for pppd to interact with the rest of the networking configuration. * New options have been added to allow the system administrator to set the location of various scripts and secrets files. * A new "noresolvconf" option tells pppd not to write the /etc/ppp/resolv.conf file; DNS server addresses, if obtained from the peer, are still passed to scripts in the environment. * Pppd will now create the directory for the TDB connection database if it doesn't already exist. * Kernel module code for Solaris is no longer included. * Support for decompressing compressed packets has been removed from pppdump, because the zlib code used was old and potentially vulnerable. * Some old code has been removed. * Various other bug fixes and minor enhancements. What was new in ppp-2.5.0. ************************** The 2.5.0 release is a major release of pppd which contains breaking changes for third-party plugins, a complete revamp of the build-system and that allows for flexibility of configuring features as needed. In Summary: * Support for PEAP authentication by Eivind Næss and Rustam Kovhaev * Support for loading PKCS12 certificate envelopes * Adoption of GNU Autoconf / Automake build environment, by Eivind Næss and others. * Support for pkgconfig tool has been added by Eivind Næss. * Bunch of fixes and cleanup to PPPoE and IPv6 support by Pali Rohár. * Major revision to PPPD's Plugin API by Eivind Næss. - Defines in which describes what features was included in pppd - Functions now prefixed with explicit ppp_* to indicate that pppd functions being called. - Header files were renamed to better align with their features, and now use proper include guards - A pppdconf.h file is supplied to allow third-party modules to use the same feature defines pppd was compiled with. - No extern declarations of internal variable names of pppd, continued use of these extern variables are considered unstable. * Lots of internal fixes and cleanups for Radius and PPPoE by Jaco Kroon * Dropped IPX support, as Linux has dropped support in version 5.15 for this protocol. * Many more fixes and cleanups. * Pppd is no longer installed setuid-root. * New pppd options: - ipv6cp-noremote, ipv6cp-nosend, ipv6cp-use-remotenumber, ipv6-up-script, ipv6-down-script - -v, show-options - usepeerwins, ipcp-no-address, ipcp-no-addresses, nosendip * On Linux, any baud rate can be set on a serial port provided the kernel serial driver supports that. Note that if you have built and installed previous versions of this package and you want to continue having configuration and TDB files in /etc/ppp, you will need to use the --sysconfdir option to ./configure. For a list of the changes made during the 2.4 series releases of this package, see the Changes-2.4 file. @ text @d38 1 a38 3 them to #include "pppd.h" from the pppd source directory. Other header files can be included such as chap.h, mppe.h, and upap.h as needed per project. d45 1 a45 1 char pppd_version[] = PPPD_VERSION; d53 1 a53 1 done by calling the ppp_add_options() procedure with a pointer to an d244 1 a244 1 void (ppp_notify_fn)(void *opaque, int arg); d249 1 a249 4 ppp_add_notify(ppp_notify_t, ppp_notify_fn, opaque); The ppp_notify_t is an enumerated type that describes which notifier to attach the function to. Example: NF_EXIT, NF_SIGNALED, NF_IP_UP d258 1 a258 1 ppp_del_notify(ppp_notify_t, ppp_notify_fn, opaque); d262 1 a262 1 * NF_PID_CHANGE. This notifier is called in the parent when pppd has d267 1 a267 1 * NF_PHASE_CHANGE. This is called when pppd moves from one phase of d270 1 a270 1 * NF_EXIT. This is called just before pppd exits. The argument is d273 1 a273 1 * NF_SIGNALED. This is called when a signal is received, from within d276 1 a276 5 * NF_IP_UP. This is called when IPCP has come up. * NF_IP_DOWN. This is called when IPCP goes down. * NF_IPV6_UP. This is called when IP6CP has come up. d278 1 a278 1 * NF_IPV6_DOWN. This is called when IP6CP goes down. d280 1 a280 1 * NF_AUTH_UP. This is called when the peer has successfully d283 1 a283 27 * NF_LINK_DOWN. This is called when the link goes down. * NF_FORK. Called for each time pppd exists as a new process (child). Regarding MPPE keys and key-material for 2.5.0 release Sometimes it is necessary for a plugin to access details related to the authentication process. The NF_AUTH_UP callback notifier (client only) allows a plugin to inspect e.g. key details after authentication has been completed, but before the key material is cleared from memory for security reasons. There are in particularly 3 functions that allow one to inspect these keys: * bool mppe_keys_isset() * int mppe_get_recv_key(unsigned char *key, int length) * int mppe_get_send_key(unsigned char *key, int length) The first function indicates whether or not the key material is set and is valid. The two latter functions will allow one to obtain a copy of the respective receive and send keys. The return value of these functions is the length of the valid key material. For security reasons, one should take care to clear these copies when work is complete. The max length of MPPE receive ands send keys are up to 32 bytes long, or of MPPE_MAX_KEY_SIZE length. a284 3 The previous definitions of MPPE_MAX_KEY_LEN is the maximum length in which the Linux kernel will accept for MPPE key lengths. Plugins would access the MPPE keys directly via the: a285 2 extern u_char mppe_send_key[MPPE_MAX_KEY_LEN] extern u_char mppe_recv_key[MPPE_MAX_KEY_LEN] d287 1 a287 3 variables. The 2.5.0 release prohibits the direct access of these variables by making them static and private in favor of using the new API. @ 1.1.1.1.8.1 log @file PLUGINS was added on branch tls-maxphys on 2014-08-19 23:52:11 +0000 @ text @d1 287 @ 1.1.1.1.8.2 log @Rebase to HEAD as of a few days ago. @ text @a0 287 Starting with version 2.3.10, pppd includes support for `plugins' - pieces of code which can be loaded into pppd at runtime and which can affect its behaviour in various ways. The idea of plugins is to provide a way for people to customize the behaviour of pppd without having to either apply local patches to each version or get their patches accepted into the standard distribution. A plugin is a standard shared library object, typically with a name ending in .so. They are loaded using the standard dlopen() library call, so plugins are only supported on systems which support shared libraries and the dlopen call. At present pppd is compiled with plugin support only under Linux and Solaris. Plugins are loaded into pppd using the `plugin' option, which takes one argument, the name of a shared object file. The plugin option is a privileged option. If the name given does not contain a slash, pppd will look in the /usr/lib/pppd/ directory for the file, where is the version number of pppd, for example, 2.4.2. I suggest that you either give the full path name of the shared object file or just the base name; if you don't, it may be possible for unscrupulous users to substitute another shared object file for the one you mean to load, e.g. by setting the LD_LIBRARY_PATH variable. Plugins are usually written in C and compiled and linked to a shared object file in the appropriate manner for your platform. Using gcc under Linux, a plugin called `xyz' could be compiled and linked with the following commands: gcc -c -O xyz.c gcc -shared -o xyz.so xyz.o There are some example plugins in the pppd/plugins directory in the ppp distribution. Currently there is one example, minconn.c, which implements a `minconnect' option, which specifies a minimum connect time before the idle timeout applies. Plugins can access global variables within pppd, so it is useful for them to #include "pppd.h" from the pppd source directory. Every plugin must contain a global procedure called `plugin_init'. This procedure will get called (with no arguments) immediately after the plugin is loaded. Every plugin should also contain a variable called pppd_version declared as follows: char pppd_version[] = VERSION; If this declaration is included, pppd will not load the module if its version number differs from that compiled into the plugin binary. Plugins can affect the behaviour of pppd in at least four ways: 1. They can add extra options which pppd will then recognize. This is done by calling the add_options() procedure with a pointer to an array of option_t structures. The last entry in the array must have its name field set to NULL. 2. Pppd contains `hook' variables which are procedure pointers. If a given hook is not NULL, pppd will call the procedure it points to at the appropriate point in its processing. The plugin can set any of these hooks to point to its own procedures. See below for a description of the hooks which are currently implemented. 3. Plugin code can call any global procedures and access any global variables in pppd. 4. Plugins can register procedures to be called when particular events occur, using the `notifier' mechanism in pppd. The differences between hooks and notifiers are that a hook will only call one function, whereas a notifier can call an arbitrary number, and that a hook usually returns some value to pppd, whereas a notifier function returns nothing. Here is a list of the currently implemented hooks in pppd. int (*idle_time_hook)(struct ppp_idle *idlep); The idle_time_hook is called when the link first comes up (i.e. when the first network protocol comes up) and at intervals thereafter. On the first call, the idlep parameter is NULL, and the return value is the number of seconds before pppd should check the link activity, or 0 if there is to be no idle timeout. On subsequent calls, idlep points to a structure giving the number of seconds since the last packets were sent and received. If the return value is > 0, pppd will wait that many seconds before checking again. If it is <= 0, that indicates that the link should be terminated due to lack of activity. int (*holdoff_hook)(void); The holdoff_hook is called when an attempt to bring up the link fails, or the link is terminated, and the persist or demand option was used. It returns the number of seconds that pppd should wait before trying to reestablish the link (0 means immediately). int (*pap_check_hook)(void); int (*pap_passwd_hook)(char *user, char *passwd); int (*pap_auth_hook)(char *user, char *passwd, char **msgp, struct wordlist **paddrs, struct wordlist **popts); void (*pap_logout_hook)(void); These hooks are designed to allow a plugin to replace the normal PAP password processing in pppd with something different (e.g. contacting an external server). The pap_check_hook is called to check whether there is any possibility that the peer could authenticate itself to us. If it returns 1, pppd will ask the peer to authenticate itself. If it returns 0, pppd will not ask the peer to authenticate itself (but if authentication is required, pppd may exit, or terminate the link before network protocol negotiation). If it returns -1, pppd will look in the pap-secrets file as it would normally. The pap_passwd_hook is called to determine what username and password pppd should use in authenticating itself to the peer with PAP. The user string will already be initialized, by the `user' option, the `name' option, or from the hostname, but can be changed if necessary. MAXNAMELEN bytes of space are available at *user, and MAXSECRETLEN bytes of space at *passwd. If this hook returns 0, pppd will use the values at *user and *passwd; if it returns -1, pppd will look in the pap-secrets file, or use the value from the +ua or password option, as it would normally. The pap_auth_hook is called to determine whether the username and password supplied by the peer are valid. user and passwd point to null-terminated strings containing the username and password supplied by the peer, with non-printable characters converted to a printable form. The pap_auth_hook function should set msg to a string to be returned to the peer and return 1 if the username/password was valid and 0 if not. If the hook returns -1, pppd will look in the pap-secrets file as usual. If the username/password was valid, the hook can set *paddrs to point to a wordlist containing the IP address(es) which the peer is permitted to use, formatted as in the pap-secrets file. It can also set *popts to a wordlist containing any extra options for this user which pppd should apply at this point. The pap_logout_hook is called when the link is terminated, instead of pppd's internal `plogout' function. It can be used for accounting purposes. This hook is deprecated and will be replaced by a notifier. int (*chap_check_hook)(void); int (*chap_passwd_hook)(char *user, char *passwd); int (*chap_verify_hook)(char *name, char *ourname, int id, struct chap_digest_type *digest, unsigned char *challenge, unsigned char *response, char *message, int message_space) These hooks are designed to allow a plugin to replace the normal CHAP password processing in pppd with something different (e.g. contacting an external server). The chap_check_hook is called to check whether there is any possibility that the peer could authenticate itself to us. If it returns 1, pppd will ask the peer to authenticate itself. If it returns 0, pppd will not ask the peer to authenticate itself (but if authentication is required, pppd may exit, or terminate the link before network protocol negotiation). If it returns -1, pppd will look in the chap-secrets file as it would normally. The chap_passwd_hook is called to determine what password pppd should use in authenticating itself to the peer with CHAP. The user string will already be initialized, by the `user' option, the `name' option, or from the hostname, but can be changed if necessary. This hook is called only if pppd is a client, not if it is a server. MAXSECRETLEN bytes of space are available at *passwd. If this hook returns 0, pppd will use the value *passwd; if it returns -1, pppd will fail to authenticate. The chap_verify_hook is called to determine whether the peer's response to our CHAP challenge is valid -- it should return 1 if valid or 0 if not. The parameters are: * name points to a null-terminated string containing the username supplied by the peer, or the remote name specified with the "remotename" option. * ourname points to a null-terminated string containing the name of the local machine (the hostname, or the name specified with the "name" option). * id is the value of the id field from the challenge. * digest points to a chap_digest_type struct, which contains an identifier for the type of digest in use plus function pointers for functions for dealing with digests of that type. * challenge points to the challenge as a counted string (length byte followed by the actual challenge bytes). * response points to the response as a counted string. * message points to an area of message_space bytes in which to store any message that should be returned to the peer. int (*null_auth_hook)(struct wordlist **paddrs, struct wordlist **popts); This hook allows a plugin to determine what the policy should be if the peer refuses to authenticate when it is requested to. If the return value is 0, the link will be terminated; if it is 1, the connection is allowed to proceed, and in this case *paddrs and *popts can be set as for pap_auth_hook, to specify what IP addresses are permitted and any extra options to be applied. If the return value is -1, pppd will look in the pap-secrets file as usual. void (*ip_choose_hook)(u_int32_t *addrp); This hook is called at the beginning of IPCP negotiation. It gives a plugin the opportunity to set the IP address for the peer; the address should be stored in *addrp. If nothing is stored in *addrp, pppd will determine the peer's address in the usual manner. int (*allowed_address_hook)(u_int32_t addr) This hook is called to see if a peer is allowed to use the specified address. If the hook returns 1, the address is accepted. If it returns 0, the address is rejected. If it returns -1, the address is verified in the normal away against the appropriate options and secrets files. void (*snoop_recv_hook)(unsigned char *p, int len) void (*snoop_send_hook)(unsigned char *p, int len) These hooks are called whenever pppd receives or sends a packet. The packet is in p; its length is len. This allows plugins to "snoop in" on the pppd conversation. The hooks may prove useful in implmenting L2TP. void (*multilink_join_hook)(); This is called whenever a new link completes LCP negotiation and joins the bundle, if we are doing multilink. A plugin registers itself with a notifier by declaring a procedure of the form: void my_notify_proc(void *opaque, int arg); and then registering the procedure with the appropriate notifier with a call of the form add_notifier(&interesting_notifier, my_notify_proc, opaque); The `opaque' parameter in the add_notifier call will be passed to my_notify_proc every time it is called. The `arg' parameter to my_notify_proc depends on the notifier. A notify procedure can be removed from the list for a notifier with a call of the form remove_notifier(&interesting_notifier, my_notify_proc, opaque); Here is a list of the currently-implemented notifiers in pppd. * pidchange. This notifier is called in the parent when pppd has forked and the child is continuing pppd's processing, i.e. when pppd detaches from its controlling terminal. The argument is the pid of the child. * phasechange. This is called when pppd moves from one phase of operation to another. The argument is the new phase number. * exitnotify. This is called just before pppd exits. The argument is the status with which pppd will exit (i.e. the argument to exit()). * sigreceived. This is called when a signal is received, from within the signal handler. The argument is the signal number. * ip_up_notifier. This is called when IPCP has come up. * ip_down_notifier. This is called when IPCP goes down. * auth_up_notifier. This is called when the peer has successfully authenticated itself. * link_down_notifier. This is called when the link goes down. ## Id: PLUGINS,v 1.8 2008/06/15 07:02:18 paulus Exp ## @ 1.1.1.1.4.1 log @file PLUGINS was added on branch yamt-pagecache on 2014-05-22 15:51:08 +0000 @ text @d1 287 @ 1.1.1.1.4.2 log @sync with head. for a reference, the tree before this commit was tagged as yamt-pagecache-tag8. this commit was splitted into small chunks to avoid a limitation of cvs. ("Protocol error: too many arguments") @ text @a0 287 Starting with version 2.3.10, pppd includes support for `plugins' - pieces of code which can be loaded into pppd at runtime and which can affect its behaviour in various ways. The idea of plugins is to provide a way for people to customize the behaviour of pppd without having to either apply local patches to each version or get their patches accepted into the standard distribution. A plugin is a standard shared library object, typically with a name ending in .so. They are loaded using the standard dlopen() library call, so plugins are only supported on systems which support shared libraries and the dlopen call. At present pppd is compiled with plugin support only under Linux and Solaris. Plugins are loaded into pppd using the `plugin' option, which takes one argument, the name of a shared object file. The plugin option is a privileged option. If the name given does not contain a slash, pppd will look in the /usr/lib/pppd/ directory for the file, where is the version number of pppd, for example, 2.4.2. I suggest that you either give the full path name of the shared object file or just the base name; if you don't, it may be possible for unscrupulous users to substitute another shared object file for the one you mean to load, e.g. by setting the LD_LIBRARY_PATH variable. Plugins are usually written in C and compiled and linked to a shared object file in the appropriate manner for your platform. Using gcc under Linux, a plugin called `xyz' could be compiled and linked with the following commands: gcc -c -O xyz.c gcc -shared -o xyz.so xyz.o There are some example plugins in the pppd/plugins directory in the ppp distribution. Currently there is one example, minconn.c, which implements a `minconnect' option, which specifies a minimum connect time before the idle timeout applies. Plugins can access global variables within pppd, so it is useful for them to #include "pppd.h" from the pppd source directory. Every plugin must contain a global procedure called `plugin_init'. This procedure will get called (with no arguments) immediately after the plugin is loaded. Every plugin should also contain a variable called pppd_version declared as follows: char pppd_version[] = VERSION; If this declaration is included, pppd will not load the module if its version number differs from that compiled into the plugin binary. Plugins can affect the behaviour of pppd in at least four ways: 1. They can add extra options which pppd will then recognize. This is done by calling the add_options() procedure with a pointer to an array of option_t structures. The last entry in the array must have its name field set to NULL. 2. Pppd contains `hook' variables which are procedure pointers. If a given hook is not NULL, pppd will call the procedure it points to at the appropriate point in its processing. The plugin can set any of these hooks to point to its own procedures. See below for a description of the hooks which are currently implemented. 3. Plugin code can call any global procedures and access any global variables in pppd. 4. Plugins can register procedures to be called when particular events occur, using the `notifier' mechanism in pppd. The differences between hooks and notifiers are that a hook will only call one function, whereas a notifier can call an arbitrary number, and that a hook usually returns some value to pppd, whereas a notifier function returns nothing. Here is a list of the currently implemented hooks in pppd. int (*idle_time_hook)(struct ppp_idle *idlep); The idle_time_hook is called when the link first comes up (i.e. when the first network protocol comes up) and at intervals thereafter. On the first call, the idlep parameter is NULL, and the return value is the number of seconds before pppd should check the link activity, or 0 if there is to be no idle timeout. On subsequent calls, idlep points to a structure giving the number of seconds since the last packets were sent and received. If the return value is > 0, pppd will wait that many seconds before checking again. If it is <= 0, that indicates that the link should be terminated due to lack of activity. int (*holdoff_hook)(void); The holdoff_hook is called when an attempt to bring up the link fails, or the link is terminated, and the persist or demand option was used. It returns the number of seconds that pppd should wait before trying to reestablish the link (0 means immediately). int (*pap_check_hook)(void); int (*pap_passwd_hook)(char *user, char *passwd); int (*pap_auth_hook)(char *user, char *passwd, char **msgp, struct wordlist **paddrs, struct wordlist **popts); void (*pap_logout_hook)(void); These hooks are designed to allow a plugin to replace the normal PAP password processing in pppd with something different (e.g. contacting an external server). The pap_check_hook is called to check whether there is any possibility that the peer could authenticate itself to us. If it returns 1, pppd will ask the peer to authenticate itself. If it returns 0, pppd will not ask the peer to authenticate itself (but if authentication is required, pppd may exit, or terminate the link before network protocol negotiation). If it returns -1, pppd will look in the pap-secrets file as it would normally. The pap_passwd_hook is called to determine what username and password pppd should use in authenticating itself to the peer with PAP. The user string will already be initialized, by the `user' option, the `name' option, or from the hostname, but can be changed if necessary. MAXNAMELEN bytes of space are available at *user, and MAXSECRETLEN bytes of space at *passwd. If this hook returns 0, pppd will use the values at *user and *passwd; if it returns -1, pppd will look in the pap-secrets file, or use the value from the +ua or password option, as it would normally. The pap_auth_hook is called to determine whether the username and password supplied by the peer are valid. user and passwd point to null-terminated strings containing the username and password supplied by the peer, with non-printable characters converted to a printable form. The pap_auth_hook function should set msg to a string to be returned to the peer and return 1 if the username/password was valid and 0 if not. If the hook returns -1, pppd will look in the pap-secrets file as usual. If the username/password was valid, the hook can set *paddrs to point to a wordlist containing the IP address(es) which the peer is permitted to use, formatted as in the pap-secrets file. It can also set *popts to a wordlist containing any extra options for this user which pppd should apply at this point. The pap_logout_hook is called when the link is terminated, instead of pppd's internal `plogout' function. It can be used for accounting purposes. This hook is deprecated and will be replaced by a notifier. int (*chap_check_hook)(void); int (*chap_passwd_hook)(char *user, char *passwd); int (*chap_verify_hook)(char *name, char *ourname, int id, struct chap_digest_type *digest, unsigned char *challenge, unsigned char *response, char *message, int message_space) These hooks are designed to allow a plugin to replace the normal CHAP password processing in pppd with something different (e.g. contacting an external server). The chap_check_hook is called to check whether there is any possibility that the peer could authenticate itself to us. If it returns 1, pppd will ask the peer to authenticate itself. If it returns 0, pppd will not ask the peer to authenticate itself (but if authentication is required, pppd may exit, or terminate the link before network protocol negotiation). If it returns -1, pppd will look in the chap-secrets file as it would normally. The chap_passwd_hook is called to determine what password pppd should use in authenticating itself to the peer with CHAP. The user string will already be initialized, by the `user' option, the `name' option, or from the hostname, but can be changed if necessary. This hook is called only if pppd is a client, not if it is a server. MAXSECRETLEN bytes of space are available at *passwd. If this hook returns 0, pppd will use the value *passwd; if it returns -1, pppd will fail to authenticate. The chap_verify_hook is called to determine whether the peer's response to our CHAP challenge is valid -- it should return 1 if valid or 0 if not. The parameters are: * name points to a null-terminated string containing the username supplied by the peer, or the remote name specified with the "remotename" option. * ourname points to a null-terminated string containing the name of the local machine (the hostname, or the name specified with the "name" option). * id is the value of the id field from the challenge. * digest points to a chap_digest_type struct, which contains an identifier for the type of digest in use plus function pointers for functions for dealing with digests of that type. * challenge points to the challenge as a counted string (length byte followed by the actual challenge bytes). * response points to the response as a counted string. * message points to an area of message_space bytes in which to store any message that should be returned to the peer. int (*null_auth_hook)(struct wordlist **paddrs, struct wordlist **popts); This hook allows a plugin to determine what the policy should be if the peer refuses to authenticate when it is requested to. If the return value is 0, the link will be terminated; if it is 1, the connection is allowed to proceed, and in this case *paddrs and *popts can be set as for pap_auth_hook, to specify what IP addresses are permitted and any extra options to be applied. If the return value is -1, pppd will look in the pap-secrets file as usual. void (*ip_choose_hook)(u_int32_t *addrp); This hook is called at the beginning of IPCP negotiation. It gives a plugin the opportunity to set the IP address for the peer; the address should be stored in *addrp. If nothing is stored in *addrp, pppd will determine the peer's address in the usual manner. int (*allowed_address_hook)(u_int32_t addr) This hook is called to see if a peer is allowed to use the specified address. If the hook returns 1, the address is accepted. If it returns 0, the address is rejected. If it returns -1, the address is verified in the normal away against the appropriate options and secrets files. void (*snoop_recv_hook)(unsigned char *p, int len) void (*snoop_send_hook)(unsigned char *p, int len) These hooks are called whenever pppd receives or sends a packet. The packet is in p; its length is len. This allows plugins to "snoop in" on the pppd conversation. The hooks may prove useful in implmenting L2TP. void (*multilink_join_hook)(); This is called whenever a new link completes LCP negotiation and joins the bundle, if we are doing multilink. A plugin registers itself with a notifier by declaring a procedure of the form: void my_notify_proc(void *opaque, int arg); and then registering the procedure with the appropriate notifier with a call of the form add_notifier(&interesting_notifier, my_notify_proc, opaque); The `opaque' parameter in the add_notifier call will be passed to my_notify_proc every time it is called. The `arg' parameter to my_notify_proc depends on the notifier. A notify procedure can be removed from the list for a notifier with a call of the form remove_notifier(&interesting_notifier, my_notify_proc, opaque); Here is a list of the currently-implemented notifiers in pppd. * pidchange. This notifier is called in the parent when pppd has forked and the child is continuing pppd's processing, i.e. when pppd detaches from its controlling terminal. The argument is the pid of the child. * phasechange. This is called when pppd moves from one phase of operation to another. The argument is the new phase number. * exitnotify. This is called just before pppd exits. The argument is the status with which pppd will exit (i.e. the argument to exit()). * sigreceived. This is called when a signal is received, from within the signal handler. The argument is the signal number. * ip_up_notifier. This is called when IPCP has come up. * ip_down_notifier. This is called when IPCP goes down. * auth_up_notifier. This is called when the peer has successfully authenticated itself. * link_down_notifier. This is called when the link goes down. ## Id: PLUGINS,v 1.8 2008/06/15 07:02:18 paulus Exp ## @