DHCPC plugin for PPPD 2.4.2 =========================== Overview: This plugin is a hybrid DHCP client and proxy server. It allows a ppp server to request an IP address from a local or remote DHCP server on behalf of the client. To the DHCP server it appears to be a DHCP/BOOTP relay agent. The peer's authentication name is used as the DHCP client identifier (to allow static leases to be granted to some users). Installation: Place files in a pppd/plugins/dhcp directory of a built and installed PPPD distribution. Run 'make' followed by 'make install'. Configuration: In your ppp options file, add the line: plugin dhcpc.so Following the above line, you should give the options for the plugin: dhcp-interface <interface name> This option specifies which interface DHCP requests should be broadcast. The default is 'eth0'. dhcp-relay-address <local ip address> This option specified the local IP address of the system running this proxy, as should be identified to the DHCP server in the 'giaddr' field of DHCP requests. Normal server behavor should be to send DHCP responses to this address. The default is the primary address bound to the dhcp interface. N.B. If you are using ISC DHCPD on the local system, this should NOT be set to the loopback address (127.0.0.1). The ISC DHCPD treats this as a special debugging mode and does behave according to the RFCs. dhcp-server <server ip address> Address of the DHCP server. Specifying this option will disable normal DHCP broadcast behaviour and force all requests to be sent to the specified IP address only. The default behaviour is to send DHCP broadcasts on the specified dhcp interface. dhcp-subnet-selection <network ip address> This specifies the address of the network for which to request leases. (The address should be specified without a netmask.) Your DHCP server must support the 'Subnet Selection' DHCP option as per RFC 3011 for this option to work. If subnet selection is not used, most DHCP servers will allocate leases from the same subnet as that in which 'dhcp-relay-address' resides. CURRENT LIMITATIONS Presently, there is a potential problem if a user is able to establish multiple simultaneous connections under the same login credentials. Because the username is used as the client identifier, if the user establishes a second connection without first closing the original connection, this new connection will still be allocated the same lease and IP address as the original connection. Clearly only one connection will be routeable at a time. The problem is compounded when either of the connections is closed. This will trigger a release of the DHCP lease, even though there is still a current connection using it. The lease could then potentially be reallocated to another users connection. It is my intention to introduce a mechanism in the next version to overcome this limitation.