[net_server] after r35941 all entries in resolv.conf apears twice

[diver]

I've binary searched this revision (hrev35941) to be the first one when this problem happened.
cat /boot/common/settings/network/resolv.conf

nameserver 10.54.0.6
nameserver 172.28.0.6
domain homenet
nameserver 10.54.0.6
nameserver 172.28.0.6
domain homenet

[vegardw]

The DHCP client writes to resolv.conf both when receiving DCHP_OFFER and DHCP_ACK from the server, that's why everything is listed twice.

The way I read RFC2131 (​http://tools.ietf.org/html/rfc2131#section-3.1) it seems we should only write resolv.conf when receiving DHCP_ACK from the server, not when receiving DHCP_OFFER. It's DHCP_ACK that contains the final configuration from the server.

According to the RFC you can receive DHCP_OFFER from several servers, but the settings doesn't take effects until you have sent a DHCP_REQUEST to your server of choice and received DHCP_ACK from the server.

[stippi]

My first fix to the problem was probably the correct one then. What I don't understand is why the options for DHCP_OFFER are parsed? But I probably have to look at the code again to understand it...

[stippi]

Fixed in hrev35954.

[stippi]

With regards to DHCP_OFFER versus DHCP_ACK... I don't quite understand the code there. First of all _ParseOptions() should only parse the options into the provided BMessage, not write config files. Second the parsing results of DHCP_ACK is ignored completely, except for (re-)writing resolv.conf. There is a TODO in the code. If it's possible for the configuration to change from DHCP_OFFER until DHCP_ACK, we would work with outdated information. Would be nice to have some insights from Axel.

[vegardw]

Just saw the following in the DHCP RFC:

Any configuration parameters in the DHCPACK message SHOULD NOT conflict with those in the earlier DHCPOFFER message to which the client is responding. The client SHOULD use the parameters in the DHCPACK message for configuration.

According to this they should be the same, but the client should use the ones in DHCP_ACK for configuration.

[axeld]

Since you may get more DHCP_OFFERs than one (although this usually hints to a broken environment configuration), you would usually parse those to know if it satisfies your needs.

Once you got such an offer, you request binding from that server, and will then receive the DHCP_ACK which contains your final and complete configuration. So it would indeed make sense to move filling fConfiguration to DHCP_ACK.

The resolv.conf file should actually not be touched by the DHCP code - that's just a hack. Instead, the net_server should handle this when it receives the configuration request.