FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Debian > Debian User

 
 
LinkBack Thread Tools
 
Old 10-10-2012, 03:56 PM
Panayiotis Karabassis
 
Default dhcpd and always-broadcast

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?

Thanks, and best regards,
Panayiotis


--
To UNSUBSCRIBE, email to debian-user-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 50759A9D.6060306@gmail.com">http://lists.debian.org/50759A9D.6060306@gmail.com
 
Old 10-11-2012, 04:51 AM
Kushal Kumaran
 
Default dhcpd and always-broadcast

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.

--
regards,
kushal


--
To UNSUBSCRIBE, email to debian-user-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: CAH8GtdMYLnCGZCo7tJ5iWXD70945Q0h6W1ZCGwQkRFNEWsq4r w@mail.gmail.com">http://lists.debian.org/CAH8GtdMYLnCGZCo7tJ5iWXD70945Q0h6W1ZCGwQkRFNEWsq4r w@mail.gmail.com
 
Old 10-11-2012, 06:06 PM
Panayiotis Karabassis
 
Default dhcpd and always-broadcast

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.

So, UDP packets can be sent to MAC addresses? I was confused because in
the Wikipedia article, IP addresses where shown in the headers.


--
To UNSUBSCRIBE, email to debian-user-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 50770AA5.50903@gmail.com">http://lists.debian.org/50770AA5.50903@gmail.com
 
Old 10-12-2012, 04:53 AM
Kushal Kumaran
 
Default 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


--
To UNSUBSCRIBE, email to debian-user-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: http://lists.debian.org/CAH8GtdPSmgy8sqAAb9P3MG64XynHGj406YbAQO3=fD8+_kKAH w@mail.gmail.com
 

Thread Tools




All times are GMT. The time now is 07:02 PM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright 2007 - 2008, www.linux-archive.org