Bug 426899 - do not return option 24 (domain list) in ADVERTISE messages
do not return option 24 (domain list) in ADVERTISE messages
Status: CLOSED ERRATA
Product: Red Hat Enterprise Linux 5
Classification: Red Hat
Component: dhcpv6 (Show other bugs)
5.1
All Linux
urgent Severity medium
: rc
: ---
Assigned To: David Cantrell
: ZStream
Depends On:
Blocks: 253764 455722
  Show dependency treegraph
 
Reported: 2007-12-28 02:00 EST by Zhiyong Wu
Modified: 2009-01-20 16:38 EST (History)
5 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2009-01-20 16:38:25 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
wireshark-bz426899.ps (16.78 KB, application/postscript)
2008-10-07 20:13 EDT, David Cantrell
no flags Details
server-test1.txt (12.43 KB, text/plain)
2008-10-16 23:28 EDT, David Cantrell
no flags Details
server-test2.txt (12.06 KB, text/plain)
2008-10-16 23:28 EDT, David Cantrell
no flags Details
client-test1.txt (12.50 KB, text/plain)
2008-10-16 23:28 EDT, David Cantrell
no flags Details
client-test2.txt (12.14 KB, text/plain)
2008-10-16 23:29 EDT, David Cantrell
no flags Details
the wireshark result without any new config line (9.42 KB, text/plain)
2008-10-29 23:56 EDT, Yang Ren
no flags Details
RFC3646 test result on dhcpv6-1.0.10-13.el5 (7.32 KB, text/html)
2008-10-30 07:09 EDT, Mitsuru Chinen
no flags Details
RFC3646 test result on dhcpv6-1.0.10-13.el5 without dhcpv6-1.0.10-clear-opt24-for-ADVERTISE.patch (7.23 KB, text/html)
2008-10-30 07:14 EDT, Mitsuru Chinen
no flags Details

  None (edit)
Description Zhiyong Wu 2007-12-28 02:00:39 EST
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
Comment 1 RHEL Product and Program Management 2007-12-30 18:44:44 EST
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.
Comment 2 David Cantrell 2008-01-15 22:56:01 EST
Fixed upstream and will be in dhcpv6-1.0.5.
Comment 7 Denise Dumas 2008-02-27 10:28:59 EST
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. 
Comment 9 David Cantrell 2008-03-12 16:16:44 EDT
Fixed in dhcpv6-1.0.10-2.el5.
Comment 16 Red Hat Bugzilla 2008-07-07 21:24:34 EDT
Adding yshao@redhat.com to the cc list as the manager of the disabled user zwu@redhat.com who reported this bug
Comment 17 David Cantrell 2008-07-15 15:27:25 EDT

*** This bug has been marked as a duplicate of 439526 ***
Comment 18 David Cantrell 2008-07-15 19:28:21 EDT
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.
Comment 25 David Cantrell 2008-09-16 20:03:21 EDT
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.
Comment 31 David Cantrell 2008-10-07 20:13:51 EDT
Created attachment 319710 [details]
wireshark-bz426899.ps
Comment 39 David Cantrell 2008-10-16 23:27:03 EDT
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.
Comment 40 David Cantrell 2008-10-16 23:28:06 EDT
Created attachment 320630 [details]
server-test1.txt
Comment 41 David Cantrell 2008-10-16 23:28:30 EDT
Created attachment 320631 [details]
server-test2.txt
Comment 42 David Cantrell 2008-10-16 23:28:49 EDT
Created attachment 320632 [details]
client-test1.txt
Comment 43 David Cantrell 2008-10-16 23:29:05 EDT
Created attachment 320633 [details]
client-test2.txt
Comment 46 David Cantrell 2008-10-17 20:49:26 EDT
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.
Comment 50 David Cantrell 2008-10-22 04:11:20 EDT
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
Comment 53 David Cantrell 2008-10-23 22:38:16 EDT
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
Comment 56 David Cantrell 2008-10-28 16:59:04 EDT
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.
Comment 58 David Cantrell 2008-10-29 22:17:43 EDT
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;
Comment 59 Yang Ren 2008-10-29 22:31:28 EDT
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;
Comment 60 David Cantrell 2008-10-29 22:53:33 EDT
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.
Comment 61 Lawrence Lim 2008-10-29 23:05:47 EDT
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.
Comment 62 Yang Ren 2008-10-29 23:17:46 EDT
ok I'll collect all info necessary and attach it later.
Comment 63 Yang Ren 2008-10-29 23:53:25 EDT
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.
Comment 64 Yang Ren 2008-10-29 23:56:40 EDT
Created attachment 321896 [details]
the wireshark result without any new config line

the wireshark result without any new config line
Comment 65 Mitsuru Chinen 2008-10-30 07:09:45 EDT
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)
Comment 66 Mitsuru Chinen 2008-10-30 07:14:59 EDT
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.
Comment 67 Mitsuru Chinen 2008-10-30 07:19:27 EDT
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?
Comment 68 Yang Ren 2008-10-30 22:11:18 EDT
(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.
Comment 69 Mitsuru Chinen 2008-10-30 22:48:28 EDT
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;
|       };
| };
Comment 70 Yang Ren 2008-10-30 23:31:48 EDT
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.
Comment 71 Mitsuru Chinen 2008-10-30 23:42:52 EDT
> 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.
Comment 72 David Cantrell 2008-10-30 23:49:55 EDT
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.
Comment 73 Mitsuru Chinen 2008-10-31 00:14:27 EDT
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.
Comment 80 errata-xmlrpc 2009-01-20 16:38:25 EST
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

Note You need to log in before you can comment on or make changes to this bug.