[En-Nut-Discussion] SVN r4206 broke DHCP with some DHCP servers
ole.reinhardt at embedded-it.de
Fri Jul 6 11:59:27 CEST 2012
> > When the DHCP client now sends a DHCP_DISCOVER, the server _should_
> > answer with a broadcast packet, but according to RFC1542, chapter 3.1.1
> > (http://www.ietf.org/rfc/rfc1542.txt) it can also answer with a unicast
> > packet.
> I cannot see this. What I read is, that the reply is a broadcast, if
> the broadcast flag has been set in the request. This can be enabled by
> selecting DHCP_BROADCAST_FLAG in the Configurator.
Yes, I know this flag could be set but will be overlooked by most users.
So I would follow the "DISCUSSION" part in this RFC which encourages to
alow reception of unicast DHCP_OFFERSs even if the local interface is
not yet configured.
> _BUT_, the description of that flag claims: "If enabled, the client
> will set the broadcast flag in all outgoing messages. This is not
> required, because Nut/Net is able to receive UPD datagrams without
> configuring the interface."
> > Is there any real need to discard unicast packets as long as our own
> > interface is not yet configured?
> I don't see any need to discard such packets.
Ok! So I applied my patch to the trunk.
> Just a minor thing: If you
> > - uint_fast8_t bcast;
> > + uint_fast8_t bcast = 0;
> then you don't need to
> > + bcast = 0;
> within the function.
Sure, sorry :) I missed this one...
Thermotemp GmbH, Embedded-IT
Embedded Hard-/ Software and Open Source Development,
Integration and Consulting
Geschäftsstelle Siegen - Steinstraße 67 - D-57072 Siegen -
tel +49 (0)271 5513597, +49 (0)271-73681 - fax +49 (0)271 736 97
Hauptsitz - Hademarscher Weg 7 - 13503 Berlin
Tel +49 (0)30 4315205 - Fax +49 (0)30 43665002
Geschäftsführer: Jörg Friedrichs, Ole Reinhardt
Handelsregister Berlin Charlottenburg HRB 45978 UstID DE 156329280
More information about the En-Nut-Discussion