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

[Tom Gundersen]

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?

Cheers,

Tom