BIND 10 #2604: DHCP Testing: V6 Options

[BIND 10 Development]

#2604: DHCP Testing: V6 Options
-------------------------------------+-------------------------------------
            Reporter:  stephen       |                        Owner:
                Type:  task          |  marcin
            Priority:  medium        |                       Status:
           Component:  dhcp          |  reviewing
            Keywords:                |                    Milestone:
           Sensitive:  0             |  Sprint-DHCP-20130214
         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:4 marcin]:
 > First of all, this is going to be a really useful stuff. You used your
 contempt against manual testing in the right way. :-)
 It's good to have it automated, at least a bit. There are 2 people (TomM
 and Rafal - one of the students) are working on automating remove config.
 Hopefully at least one of them delivers usable code ;-)

 > '''info.txt'''
 > Instead of:
 > {{{
 > wget scapy.net
 > mv index.html scapy-latest.zip
 > unzip scapy.zip
 > }}}
 >
 > maybe something like this would be easier
 > {{{
 > wget http://www.secdev.org/projects/scapy/files/scapy-latest.zip
 > unzip scapy-latest
 > }}}
 > BTW, the !''unzip scapy.zip!'' will fail because you renamed that to
 !''scapy-latest.zip!''.
 Updated documentation as suggested.

 > Also scapy has to be installed with the root privileges:
 > {{{
 > sudo python setup.py install
 > }}}
 Done.

 > It should be mentioned that lettuce must be started as root, otherwise
 it will fail.
 Added.

 > It should be mentioned that these are the known issues with scapy:
 Added.

 > '''General to all tests'''
 > There are no tests for options being sent in a REPLY message. In theory
 you could have all tests passing but no option would be sent to the user
 in a REPLY messages if we failed to append them to REPLY messages on the
 Kea side.
 That was much easier than done. Scapy sends defined set of packets and
 then matches incoming packets as responses to sent packets. Scapy 2.2.0
 (the latest) has a but that do not match REPLY properly. After long and
 unpleasant debugging I've fixed that bug. The procedure is now updated
 with extra step that requires scapy patching before installation. We'll
 need to agree on sane way to maintain scapy fixes, but that's a matter for
 a different ticket.

 > Also, there is no test that checks if the server manages to send
 multiple options in a single packet. Can this be done with the current
 code by just adding test scenario which requests multiple options and
 checks them?
 No. option-data[0] was hardcoded. I needed to extend the code a bit to
 increment the
 counter (option-data[1], option-data[2], ...) with every option added and
 then reset it for each test.

 > Such a test would check that server is not limited to just adding a
 single option.
 See new test v6.options.multiple

 > There is no test that checks how the server behaves when the non-
 configured option is requested.
 There is now. See v6.options.negative

 > I am aware of the time constraints so it may be unrealistic to write
 these tests before the Feb 12th deadline. If so it is alright to skip them
 for now. However the tests that check options being added to a REQUEST
 messages should be fairly simple given that the logic is very similar to
 tests that check ADVERTISE and I would suggest to assign them the highest
 priority if time permits to write any additional tests.
 It is now past Feb 12th, so I implemented everything you rightly pointed
 out. Those tests are still not exhaustive, but I suppose this is fair to
 say that we have sufficient coverage to declare v6.options somehow tested.

 > '''Script files'''
 > The dates in the copyright headers are randomly chosen between 2011,
 2012 and 2013. :-)
 They are not random. I used an old, old prototype I wrote long time ago,
 so the 2011 date is somewhat feasible. I knew that the idea is at least
 possible, because I've tested it myself. Otherwise I wouldn't propose
 master thesis topics, based on that idea being possible to implement.
 Anyway, I've updated headers. All modified files mention 2013. Metioning
 2011 is valid, though.

 > '''msg6.py'''
 > client_send_msg: inconsistency between various cases: SOLICIT is in
 upper case, other cases are in lower case. Personally, I prefer upper
 case.
 I hope I caught all instances. Let me know if I missed anything.

 > send_wait_for_message:
 > The comment says that the function fails if the message is not found
 after 10 seconds while the timeout value in the function body is set to 2
 (I presume seconds).
 The timeout is now set to 1. Test execution is faster and the server has
 ample time to respond.

 > '''srv_control.py'''
 > start_srv_isc_dhcp:
 > {{{
 >     world.processes.add_process(step, "dibbler-server", args)
 > }}}
 >
 > !''dibbler-server!'' should be changed to !''isc-dhcp-server!'' I
 belive.
 Ok, removed. That whole method will have to be rewritten anyway as the
 server must be started on a remote machine, not locally.

 I hope that deals with all the issues related to this ticket.

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