Release notes for dhcp-forwarder, version 0.1.3
===============================================

This program is used to forward DHCP and BOOTP messages between two
networks with different broadcast domains.


FEATURES
========
- runs as non-root in a chroot-environment

- uses AF_INET sockets to listen for DHCP messages. Thus, packetfilters
  like iptables can be used to filter incoming messages

- supports DHCP agent IDs as described in RFC 3046. These IDs can be
  defined freely.

- small memory-footprint:
  | $ ./dhcp-fwd -v; ls -l dhcp-fwd; file dhcp-fwd;
  | dhcp-forwarder 0.1.3
  | -rwxrwxr-x    1 ensc     ensc        30040 Jun 14 14:28 dhcp-fwd
  | dhcp-fwd: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), statically linked, stripped

  | # ps hu `pidof dhcp-fwd`
  | dhcpfwd  19086  0.0  0.0    72   72 pts/3    S    14:29   0:00 dhcp-fwd -c /etc/dhcp-fwd.conf


INSTALLATION
============
- build with the usual './configure && make && make install'. When
  not having an actual dietlibc, you will need to call ./configure
  with a '--disable-dietlibc' option. *NOT* using this flag results
  in significantly smaller binaries and memory consumption.

  Old dietlibc versions (<0.17) are causing strange warnings while
  compiling and I am not not sure if they are harmful or not. I am
  running dhcp-fwd with dietlibc-0.17 successfully.

- install contrib/dhcp-fwd.conf in $(sysconfdir)/ and adapt it to your
  needs; the possible settings are described in this file.

  An alternative cfg-file can be given on the commandline with the
  '-c' option.

- start '$(sbindir)/dhcp-fwd'


If you are a RH 7.3 user, I suggest to build an RPM with

|     rpm -tb dhcp-forwarder-0.1.tar.bz2 --without dietlibc'

and install the resulting binary. The '--without dietlibc' is neccessary
since RH ships an elder dietlibc. After installation, the daemon can be
started with

|     service dhcp-fwd start

and enabled permanently with

|     chkconfig dhcp-fwd on


BUGS
====
- no documentation; only contrib/dhcp-fwd.conf contains some information

- bad behavior when serverside-interface has a smaller MTU than the
  MTU on the server itself. An example is

         [Server]-- Ethernet --[Router]-- PPP --[Forwarder]

  (example is not completely correct since the program assumes an MTU
  of 1500 or greater; but when server is on a special device (IPSec
  VLAN??) a similar situation can occur)

- on client-side only ethernet supported; same holds on server-side if
  server is a broadcast-address

- works with Linux only; the device-binding stuff is not specified by
  SUSv3 and I do not know enough about other systems to provide a
  better solution

- it does not set the agent-id on large DHCP-messages although it
  would be possible to enlarge the package or to use the
  bootfile/sname header-fields

- untested; particularly, I would like to get feedback about success
  or failures in the following areas:
  * cooperation within an IPv6 network or
  * running on a big-endian host (will probably fail)
  * IP fragmentation
