Re: [OT] dhcpd and always-broadcast
On Thu, Oct 11, 2012 at 11:36 PM, Panayiotis Karabassis
<panayk@gmail.com> wrote:
> On 10/11/2012 07:51 AM, Kushal Kumaran wrote:
>> On Wed, Oct 10, 2012 at 9:26 PM, Panayiotis Karabassis <panayk@gmail.com> wrote:
>>> Hey,
>>>
>>> I have an OT question about the always-broadcast option of the dhcpd server.
>>>
>>> Based on the Wikipedia article, all DHCP messages to the client are sent
>>> to the broadcast address. This makes sense, since the UDP protocol used
>>> by DHCP runs on top of the IP protocol, and the client does not have an
>>> IP address until the DHCP negotiation is completed.
>>>
>>> So, what is the use of this option? Under what circumstances should the
>>> server not broadcast its messages?
>>>
>>
>> In a DHCP request, a client can choose to say that it does not need
>> responses to be broadcast. There is a "broadcast bit" in the DHCP
>> request that the client can turn off. The always-broadcast option for
>> the DHCP server says that the server should ignore the unset broadcast
>> bit and always broadcast the response.
>>
>> How does the client receive a unicast response, you ask? The response
>> will still have the client's hardware address (MAC address). So the
>> response will reach the client's interface.
>>
>> It seems, though, that this functionality is not often used. Clients
>> always seem to set the broadcast bit, even if they will be able to
>> receive a unicast response. I had a problem recently, where some
>> random malfunctioning device on a network was seeing random DHCP
>> responses intended for someone else and assigning the offered address
>> to itself. I had to patch dhcpd to ignore the broadcast bit and
>> always send a unicast response (a "never-broadcast" option). It
>> worked surprisingly well.
>>
>
> Thanks! I had the reverse problem. My android device (apparently
> android's dhcp client is buggy) would not receive the dhcp assignments
> even though the server would send them.
>
> Had the malfunctioning device requested an address in the first place? I
> think in any case it should not happen, because -I think- the DHCP
> packets include a 'transaction' field, by means of which a client can
> distinguish whether the packet is intended for it or not.
>
It may have requested an address. Truth be told, I did not
investigate the matter further after I hacked my way around it.
> So, UDP packets can be sent to MAC addresses? I was confused because in
> the Wikipedia article, IP addresses where shown in the headers.
Remember, the client does not actually have any IP address assigned to
its interface. So, it will not care at all what shows up in the UDP
header's destination field. The MAC address is used by the
intermediate switches to guide the packet. The clients network
interface will of course pick up the ethernet frame because it has its
MAC address on it. Meanwhile the DHCP client is waiting for packets
to show up on UDP port 68, and it does not particularly care what the
destination IP address is set in the UDP header.
--
regards,
kushal
Reply to: