BIND 10 #3343: Kea not responding when is configured only with subnet with client classification

[BIND 10 Development]

#3343: Kea not responding when is configured only with subnet with client
classification
-------------------------------------+-------------------------------------
            Reporter:  wlodekwencel  |                        Owner:  tomek
                Type:  defect        |                       Status:
            Priority:  medium        |  closed
           Component:  dhcp          |                    Milestone:  DHCP-
            Keywords:                |  Kea0.9-alpha
           Sensitive:  0             |                   Resolution:  fixed
         Sub-Project:  DHCP          |                 CVSS Scoring:
Estimated Difficulty:  0             |              Defect Severity:  N/A
         Total Hours:  6.5           |  Feature Depending on Ticket:
                                     |          Add Hours to Ticket:  6
                                     |                    Internal?:  0
-------------------------------------+-------------------------------------
Changes (by tomek):

 * hours:  .5 => 6
 * status:  reviewing => closed
 * resolution:   => fixed
 * totalhours:  .5 => 6.5


Comment:

 This bug looks like a side effect of merging 2 tickets. I remember that
 Marcin and I were working the same part of the code (I was writing
 classifyPacket() and Marcin was tweaking call to accept() method, both in
 Dhcpv4Srv::run(). During the merge Marcin's code went before
 classifyPacket(), so the code called accept() first and classifyPacket()
 later. As a result, the code did not work if there were classes defined
 for subnets, because accept() was trying to get a subnet, but the packet
 was not classified yet (did not belong to any subnet).

 It's great that this issue was caught by Forge tests.

 Majority of the time (6h) was needed to set up current Forge code. I have
 previously working setup, but after Forge update it did not work anymore
 (it was Debian 6.0 with Python 2.6, which is too old).

 I spent some time on tweaking Forge to have the ability to wait a long
 time for server response. That is needed when the server is being
 debugged. Without it, the Forge gives up after a second and then kills the
 server. Receiving kill signal unfortunate if you try to debug a process.

 Improvements to Forge have been checked into ip_v4_support branch. Wlodek
 will merge them to master as soon as he deploys v4 Forge tests on Jenkins.

 Thanks for the review. Closing ticket.

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