Dear lazyweb,

I need your help. Situation: I've got here a little embedded device that is suspected to violate DHCP standards, specifically RFC 2132 section 9.7, and I am supposed to setup a test which will confirm this suspicion.

The section says that DHCPOFFER packages must include an option 'server identifier' which is supposed to be set to the IP of the DHCP server ( sometimes the network is setup in this way that there is a machine which relays all traffic - including DHCP packets - to the clients so they cannot just take a look at source IP of the incoming packets to know where the DHCP server is ). The clients are supposed to use this IP for all subsequent communication with DHCP server.

Now, the embedded device is suspected to ignore the 'server identifier' option and send all subsequent DHCPREQUESTS to the IP from where it got its DHCPOFFER, so if there is a relaying machine in between, the device fails to renew its IP.

I have no access to the original setup where this bug was supposedly detected. All I have here is the device and 1 laptop running, of course, Debian. So I have to

1) produce a DHCPOFFER packet whose source IP would be different than the 'server identifier' option inside it,
2) set the lease time to, lets say, 10 seconds ,
3) sniff the network and see which IP the embedded device uses to renew its lease.

The problem is with 1). There are 3 DHCP servers in Debian: dhcp3-server, dnsmasq and udhcpd. AFAIK, dnsmasq and udhcpd do not even let me configure the 'server identifier' , so looks like my only option is to use 'dhcp3-server'.

So I have set up the server to listen on laptop's eth0 with the following dhcpd.conf: ( eth0's IP is 10.0.0.1 )

(... snip...)

subnet 10.0.0.0 netmask 255.255.255.0 {

  range 10.0.0.3 10.0.0.254;

  option domain-name-servers 192.168.1.60;

  option domain-name "utumno.com";

  option routers 10.0.0.1;

  option broadcast-address 10.0.0.255;

  max-lease-time 10;

  server-identifier 120.30.0.1;

}

I connected the device and everything works: the device gets it's IP, renews it and so on. However, the problem is that dhcp3-server is too clever and as soon as I set the 'server-identifier' option to 120.30.0.1, it starts sending its DHCPOFFER and DHCPACK packets FROM THIS IP, even though it is listening in eth0 which has 10.0.0.1. So for my testing purposes, this setup is useless.

Now, anobody has an idea how can I either

a) force dhcp3-server to produce the desired DHCPOFFER packages?
b) rewrite the source IP with iptables ( iptables -t nat -A POSTROUTING -o eth0 -j SNAT --to-source=10.0.0.1 doesn't work! Is it because such packets do not go thru NAT? )
c) some other suggestion?