BIND 10 #3200: DHCPv4 Parameter Request List Option is not handled correctly.

BIND 10 Development do-not-reply at isc.org
Tue Oct 22 11:30:37 UTC 2013


#3200: DHCPv4 Parameter Request List Option is not handled correctly.
-------------------------------------+-------------------------------------
            Reporter:  marcin        |                        Owner:
                Type:  defect        |  marcin
            Priority:  high          |                       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:  High
                                     |  Feature Depending on Ticket:
                                     |          Add Hours to Ticket:  0
                                     |                    Internal?:  0
-------------------------------------+-------------------------------------
Changes (by tomek):

 * owner:  UnAssigned => marcin


Comment:

 '''dhcp4_messages.msg'''
 It may be confusing whether the yiaddr is what client sent or what
 server assigned. To remove this ambiguity, it is better to rephrase
 the message as:

 {{{
 % DHCP4_LEASE_ADVERT_FAIL failed to advertise a lease for client
 client-id %1, hwaddr %2, client sent yiaddr %3
 }}}

 '''dhcp4_test_utils.cc'''
 In !Dhcpv4SrvTest::testDiscoverRequest you may replace

 {{{
     EXPECT_FALSE(rsp->getOption(DHO_LOG_SERVERS));
     EXPECT_FALSE(rsp->getOption(DHO_COOKIE_SERVERS));
     EXPECT_FALSE(rsp->getOption(DHO_LPR_SERVERS));
 }}}

 with noOptionsCheck() call.

 '''dhcp4_srv_unittest.cc'''
 We may add a test that uses actual packet capture with PRL. I vaguely
 remember that I wrote such a test last week, but it is apparently not
 on this branch. So for now, please add a @todo somewhere
 and mention that it should check if packet returned by
 captureRelayedDiscover() would be handled correctly (and options
 requested in PRL be returned). It will be a test very similar to
 Dhcpv4SrvTest.relayAgentInfoEcho. On one branch, there is also additional
 capture added to wireshark.cc, so can use that, too. But definitely
 that's a thing we can do later. A simple @todo will suffice for
 now.

 '''option_definition.cc'''
 With the change in option_definition.cc, I just realized that this
 change will affect how we handle v4 vendor options that uses
 OPT_UINT8_TYPE array option. When tweaking #3194, you'll probably
 need to merge #3200 on it.

 Make sure to mention in changelog that options are no longer sent
 back to the client if server failed to assign a lease. This is a user
 visible change, so we should mention that.

 If you agree with my suggestions and you apply them, you can merge
 the ticket.

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


More information about the bind10-tickets mailing list