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

[Camilo Aguilar]

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

agreed

>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.

My interpretation is that a DHCPNAK is usually sent through unicast unless
the broadcast bit flag is ON in the DHCPDISCOVERY or DHCPREQUEST packet. (Page
25)

I was also cc'ed recently to a new case in Linode:
https://bugs.freedesktop.org/show_bug.cgi?id=81225
If what Linode says in this blog post
<https://blog.linode.com/2003/09/24/network-filtering-improvements/> still
holds true, then it seems Linode is filtering ARP broadcasts.

> 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).

I'm not against understanding why this is failing on a case by case basis.
it will be very useful if Friedrich could send us a dhcp dump
<http://www.cyberciti.biz/faq/linux-unix-dhcpdump-monitor-dhcp-traffic/>.

My suggestions are based on what I've seen implemented in dhcpcd and ISC
dhcp, as well as my personal experience with some networks.

Best,
Camilo



On Sun, Jun 29, 2014 at 2:56 PM, Tom Gundersen <teg at jklm.no> wrote:

> 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
>



-- 
*Camilo Aguilar*
Software Engineer
http://github.com/c4milo
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/systemd-devel/attachments/20140712/f6d2c5c8/attachment.html>