[Dibbler] Dibbler 0.8.3 tests with CDRouter

Rapoport, MichaelX michaelx.rapoport at intel.com
Wed Feb 20 09:16:57 CET 2013

Hello Tomek.

Thank you very much for the help.
I've mismatched one test - sending 50 instead of 52.

Please see it attached.

I'll consult my superior on the further steps and inform you.


-----Original Message-----
From: dibbler-bounces at klub.com.pl [mailto:dibbler-bounces at klub.com.pl] On Behalf Of Tomasz Mrugalski
Sent: Tuesday, February 19, 2013 23:31
To: dibbler at klub.com.pl
Subject: Re: [Dibbler] Dibbler 0.8.3 tests with CDRouter

On 18.02.2013 09:28, Rapoport, MichaelX wrote:
> Hello Tomek.
> Sorry for my previous mail with the CDRouter tests,- it was a mistake - wrong tests were attached.
> Attached are the failed DHCP v6 Server tests performed on the CDRouter.
> I'd like to receive your opinion.
Support for UseMulticast is not implemented. See bug #83.

User class is not supported. Please file a bug.
Fragmentation is not supported. Please file a bug.

Support for UseMulticast is not implemented. See bug #83.

Server does not implement this particular text from RFC3315. Please file a bug.

See bug #240 and decide if you want to update this bug or create a new one.

Support for UseMulticast is not implemented. See Bug #83.

This is somewhat questionable. If the client tries to renew an address that is not valid, server assigns a valid address and sends it back.
This was my interpretation of the following text (Section 18.2.3, RFC3315):

   If the server finds the addresses in the IA for the client then the
   server sends back the IA to the client with new lifetimes and T1/T2
   times.  The server may choose to change the list of addresses and the
   lifetimes of addresses in IAs that are returned to the client.

This is a convenient behavior, because it is faster. The alternative is to send REPLY with lifetimes set to 0, then client will restart SOLICIT phase and will eventually get an address. However, I agree that this behaviour is not compliant, because the first part of the sentence ("server finds the address...") is not fulfilled. Please file a bug.

Server behaves correctly. That is confirmed by the following log entry:
PASS(cdr-mp-1349): 16:05:21.039| Test dhcpv6_server_50 (1349) passed

Support for UseMulticast is not implemented. See Bug #83.

Server does not include status code. Please file a bug.

Support for UseMulticast is not implemented. See Bug #83.

Server shouldn't include preference option. Please file a bug.

This is test error. Your server is not configured to support PD, so it assigns only IA_NA (address), but IA_PD contains NoPrefixAvail status code. This seem to confuse the test. The test sends Solicit couple times and later gives up and declares a failure. This is not a bug, but server misconfiguration. Please configure Dibbler server to also serve PD and this will likely improve the situation.

This is a configuration error. Did you configure Dibbler server to support relays? It doesn't appear to be configured to do so, so it doesn't listen on ff05::1:3. See Dibbler User's Guide, section 4.2.

This is a configuration error. See DHCP-120. Also, did you configure Dibbler to use unicast address? See Dibbler User's Guide, section 4.2 and 5.3.4.

This is a configuration error. See DHCP-120.

It seems there are number of bugs discovered, but most of them are not serious. Personally I think the issues in DHCP-32 and DHCP-43 are the most serious. Lack of support for UseMulticast affects biggest number of tests, but it is harmless in most cases - client gets responses, service is provided and even traffic is more optimal (unicast rather than multicast). The only benefit of using multicast is that if you run other DHCP servers they could receive that traffic as well. I doubt you are running multiple DHCP servers with some kind of very clever semi-failover capability between them. If you do, I'd be very interested to learn the details. Issues in DHCP-80 and DHCP-82 are trivial. Dibbler server seems to send additional options that are not necessary.

It seems that there are up to 7 separate bugs. Once you fill in those bugs, we can discuss the best way forward to deal with the situation.
Are you interested in those issues being fixed?

I plan to work on issue that affects DHCP-32 as it requires the most extensive changes to the code (information about subnets must be specified in config file, which requires parser changes and code update in several places).

I know Intel has many skilled engineers that could fix those issues easily, so I hope you'll be actively participating in the bug fixing.
Please let me know if you decide to work on specific problem and I'll try to provide you with some tips. Don't be scared - some of the issues require 1 line fixes. Your patches will be more than welcome :-)

If your goal is to increase pass rate as soon as possible, you should probably work on UseMulticast problem as it affects the biggest number of tests. If your goal is to address the most serious bugs first, I suggest you start looking into problem in DHCP-43.

Good tests in general.

Intel Israel (74) Limited

This e-mail and any attachments may contain confidential material for
the sole use of the intended recipient(s). Any review or distribution
by others is strictly prohibited. If you are not the intended
recipient, please contact the sender and delete all copies.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: DHCP-52.zip
Type: application/x-zip-compressed
Size: 5446 bytes
Desc: DHCP-52.zip
URL: <http://klub.com.pl/pipermail/dibbler/attachments/20130220/17a56a13/attachment.bin>

More information about the Dibbler mailing list