[systemd-devel] systemd-networkd: no network connectivity with 214/master due to 63a070415db09f5b5bcc5c

[Tom Gundersen]

Hi Camilo,

Sorry for taking some time to get back to you.

On Sat, Jun 21, 2014 at 9:08 PM, Camilo Aguilar
<camilo.aguilar at gmail.com> wrote:
> This is another reason why I previously suggested to expose a directive to
> allow administrators to enable/disable the broadcast flag. I have seen DHCP
> servers ignoring the flag and always sending broadcasted DHCPOFFERs. There
> could be other servers that may only use unicast,

Notice that the current client code should be ok with the server
ignoring the broadcast flag, and just accept either broadcast or
unicast packages.

> and even networks that
> might disallow broadcast traffic altogether.

Hm, if I read the DHCP spec correctly it requires the networks to deal
with broadcast packets, as NAK is always sent as broadcast, so if this
is the case we have a bigger problem.

> Set broadcast flag always ON for Firewire interfaces:
> http://tools.ietf.org/html/rfc2855#section-2
> Set broadcast flag always ON for Infiniband interfaces:
> http://tools.ietf.org/html/rfc4390#section-2.2

Once we support these RFC's, I agree that we should enable broadcast
unconditionally for them (some work still needs to be done before we
support DHCP over firewire/infiniband).

> Set broadcast flag OFF by default, if and only if the interface is not
> Infiniband or Firewire
> Expose a configuration directive to allow administrators to configure the
> broadcast flag in case there are DHCP servers ignoring the RFC, or networks
> disallowing broadcast traffic.

I'd be ok with making broadcast opt-in like this if we really have to,
but I'd like to understand the problems seen by Friedrich first (still
haven't gotten around to reproduce it).

Cheers,

Tom