ddns_ttl is not set properly when using DHCPv6
thomas.pegeot at sogeti.com
Fri Apr 2 14:38:47 UTC 2010
I noticed that the ddns_ttl value is not set as expected in both stable and
development versions (from CVS repo).
In both versions, DHCPv4 correctly sets ddns_ttl whereas DHCPv6 doesn't
respect the user's choice and therefore does not set the proper value.
The evaluate_option_cache function is used to set the ddns_ttl value. This
function only works with a lease (struct lease) but not with a lease6
(struct iasubopt) as you can see below:
int evaluate_option_cache PROTO ((struct data_string *,
struct packet *, struct lease *,
struct client_state *,
struct option_state *, struct option_state
struct binding_scope **,
struct option_cache *,
const char *, int));
It actually uses lease -> ends.
In case we are using DHCPv6, the lease structure is NULL here and
evaluate_numeric_expression complains about it: "data: leased_lease: not
available". So, evaluate_option_cache returns 0 and the ttl value is not
If we are using DHCP 4.1.1, DHCP falls back to DEFAULT_DDNS_TTL (3600).
However, ddns_ttl is not set to DEFAULT_DDNS_TTL if we are using the
development version of DHCP: its value is 0.
I have got a few questions about this behaviour.
Why does evaluate_option_cache need to get the dns ttl value from the lease
structure? Why can't it get this value from the DHCP universe without using
a lease structure?
For me, there are a few ways to fix this issue:
- Dirty fix: using a temporary lease in order to store the
hard_lifetime_end_time value extracted from a lease6 structure. In that way,
evaluate_option_cache would return the proper value. Anyway, if you consider
going this way, I can send you a patch as I tried this solution.
- Modifying evaluate_option_cache and evaluate_numeric_expression (and
likely other functions) to make them able to deal with a lease6 structure.
- Getting this value from DHCP universe?
Is that a known bug?
Is anyone here working on this?
More information about the dhcp-workers