| 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. |