[systemd-devel] [PATCH] sd-dhcp-client: Sets broadcast flag to 1

[Tom Gundersen]

On Tue, Jun 3, 2014 at 11:37 AM, Tom Gundersen <teg at jklm.no> wrote:
> On Mon, Jun 2, 2014 at 2:09 PM, Patrik Flykt
> <Patrik.Flykt at linux.intel.com> wrote:
>> On Fri, 2014-05-30 at 17:21 +0100, Tom Gundersen wrote:
>>> I'm wondering if the criterion should be to request broadcast if and
>>> only if we have not configured an IP address (I.e. only in
>>> discovering, requesting and init-reboot), as that seems to be the
>>> problem, or did I get that wrong?
>>
>> Yes, I was aiming at requesting broadcast delivery from the server only
>> for broadcast packets sent by the client. That can be an overly simple
>> solution which waits until T2 until the client reacquires the lease by
>> using broadcast; the unicast packets between times T1 and T2 are always
>> lost on these links. Is this something acceptable?
>
> Hm, are you sure packets are lost between T1 and T2? These sholud just
> be regular UDP packets, should they not?
>
>> Then again, if the network is known to operate correctly, it is better
>> to request and get unicast delivery all the time instead. Should we have
>> a configuration parameter that requests broadcast delivery by default
>> and therefore works in all places? The system owner can then turn on
>> unicast delivery once the network is known to work properly?
>
> I'd rather not introduce options to work around bugs, unless there is
> a really compelling reason... I'd either go with enabling broadcast
> unconditionally in the cases where it may be necessary, or find a test
> for deciding whether or not it should be enabled.
>
> I now pushed an attempt at a fix. Does it work as expected for everyone?


Correction, I actually pushed precisely the patch that Camilo posted.
As the server side is responsible for not sending broadcasts except in
the cases I requested in my initial comments, the patch was fine all
along. It would be even better if we could detect when to enable
broadcasting of course...

Cheers,

Tom