Client misconfigured after DHCPINFORM/DHCPACK

[Paine, Thomas Asa]

Problem:
        I had recent issues after upgrading to release 3.0.5.  In versions sometime after 3.0.3 (checked 3.0.5 and the alpha release of 3.1.0a2) the service started doing the subnet lookup (for INFORMs) based on the gip (the relay's IP address) instead of cip (the client's ip address).  I don't now the reasoning behind this, but it causes clients
to become misconfigured.  Why wouldn't you always use the client's IP addr to resolve dhcp options?  Is this a bug or by design?  If by design, what RFC stipulates using the relay's IP addr?

Scenario:
        Some of our LANs/VLANs are configured as follows
                each VLAN as two router interfaces (physical)
                1 router is publicly addressed
                1 router is privately addressed
                both routers relay dhcp messages to the same ISC DHCP server
                each vlan has a corresponding "shared-network" in the dhcpd configuration
                Each shared-network has one publicly addressed scope/pool for "known" clients
                        "known" hosts are given one set of DNS information
                Each shared-network has one privately addressed scope/pool for "unknown" clients
                        "unknown" hosts are given a different set of DNS information
                After hosts obtain their correct lease and other options the following happens
                        a valid client sends a DHCPINFORM message
                        Both routers on that segment relay the broadcast to the ISC DCHP server
                        Server potentially DHCPACKs with the wrong DNS information
                        Client's name resolution is broken at that point

This is what I found...

In the inform handler code for release 3.0.5 there is this....

        /* Find the subnet that the client is on. */
        if (gip.len) {
                /* XXX - do subnet selection relay agent suboption here */
                find_subnet(&subnet, gip, MDL);
        } else {
                /* XXX - do subnet selection (not relay agent) option here */
                find_subnet(&subnet, cip, MDL);
        }

        /* Sourceless packets don't make sense here. */
        if (!subnet) {
                log_info ("%s: unknown subnet for address %s",
                          msgbuf, gip.len ? piaddr(gip) : piaddr(cip));
                return;
        }


In the inform handler code for release 3.0.3 there is this...

        /* Find the subnet that the client is on. */
        oc = (struct option_cache *)0;
        find_subnet (&subnet , cip, MDL);

        /* Sourceless packets don't make sense here. */
        if (!subnet) {
                log_info ("%s: unknown subnet %s",
                          msgbuf, inet_ntoa (packet -> raw -> giaddr));
                return;
        }


~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
   Thomas Paine {paineta at uwec.edu)}
   University of Wisconsin - Eau Claire
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~