BIND 10 #3191: Kea4: siaddr field must be configurable

BIND 10 Development do-not-reply at isc.org
Tue Oct 22 13:25:39 UTC 2013


#3191: Kea4: siaddr field must be configurable
-------------------------------------+-------------------------------------
            Reporter:  tomek         |                        Owner:
                Type:  defect        |  marcin
            Priority:  medium        |                       Status:
           Component:  dhcp4         |  reviewing
            Keywords:                |                    Milestone:
           Sensitive:  0             |  Sprint-DHCP-20131016
         Sub-Project:  DHCP          |                   Resolution:
Estimated Difficulty:  0             |                 CVSS Scoring:
         Total Hours:  0             |              Defect Severity:  N/A
                                     |  Feature Depending on Ticket:
                                     |          Add Hours to Ticket:  0
                                     |                    Internal?:  0
-------------------------------------+-------------------------------------
Changes (by tomek):

 * owner:  tomek => marcin


Comment:

 Replying to [comment:6 marcin]:
 > We have earlier noticed that the global values of siaddr were overridden
 by the subnet-specific value of 0.0.0.0. I am a bit surprised actually,
 because I thought that default values are not working properly in bind10
 and even though you have a default, you have to specify non-optional
 parameters. Nevertheless, please double check if it works or not. Also, I
 think that the next-server should not have a default per-subnet value at
 all because if defaults get working, the subnet-specific value will always
 override the global.

 Fixed that. But it is not really testable in unit-tests, at least not
 without major refactor. That is due to the way how we create config file:
 {{{
     string config = "{ some JSON config here }";
     ElementPtr json = Element::fromJSON(config);
 }}}
 This does not take into account the .spec definitions. So eventually we'll
 need a function like fromJSONbutApplySpecFileDefaultsFirst(). Added ticket
 #3205 for this.

-- 
Ticket URL: <http://bind10.isc.org/ticket/3191#comment:7>
BIND 10 Development <http://bind10.isc.org>
BIND 10 Development


More information about the bind10-tickets mailing list