[En-Nut-Discussion] SVN r4206 broke DHCP with some DHCP servers

Ole Reinhardt ole.reinhardt at embedded-it.de
Fri Jul 6 11:59:27 CEST 2012


Hi Harald,

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

Bye,

Ole

-- 

Thermotemp GmbH, Embedded-IT

Embedded Hard-/ Software and Open Source Development, 
Integration and Consulting

http://www.embedded-it.de

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