[Dnsmasq-discuss] A problem with kpac_dhcp_helper, dhcprelay, and dnsmasq

[Simon Kelley]

Jon Nelson wrote:
> On Fri, Jan 2, 2009 at 4:29 AM, Simon Kelley <simon at thekelleys.org.uk> wrote:
>> Jon Nelson wrote:
>>
>>> dnsmasq[3667]: DHCP packet: transaction-id is 1655180374
>>> dnsmasq[3667]: Available DHCP range: 192.168.2.0 -- 192.168.2.150
>>> dnsmasq[3667]: DHCPINFORM(eth1) 127.0.0.1 <null>
>>>
>>> tcpdump shows the workstation making the request, the dhcp helper
>>> re-making the request on the client's behalf, and the dhcp helper
>>> **not** relaying the response back to the client. It does this
>>> correctly for other dhcp requests but not this one. One might be going
>>> wrong? Does dnsmasq have forwarding capability?
>>>
>> Dnsmasq thinks that the request is coming from 127.0.0.1 and has no valid
>> mac address, so it has no way to send back a reply to the relay or the
>> original sender.
>>
>> Jon, could you use wireshark or "tcpdump -s 0" to grab the packets being
>> send from the host to the relay and from the relay to dnsmasq? It may be
>> possible to change dnsmasq's behavior to work in this case.
> 
> Yeah no problem. Do you want them sent to you directly as attachments
> or textified for this list?
> 

Got them, thanks. The problem is this: the helper is sending the
DHCPINFORM as a broadcast, with source address of itself (192.168.2.20)
but the "client address" field in the DHCP request set to 127.0.0.1.

Without a relay, the DHCP server can use the source address to return a
reply, dnsmasq will do this for INFORM requests. With the relay, dnsmasq
sees a request with a source address of the relay, which declares that
it "really" came from 127.0.0.1. It's impossible to reply to this,
there's not enough information to address the reply.

If the kpac dhcp helper could be persuaded to set the DHCP ciaddr field
to the clients network address (192.168.2.20 in this case) everything
would work. This is really a bug in kpac, it's clearly violating RFC2131
section 4.4.1 table 5. You should report it to the KDE maintainers.

Without a fix from KDE, I can't see a workaround for this: the best I
can suggest to to use the DNS WPAC method instead.

HTH

Simon.