Description of problem: Description of problem: When having dhcpv6 tests in the server mode,we found that The unexpected option is exist. Version-Release number of selected component (if applicable): kernel-2.6.18-53.el5 Software Environment: Testee(NUT): RHEL5 Kernel:2.6.18-53.el5 Tester(TN): FreeBSD6.2 v6eval-3.0.12.tar.gz TAHI package: DHCPv6_Self_Test_P2_1_0_8.tar.gz How reproducible: every time Steps to Reproduce: 1. Configure TAHI test environment. 2. Run the TAHI test suite 3. After the test completes, check for the results Actual results: The unexpected option is exist Expected results: The unexpected option should not exist failed. Additional info: please refer to http://focus.brisbane.redhat.com/~zwu/RHEL5.1-Server-20071017.0/20071225/DHCPv6_Self_Test_P2_1_0_8_server/rfc3646/index.html (1) 4 Part A :Returning of DNS Recursive Name Server option http://focus.brisbane.redhat.com/~zwu/RHEL5.1-Server-20071017.0/20071225/DHCPv6_Self_Test_P2_1_0_8_server/rfc3736/index.html (2) 19 Part A :Returning of DNS Recursive Name Server option
This request was evaluated by Red Hat Product Management for inclusion in a Red Hat Enterprise Linux maintenance release. Product Management has requested further review of this request by Red Hat Engineering, for potential inclusion in a Red Hat Enterprise Linux Update release for currently deployed products. This request is not yet committed for inclusion in an Update release.
Fixed upstream and will be in dhcpv6-1.0.5.
but the test cases FAIL on RHEL5.2 with dhcpv6-1.0.10 for more details, pls refer to http://focus.brisbane.redhat.com/~zwu/RHEL5.2-Server-20080212.0/20080220/DHCPv6_Self_Test_P2_1_0_8_client_1.0.10/rfc3646/index.html http://focus.brisbane.redhat.com/~zwu/RHEL5.2-Server-20080212.0/20080220/DHCPv6_Self_Test_P2_1_0_8_client_1.0.10/rfc3736/index.html
sorry ,it should be http://focus.brisbane.redhat.com/~zwu/RHEL5.2-Server-20080212.0/20080220/DHCPv6_Self_Test_P2_1_0_8_server_1.0.10/rfc3646/index.html http://focus.brisbane.redhat.com/~zwu/RHEL5.2-Server-20080212.0/20080220/DHCPv6_Self_Test_P2_1_0_8_server_1.0.10/rfc3736/index.html
In order to debug this problem, we need the test case for RHEL 5.2 with an exact reproducer, including output with verbose debugging messages from the DHCPV6 software. One way to do this would be to extract the commands that TAHI runs. The man pages for dhcp6s, dhcp6r, and dhcp6c all show how to generate verbose debug messages.
Fixed in dhcpv6-1.0.10-2.el5.
Adding yshao to the cc list as the manager of the disabled user zwu who reported this bug
*** This bug has been marked as a duplicate of 439526 ***
This should be cleared up with the option code reworking done for bug #439526, so I'm marking it as MODIFIED. Fix is available in dhcpv6-1.0.10-6.el5 and later builds.
I believe I've fixed this now (at least my local testing is showing that). dhcp6s will only return the DNS server list or DNS domain list if they are requested by the client. The logic in the program is a little backwards, so I'll probably come up with a better fix upstream, but for now I think this will work. The fix will be in dhcpv6-1.0.10-8.el5.
Created attachment 319710 [details] wireshark-bz426899.ps
I have worked on this bug a lot this afternoon and found a SIGSEGV that was occurring when I was testing it. This may have caused the failure in TAHI, but I'm not sure. I fixed the SIGSEGV and ran two tests with the new dhcpv6. Both tests used a common dhcp6s.conf file on the server. I used the same one posted in comments in this bug, but here it is again: interface eth1 { server-preference 255; renew-time 5000; rebind-time 8000; prefer-life-time 10000; valid-life-time 10000; option dns_servers 3ffe:501:ffff:100:210:18ff:fe32:56e2 redhat.com; link AAA { pool { range 3ffe:501:ffff:101::10 to 3ffe:501:ffff:101::11/64; prefix 3ffe:501:ffff:101::/48; }; }; host TN { duid 00:01:00:01:00:04:93:e0:00:00:00:00:a2:a2; }; }; ------------------------------------------------ FIRST TEST - Client requesting options 23 and 24 ------------------------------------------------ 1) Start dhcp6s on the server: dhcp6s -d -D -f eth1 2) Write /etc/dhcp6c.conf file on the client: interface eth0 { request domain-name-servers; request domain-search-list; }; 3) Start dhcp6c on the client: dhcp6c -d -D -f eth0 Packet captures were collected on the server and client. The packet capture reports are attached to this bug as: server-test1.txt client-test1.txt You can see that the Advertise message received on the client contains both option 23 and 24. ---------------------------------------------- SECOND TEST - Client requesting only option 23 ---------------------------------------------- 1) Start dhcp6s on the server: dhcp6s -d -D -f eth1 2) Write /etc/dhcp6c.conf file on the client: interface eth0 { request domain-name-servers; }; 3) Start dhcp6c on the client: dhcp6c -d -D -f eth0 Packet captures were collected on the server and client. The packet capture reports are attached to this bug as: server-test2.txt client-test2.txt You can see that the Advertise message received on the client contains only option 23 and not an empty option 24 or an option 24 with data. I have built a new dhcpv6 package as dhcpv6-1.0.10-12.el5 which contains the fix for the SIGSEGV that I found. It was crashing if the client was run in the foreground (-f), so that may have definitely attributed to the problems in TAHI. But again, I do not know for sure.
Created attachment 320630 [details] server-test1.txt
Created attachment 320631 [details] server-test2.txt
Created attachment 320632 [details] client-test1.txt
Created attachment 320633 [details] client-test2.txt
OK, I think I have it now. For all ADVERTISE messages sent from the server to the client, it does not send option 24. Even if the client requests it, the ADVERTISE message will not contain it. If the server requests option 24, it will get it in the REPLY message, but not in the ADVERTISE message. Rebuilding as dhcpv6-1.0.10-13.el5.
I've updated the patch. For dhcp6s.conf, you can now add this line: send advertise-dns-list-only; And the server will only include option 23 in ADVERTISE messages. If that option is not present, all options are included. I hope this is sufficient for the purposes of the TAHI software. The new build is dhcpv6-1.0.10-14.el5
Should be working now. I messed up the bitwise operations. My mistake. I also added a similar configuration file setting for REPLY messages. The man page has been updated too. The new settings are: send advertise-dns-list-only; send reply-dns-list-only; If you set advertise-dns-list-only, then ADVERTISE messages will only contain option 23 regardless of what options the client requested. If you leave this setting out of the configuration file, all options in the request list are included in the ADVERTISE message. If you set reply-dns-list-only, then REPLY messages will only contain option 23 regardless of what options the client requested. If you leave this setting out of the configuration file, all options in the request list are included in the REPLY message. New build is dhcpv6-1.0.10-15.el5
You have the configuration file lines wrong. The settings are: send advertise-dns-list-only; send reply-dns-list-only; Use advertise-dns-list-only when you want dhcp6s to only send option 23 in the ADVERTISE message option list. Use reply-dns-list-only when you want dhcp6s to only send option 23 in the REPLY message option list. I would not use both settings at the same time.
The client configuration file is requesting both option 23 and 24, correct? You should have this line: request domain-name-servers; for option 23. And this line: request domain-search-list; for option 24;
tahi test suit send the solicit msg with option request 23 ,24 both. In server test mode tahi do the client behavior. (In reply to comment #58) > The client configuration file is requesting both option 23 and 24, correct? > > You should have this line: > request domain-name-servers; > for option 23. > > And this line: > request domain-search-list; > for option 24;
Have you tested it with wireshark? I am running it here between two systems using wireshark to monitor network traffic. When I set: send advertise-dns-list-only; And have the client request both options, the ADVERTISE message from the server contains only option 23. The REPLY message that comes later from the server contains both options 23 and 24.
llim->ryang: each test should come with their own tcpdump. You could attach the tcpdump for the test here for David to analyse as well. This will allow David to know exactly what happened during the event.
ok I'll collect all info necessary and attach it later.
I add a attachment which is generated by wireshark In client it request option 23 and 24 both. In server I use config file without any new config line. It should return both option 23 and 24. but you can see it with only option 23.
Created attachment 321896 [details] the wireshark result without any new config line the wireshark result without any new config line
Created attachment 321915 [details] RFC3646 test result on dhcpv6-1.0.10-13.el5 Hi all, I'm afraid this discussion goes wrong direction. Advertise message can includes option 24. As the dhcpv6-1.0.10-clear-opt24-for-ADVERTISE.patch prohibit to do so, the following tests in DHCPv6 conformance test get fail. #3 Domain Search List Option Format #5 Part B :Returning of DNS Recursive Name Server option and Domain Search List Option #7 Part B : Advertise message in response to Solicit message with ORO (Domain Search List Option)
Created attachment 321916 [details] RFC3646 test result on dhcpv6-1.0.10-13.el5 without dhcpv6-1.0.10-clear-opt24-for-ADVERTISE.patch Without dhcpv6-1.0.10-clear-opt24-for-ADVERTISE.patch, I get pass on all test.
I cannot look into the results on focus.brisbane.redhat.com. Could you upload DHCPv6_Self_Test_P2_1_0_13/rfc3646/4.html and 19.html here?
(In reply to comment #65) > Created an attachment (id=321915) [details] > RFC3646 test result on dhcpv6-1.0.10-13.el5 > > Hi all, > I'm afraid this discussion goes wrong direction. Advertise message can includes > option 24. > As the dhcpv6-1.0.10-clear-opt24-for-ADVERTISE.patch prohibit to do so, > the following tests in DHCPv6 conformance test get fail. > > #3 Domain Search List Option Format > #5 Part B :Returning of DNS Recursive Name Server option and Domain Search > List Option > #7 Part B : Advertise message in response to Solicit message with ORO (Domain > Search List Option) I have the same problem. This patch do cause regression. Do not contain option 24 makes many test failed. But you should know a advertise can includes option 24 and it also can not includes option 24. for test case rfc3646 Part A :Returning of DNS Recursive Name Server option. Part B :Returning of DNS Recursive Name Server option and Domain Search List Option This two test case gave us same situation(a solicit message with request option 23 24). But the two test case require two different result part A only need advertise message with option 23 and part B need advertise message with both option 23 and option 24. So I think that we can add a config line in confug file and change the configure make the test pass. I do think a server will do two difference behavior with one configure file. So I'm curious about how you can make them pass with one same configure file :) Pls help me if you have some hacks. I'm afraid focus.bne.redhat.com is internal I will upload the page you want here later.
Part A test validates option 24 should not be in Advertise when the configuration of DHCPv6 server isn't enable the domain name list. Part B test validates option 24 should be in Advertise when the configuration of DHCPv6 server is enable the domain name list. So the configure file should be different for each test. In fact, the part A test calls dhcp6s.rmt with: > /usr/local/v6eval//bin/linux//dhcp6s.rmt -t linux -u root -p v6eval \ > -d ttyS0 -o 1 start \ > dns='3ffe:501:ffff:100:200:ff:fe00:3f3e' \ > link0=eth0startaddr=3ffe:501:ffff:100::10 endaddr=3ffe:501:ffff:100::11'' There is no domainlist parameter. So the configuration file would be: | # cat /root/dhcp6s.conf | prefer-life-time 10000; | valid-life-time 20000; | renew-time 5000; | rebind-time 16000; | option dns_servers 3ffe:501:ffff:100:200:ff:fe00:3f3e; | interface eth0 { | link AAA { | range 3ffe:501:ffff:100::10 to 3ffe:501:ffff:100::11/64; | }; | }; The part B test calls dhcp6s.rmt with: > /usr/local/v6eval//bin/linux//dhcp6s.rmt -t linux -u root -p v6eval \ > -d ttyS0 -o 1 start \ > dns='3ffe:501:ffff:100:200:ff:fe00:3f3e' > domainlist= 'test.example.com' > link0=eth0 startaddr=3ffe:501:ffff:100::10 endaddr=3ffe:501:ffff:100::11'' This time, there is a domainlist parameter. So the configuration file would be: | # cat /root/dhcp6s.conf | prefer-life-time 10000; | valid-life-time 20000; | renew-time 5000; | rebind-time 16000; | option dns_servers 3ffe:501:ffff:100:200:ff:fe00:3f3e test.example.com; | interface eth0 { | link AAA { | range 3ffe:501:ffff:100::10 to 3ffe:501:ffff:100::11/64; | }; | };
I got it. It's our fault we miss the domainlist parameter and using a static line in configure file. It's stupid that I want to add another line to fix this static line. Now I know how to make it work. To Mitsuru: Thank you very much indeed. Our remote control pkg are not wrote by me. It's wrote by a practised colleague who has leave red hat. So I always think it's right. You point me to the right place. Thank you. Btw you said you have all pass the dhcpv6, but I still have 10 failed in rfc3315 about relay. Do you have same problem? If not it should also be a remote control problem? To David: Sorry for my mistake, It delays this fix. I should discuss this problem more detail and careful with you. I think you also can point out if I do not add the domain in that line that will make the advertise message without option 24. I suggest roll back to pkg version 11. To llim: Don't need call any more. I'll change our remote control pkg and run tahi make them all pass. Then I'll move it to modify. It'll take about one or two work days.
> Btw you said you have all pass the dhcpv6, but I still have 10 failed in > rfc3315 about relay. Do you have same problem? If not it should also be a > remote control problem? No, I don't have same problem. But I cannot judge the cause without the results. I think you get remote files which I sent via e-mail. If you still get fails with them, feel free to contact me.
Yang, Great work! Thanks for the update! Since we had a lot of builds since release 11, I'm going to revert the whole patch for this bug and do a new build called dhcpv6-1.0.10-16.el5 and I'll update the errata file list with that. I'm moving the bug to MODIFIED based on that. Mitsuru, Thank you for your help on this issue. I really appreciate it. ----- Related issue: Mitsuru originally pointed out the DUID LLT time match patch that I did for bug #365501. He said that patch causes regressions as well. I think we should look at that bug again and see if it passes or fails with the updated TAHI scripts. For the dhcpv6-1.0.10-16.el5 build, I'm only reverting the patch for this bug. If we need to revert the DUID LLT issue, we can do that next week.
Hi David, Regarding DUID LLT issue, the DUID LLT consistency test will pass whether dhcpv6-1.0.10-duid_match_llt.patch is applied or not. The test validates the consistency of the time field. That patch sets the same time value which is in the client ID. The time field of the client ID in the message from the test is always 300000. Then, dhcp6s replies the message with 300000 value in the time field. As the value in time field is always 300000, test judges the time field is consistent. But our dhcp6s keeps the time field basically. Therefore such a tricky hack is not necessary. I anticipate the remote script removed files in /var/lib/dhcpv6/ at rebooting. If so, the result would be failure.
An advisory has been issued which should help the problem described in this bug report. This report is therefore being closed with a resolution of ERRATA. For more information on therefore solution and/or where to find the updated files, please follow the link below. You may reopen this bug report if the solution does not work for you. http://rhn.redhat.com/errata/RHBA-2009-0165.html