RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Bug 592163 - dhclient did not send DNS query message.
Summary: dhclient did not send DNS query message.
Keywords:
Status: CLOSED WONTFIX
Alias: None
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: dhcp
Version: 6.1
Hardware: All
OS: Linux
medium
medium
Target Milestone: rc
: ---
Assignee: Jiri Popelka
QA Contact: Release Test Team
URL:
Whiteboard:
Depends On: 574717
Blocks: 572236
TreeView+ depends on / blocked
 
Reported: 2010-05-14 03:28 UTC by Yang Ren
Modified: 2010-11-10 12:14 UTC (History)
7 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of: 574717
Environment:
Last Closed: 2010-11-10 12:14:54 UTC
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)
dump file from NO.24 of RFC3646 section (4.17 KB, application/octet-stream)
2010-09-07 07:12 UTC, ShanWei
no flags Details

Description Yang Ren 2010-05-14 03:28:17 UTC
Clone this bug to rhel6 to record status.
+++ This bug was initially created as a clone of Bug #574717 +++

Description of problem:
I configure a client with this configure.
############################
interface "eth0" {
request dhcp6.name-servers;
};
############################
In the first four msg exchange they all works well.(solicit advertise request reply)
And DNS = 3ffe:501:ffff:100:200:ff:fe00:3f3e

do this from client
ping6 -n -c 1 -i 1 -s 2 -M want -p 00 -w 2 -I eth0 dhcpv6.test.example.com

Then can find client sent dns query to that dns server
Receive DNS SQUERY: NUT --> DNS Server

Then ifdown and ifup interface.
Can not got confirm message.(unless server send a RA to all)
do ping again on clinet 
ping6 -n -c 1 -i 1 -s 2 -M want -p 00 -w 2 -I eth0 dhcpv6.test.example.com

Cannot get DNS Query message!

I'm not sure what it is. And this situation is also occur when request domain-search

interface "eth0" {
request dhcp6.domain-search;
};

This time client did not send DNS query message after four message exchange.


THis is the result page.
http://10.66.70.72/DHCPv6_Self_Test_P2_1_1_0_client/rfc3646/
U can have a reference to test 
Test DHCP_CONF.4.1.4 : Transmission of Confirm Messages for DNS Configuration options
8.
9.
10.
11.

--- Additional comment from jpopelka on 2010-03-18 08:15:55 EDT ---

Hi,

dhcp6.name-servers and dhcp6.domain-search options are requested by default.

If you enter a ’request’ statement, you override this default requested option list.

So in case of
############################
interface "eth0" {
request dhcp6.name-servers;
};
############################
you are requesting ONLY dhcp6.name-servers (not dhcp6.domain-search).

If you want to request additional option(s) use:
also request dhcp6.additional_option_name;

See
/usr/share/doc/dhclient-4.1.1/dhclient6.conf.sample
and
'The request statement' section in 'man dhclient.conf'.

Note:
I should probably add a note to 'man dhclient.conf',
saying that dhcp6.name-servers and dhcp6.domain-search options are requested by default.

--- Additional comment from ryang on 2010-03-18 22:57:00 EDT ---

Hi J,

    Let me explain more detail. They are two test cases. 
1. only request (DNS Recursive Name Server option) 
2. only request (Domain Search List option)

The test purpose is 
1. Part C : Option Request Option status after confirm message without any reply ( DNS Recursive Name Server option )
2. Part D : Option Request Option status after confirm message without any reply (Domain Search List option)


When client told the dns server or domain search list by the server. It use a ping command to test if they works. then it will try to ifdown and ifup the interface. then test it again to know if the options still works.

For the first test. 
When ping dhcpv6.test.example.com it will send a DNS query to DNS server. This DNS server is given by dhcp server in the first 4 message exchange.
But after ifdown and ifup the interface.
It try to ping the dhcpv6.test.example.com again. But never got DNS query.
Can not capture NS from NUT to DNS Name Server option

For the second test.
test totally can not capture NS from NUT to DNS Name Server.

They are two test with difference purpose. So I only request option 23 in test one and option 24 in test two.

--- Additional comment from jpopelka on 2010-04-23 11:14:39 EDT ---

(In reply to comment #0)
> Then ifdown and ifup interface.
> Can not got confirm message.(unless server send a RA to all)

This looks like the same problem as in bug #574677.
Can you re-test this problem after you will have the patched tahi test suite ?
Thanks

Otherwise, I tried to play with sending/receiving dhcp6.domain-search/dhcp6.name-servers options. I also tried to restart the interface and everything looks correct to me. But I don't have much experience with DNS.

Comment 1 RHEL Program Management 2010-05-14 03:49:39 UTC
This request was evaluated by Red Hat Product Management for inclusion in a Red
Hat Enterprise Linux major release.  Product Management has requested further
review of this request by Red Hat Engineering, for potential inclusion in a Red
Hat Enterprise Linux Major release.  This request is not yet committed for
inclusion.

Comment 3 Jiri Popelka 2010-05-19 17:12:30 UTC
(In reply to bug #574717, comment #4)
> still failed. I find also other people can not pass this test. I'll have a look
> at this fail, Will update it here later.

Looking at the latest (2010/05/14 14:05:22) log from
Part C : Option Request Option status after confirm message without any reply (DNS Recursive Name Server option)
I see there is (but shouldn't be) domain search path nay.redhat.com.
applied to the DNS query in the last received packet
| | | | DNS_Question                    (length:44)
| | | | | DNS_QuestionEntry               (length:44)
| | | | | | Name                             = dhcpv6.test.example.com.nay.redhat.com.

http://focus.bne.redhat.com/~ryang/ipv6ready/DHCPv6_Self_Test_P2_1_1_0_client_latest/rfc3646/10.html#vRecvPKT44

Maybe there somehow appeared
"search nay.redhat.com."
line in /etc/resolv.conf after ifdown;ifup

But client is not requesting Domain Search List option in the 'Part C' test so I don't know how it could get there.
Do you have any idea ?

Comment 4 Yang Ren 2010-05-20 00:14:19 UTC
I configure host name in NUT. XXXX.nay.redhat.com
So I remove this hostname configure on NUT.

For No.10 test it passed.
[root@IPv6testee ~]# cat /etc/resolv.conf 
; generated by /sbin/dhclient-script
nameserver 3ffe:501:ffff:100:200:ff:fe00:3f3e

For No.11 test it still fail.
[root@IPv6testee ~]# cat /etc/resolv.conf 
; generated by /sbin/dhclient-script
search test.example.com.

Client did not send DNS query message.

For No.24 test is also fail.
[root@IPv6testee ~]# cat /etc/resolv.conf 
; generated by /sbin/dhclient-script
nameserver 3ffe:501:ffff:100:200:ff:fe00:3f3e

After got rebind message client did not send DNS query.


So after I remove domain configure in NUT We pass No.10 test. Still two left.

Comment 5 Jiri Popelka 2010-05-20 09:34:49 UTC
(In reply to comment #4)
> Still two left.    
Hi,

problem with Part D is that the client doesn't have address of any nameserver where he can send the DNS query.

From http://www.ipv6ready.org/docs/Phase2_DHCPv6_Conformance_Latest.pdf

Test DHCP_CONF.4.1.4: Transmission of Confirm messages for DNS Configuration options
Part D: Option Request Option status after confirm message without any reply (DNS Recursive Name
Server option)
    22. Enable DHCPv6 which is configured to require a DNS Recursive Name Server option and a
        Domain Search List option in parallel with Address Assignment on the NUT.
    23. Upon the reception of a Solicit message from the NUT, TN1 transmits a properly formatted
        Advertise message.
    24. Upon the reception of a Request message from the NUT, TN1 transmits a properly formatted
        Reply message including a DNS Recursive Name Server option that includes TN3 (DNS
        Server)’s global IPv6 address and a Domain Search List option that includes “test.example.com”.
    25. Configure NUT transmit an Echo request to “dhcpv6”.
    26. Observe the messages transmitted on Link A.
    27. Physically disconnect the NUT interface on Link A. (This can also be achieved by disabling and
        re-enabling the network interface)
    28. After enough time elapses in which the NUT recognizes a link down situation (5 seconds),
        physically disconnect the TN1 interface on Link A, reconnect the NUT to Link A.
    29. Configure NUT transmit an Echo request to “dhcpv6”.
    30. Observe the messages transmitted on Link A.

So I hope you can pass the 'Part D' test when you configure the server to send both options (dhcp6.name-servers and dhcp6.domain-search). And also configure the client to request them both (or you can just delete the dhclient.conf, because they are both requested by default).

Comment 6 Jiri Popelka 2010-05-20 11:44:14 UTC
Let's finish it ... 'Part E':

What's 'Part E' all about ?
'Part E' is actually the same as 'Part C' with two differences:
1) When we ifdown the interface, we wait for longer that T2 (set to 80s) and then we ifup the interface.
This makes the client send Confirm (as in 'Part C') and then send Rebind (because T2 was reached).
2) There are two DNS servers.
TN3=3ffe:501:ffff:100:200:ff:fe00:3f3e (as in 'Part C') and TN4=3ffe:501:ffff:100:200:ff:fe00:3e3f.
After the server gets Rebind message from client, it sends nameserver TN4 in Reply as a new DNS server.
Client then sends the DNS query to TN4 (instead of TN3, where he sent the query before restart of interface).

What shows the log ?
There's one moment where the server sends Reply (with TN4) in response to clients Rebind, but after that the client still keeps sending Rebind like he didn't catch the Reply.

It also seems strange to me that in the log (and in packet capture) there are more occurrence of each type of message. In the packet capture
http://focus.bne.redhat.com/~ryang/ipv6ready/DHCPv6_Self_Test_P2_1_1_0_client_latest/rfc3646/24_html_Link0.pcap
after the ifup of interface I see 4x Confirm but no Reply for it.
Then I see 5x Renew (there shouldn't be any Renew).
Then there's (as I mentioned above) Rebind followed by Reply (with TN4), which looks good.
But then again 5x Rebind (did the client not catch the Reply ?).
That all makes difficult to me say where the problem is.

I did the 'Part E' test here and everything looks good.
After the restart client sent Confirm, then Rebind,
server sent Reply with new (other then the previous) nameserver
and client then sent the DNS query to the new nameserver when trying to
resolve some name. So I believe it's only configuration or tahi test suite problem.

Comment 7 Yang Ren 2010-06-09 07:41:33 UTC
(In reply to comment #6)
> Let's finish it ... 'Part E':
> 
> What's 'Part E' all about ?
> 'Part E' is actually the same as 'Part C' with two differences:
> 1) When we ifdown the interface, we wait for longer that T2 (set to 80s) and
> then we ifup the interface.
> This makes the client send Confirm (as in 'Part C') and then send Rebind
> (because T2 was reached).
> 2) There are two DNS servers.
> TN3=3ffe:501:ffff:100:200:ff:fe00:3f3e (as in 'Part C') and
> TN4=3ffe:501:ffff:100:200:ff:fe00:3e3f.
> After the server gets Rebind message from client, it sends nameserver TN4 in
> Reply as a new DNS server.
> Client then sends the DNS query to TN4 (instead of TN3, where he sent the query
> before restart of interface).
> 
> What shows the log ?
> There's one moment where the server sends Reply (with TN4) in response to
> clients Rebind, but after that the client still keeps sending Rebind like he
> didn't catch the Reply.
> 
> It also seems strange to me that in the log (and in packet capture) there are
> more occurrence of each type of message. In the packet capture
> http://focus.bne.redhat.com/~ryang/ipv6ready/DHCPv6_Self_Test_P2_1_1_0_client_latest/rfc3646/24_html_Link0.pcap
> after the ifup of interface I see 4x Confirm but no Reply for it.
> Then I see 5x Renew (there shouldn't be any Renew).
> Then there's (as I mentioned above) Rebind followed by Reply (with TN4), which
> looks good.
> But then again 5x Rebind (did the client not catch the Reply ?).
> That all makes difficult to me say where the problem is.
> 
> I did the 'Part E' test here and everything looks good.
> After the restart client sent Confirm, then Rebind,
> server sent Reply with new (other then the previous) nameserver
> and client then sent the DNS query to the new nameserver when trying to
> resolve some name. So I believe it's only configuration or tahi test suite
> problem.    

I think so too. After restart interface tahi wait for 'ns_nut_dhcp_to_dns_2'
FEM_icmp6_ns(
        ns_nut_dhcp_to_dns_2,
        _HETHER_nut_to_dns_server,
        {
                HopLimit = 255;
                _SRC(NUT_GLOBAL_UCAST);
                _DST(any);
        },
        {
                TargetAddress = DNS_SVR2_GLOBAL_UCAST;
                option = any;
        }
)

The first ping wait for 'ns_nut_dhcp_to_dns'
FEM_icmp6_ns(
        ns_nut_dhcp_to_dns,
        _HETHER_nut_to_dns_server,
        {
                HopLimit = 255;
                _SRC(NUT_GLOBAL_UCAST);
                _DST(any);
        },
        {
                TargetAddress = DNS_SVR1_GLOBAL_UCAST;
                option = any;
        }
)

I don't know the difference between DNS_SVR1_GLOBAL_UCAST with DNS_SVR2_GLOBAL_UCAST

Do u have any idea why tahi want two NS with different Target Address.

Comment 8 Yang Ren 2010-06-09 07:57:00 UTC
> So I hope you can pass the 'Part D' test when you configure the server to send
> both options (dhcp6.name-servers and dhcp6.domain-search). And also configure
> the client to request them both (or you can just delete the dhclient.conf,
> because they are both requested by default).    

I find Part C still failed. After restart interface. our client send dns query with type 12 (PTR)
http://10.66.65.86/DHCPv6_Self_Test_P2_1_1_0_client/rfc3646/10.html#vRecvPKT49

And for part D. I already use default behavior(require both dns and lst) But server side is tahi test case, we need let they send name server to pass the test? Is there some document about this behavior?

Comment 9 Jiri Popelka 2010-06-09 15:50:08 UTC
(In reply to comment #7)
> After restart interface tahi wait for 'ns_nut_dhcp_to_dns_2'
> The first ping wait for 'ns_nut_dhcp_to_dns'
> 
> I don't know the difference between DNS_SVR1_GLOBAL_UCAST with
> DNS_SVR2_GLOBAL_UCAST
> 
> Do u have any idea why tahi want two NS with different Target Address.    
Yang,
please read again my comment #6.

There are two DNS servers in the 4.1.9_Part_E test.
TN3 = 3ffe:501:ffff:100:200:ff:fe00:3f3e = DNS_SVR1_GLOBAL_UCAST and
TN4 = 3ffe:501:ffff:100:200:ff:fe00:3e3f = DNS_SVR2_GLOBAL_UCAST.

Before restart tahi sends TN3 (DNS_SVR1_GLOBAL_UCAST) to client and after restart (and rebind) tahi sends TN4 (DNS_SVR2_GLOBAL_UCAST) to client.
The reason is to see whether client changes (in /etc/resolv.conf) address (from TN3 to TN4) of DNS server.

I was again looking at the packet capture (especially on the part after restart) back and forth but can't figure out what's wrong.
The only idea I have now is that TAHI probably sent badly formed Reply (as a response for the first Rebind) and dhclient threw this packet away (because it was badly formed) and kept sending Rebind messages.

Comment 10 Jiri Popelka 2010-06-09 16:20:20 UTC
(In reply to comment #8)
> I find Part C still failed. After restart interface. our client send dns query
> with type 12 (PTR)

Yes, it should be AAAA (IPv6 address record) not PTR (pointer record).
AFAIK this is reverse lookup query.
But I totally cannot tell what's wrong here and where's the AAAA query.
As with 4.1.9_Part_E I was performing the 4.1.4_Part_C test here and everything looks correct to me.

> And for part D. I already use default behavior(require both dns and lst) But
> server side is tahi test case, we need let they send name server to pass the
> test? Is there some document about this behavior?    
Yes, this is obviously (for me) TAHI bug, because 4.1.4_Part_D says:
" 
 Upon the reception of a Request message from the NUT,
TN1 transmits a properly formatted Reply message including
a DNS Recursive Name Server option that includes
TN3 (DNS Server)’s global IPv6 address and
a Domain Search List option that includes “test.example.com”.
"
From the packet capture we can see that TAHI sends Reply with
Domain Search List option that includes “test.example.com”
but WITHOUT DNS Recursive Name Server option (even when the client requests this option).

All information I have is here:
http://www.ipv6ready.org/docs/Phase2_DHCPv6_Conformance_Latest.pdf

Comment 11 Yang Ren 2010-06-10 05:12:55 UTC
> I was again looking at the packet capture (especially on the part after
> restart) back and forth but can't figure out what's wrong.
> The only idea I have now is that TAHI probably sent badly formed Reply (as a
> response for the first Rebind) and dhclient threw this packet away (because it
> was badly formed) and kept sending Rebind messages.    

yeah Actually I have same idea. After got reply client still send a rebind msg. This should means this reply message did not work. so the dns server address in resolv.conf is not change/add. So that this test failed. I paste this reply message here for u to have a check.

And would u like to make a patch to show more debug information. So that I can run test again and give you more debug log.

Send DHCPv6 Reply Message: SERVER1 --> NUT at 08:10:57

Frame_Ether                     (length:174)
| Hdr_Ether                       (length:14)
| | DestinationAddress               = 00:1d:09:23:a9:1f
| | SourceAddress                    = 00:00:00:00:a1:a1
| | Type                             = 34525
| Packet_IPv6                     (length:160)
| | Hdr_IPv6                        (length:40)
| | | Version                          = 6
| | | TrafficClass                     = 0
| | | FlowLabel                        = 0
| | | PayloadLength                    = 120
| | | NextHeader                       = 17
| | | HopLimit                         = 64
| | | SourceAddress                    = fe80::200:ff:fe00:a1a1
| | | DestinationAddress               = fe80::21d:9ff:fe23:a91f
| | Upp_UDP                         (length:120)
| | | Hdr_UDP                         (length:8)
| | | | SourcePort                       = 547
| | | | DestinationPort                  = 546
| | | | Length                           = 120
| | | | Checksum                         = 40339 calc(40339)
| | | Udp_DHCPv6_Reply                (length:112)
| | | | Type                             = 7
| | | | Identifier                       = 9050661
| | | | Opt_DHCPv6_CID                  (length:18)
| | | | | Code                             = 1
| | | | | Length                           = 14
| | | | | DHCPv6_DUID_LLT_Ether           (length:14)
| | | | | | Type                             = 1
| | | | | | HardwareType                     = 1
| | | | | | Time                             = 327629510
| | | | | | LinkLayerAddress                 = 00:1d:09:23:a9:1f
| | | | Opt_DHCPv6_SID                  (length:18)
| | | | | Code                             = 2
| | | | | Length                           = 14
| | | | | DHCPv6_DUID_LLT_Ether           (length:14)
| | | | | | Type                             = 1
| | | | | | HardwareType                     = 1
| | | | | | Time                             = 400000
| | | | | | LinkLayerAddress                 = 00:00:00:00:a1:a1
| | | | Opt_DHCPv6_IA_NA                (length:44)
| | | | | Code                             = 3
| | | | | Length                           = 40
| | | | | Identifier                       = 153331999
| | | | | Time1                            = 50
| | | | | Time2                            = 80
| | | | | Opt_DHCPv6_IA_Address           (length:28)
| | | | | | Code                             = 5
| | | | | | Length                           = 24
| | | | | | Address                          = 3ffe:501:ffff:100::abcd
| | | | | | PreferredLifetime                = 100
| | | | | | ValidLifetime                    = 200
| | | | Opt_DHCPv6_StatusCode           (length:8)
| | | | | Code                             = 13
| | | | | Length                           = 4
| | | | | StatusCode                       = 0
| | | | | Message                          = 0000
| | | | Opt_DHCPv6_DNS_Servers          (length:20)
| | | | | Code                             = 23
| | | | | Length                           = 16
| | | | | Address                          = 3ffe:501:ffff:100:200:ff:fe00:3e3f

Comment 12 Yang Ren 2010-06-10 06:22:36 UTC
> Yes, it should be AAAA (IPv6 address record) not PTR (pointer record).
> AFAIK this is reverse lookup query.
> But I totally cannot tell what's wrong here and where's the AAAA query.
> As with 4.1.9_Part_E I was performing the 4.1.4_Part_C test here and everything
> looks correct to me.
> 
I test it several times I find client send NS for 3ffe:501:ffff:100:200:ff:fe00:3f3e and tahi test did not reply NA. I'm not sure which place got problem. So that client did not send AAAA query.

> > And for part D. I already use default behavior(require both dns and lst) But
> > server side is tahi test case, we need let they send name server to pass the
> > test? Is there some document about this behavior?    
> Yes, this is obviously (for me) TAHI bug, because 4.1.4_Part_D says:
> " 
>  Upon the reception of a Request message from the NUT,
> TN1 transmits a properly formatted Reply message including
> a DNS Recursive Name Server option that includes
> TN3 (DNS Server)’s global IPv6 address and
> a Domain Search List option that includes “test.example.com”.
> "
> From the packet capture we can see that TAHI sends Reply with
> Domain Search List option that includes “test.example.com”
> but WITHOUT DNS Recursive Name Server option (even when the client requests
> this option).
> 
> All information I have is here:
> http://www.ipv6ready.org/docs/Phase2_DHCPv6_Conformance_Latest.pdf    
Great I already sent mail to tahi about this.

Comment 18 Yang Ren 2010-08-13 09:42:01 UTC
Tahi still didn't reply me. Seems no one look at dhcp now.

Comment 19 ShanWei 2010-09-07 07:09:34 UTC
(In reply to comment #11)
> > I was again looking at the packet capture (especially on the part after
> > restart) back and forth but can't figure out what's wrong.
> > The only idea I have now is that TAHI probably sent badly formed Reply (as a
> > response for the first Rebind) and dhclient threw this packet away (because it
> > was badly formed) and kept sending Rebind messages.    
> 
> yeah Actually I have same idea. After got reply client still send a rebind msg.
> This should means this reply message did not work. so the dns server address in
> resolv.conf is not change/add. So that this test failed. I paste this reply
> message here for u to have a check.

I hit the same problem that after rebinding, client can't send DNS query message to TN4(3ffe:501:ffff:100:200:ff:fe00:3e3f), but the captured packet sequence is not different from yours. About captured packets see comment 20.

From the following log, the reply message for rebind is ok. But 3ffe:501:ffff:100::abcd is not rebind to eth0, So this lead to that NUT can't send ns_nut_dhcp_to_dns_2 packet to TN, and then fail to test.

The debug-info about dhclient is following:
[root@(none) ~]# dhclient -6  -d -cf /tmp/dhcp6c.conf eth0
Internet Systems Consortium DHCP Client 4.1.1-P1
Bound to *:546
Listening on Socket/eth0
Sending on   Socket/eth0
PRC: Soliciting for leases (INIT).
XMT: Forming Solicit, 0 ms elapsed.
XMT:  X-- IA_NA 17:71:51:f4
XMT:  | X-- Request renew in  +3600
XMT:  | X-- Request rebind in +5400
XMT: Solicit on eth0, interval 1010ms.
XMT: Forming Solicit, 1010 ms elapsed.
XMT:  X-- IA_NA 17:71:51:f4
XMT:  | X-- Request renew in  +3600
XMT:  | X-- Request rebind in +5400
XMT: Solicit on eth0, interval 1970ms.
XMT: Forming Solicit, 2980 ms elapsed.
XMT:  X-- IA_NA 17:71:51:f4
XMT:  | X-- Request renew in  +3600
XMT:  | X-- Request rebind in +5400
XMT: Solicit on eth0, interval 3750ms.
RCV: Advertise message on eth0 from fe80::200:ff:fe00:a1a1.
RCV:  X-- IA_NA 17:71:51:f4
RCV:  | X-- starts 1283929592
RCV:  | X-- t1 - renew  +50
RCV:  | X-- t2 - rebind +80
RCV:  | X-- [Options]
RCV:  | | X-- IAADDR 3ffe:501:ffff:100::abcd
RCV:  | | | X-- Preferred lifetime 100.
RCV:  | | | X-- Max lifetime 200.
RCV:  X-- Server ID: 00:01:00:01:00:06:1a:80:00:00:00:00:a1:a1
RCV:  Advertisement immediately selected.
PRC: Selecting best advertised lease.
PRC: Considering best lease.
PRC:  X-- Initial candidate 00:01:00:01:00:06:1a:80:00:00:00:00:a1:a1 (s: 152, p: 0).
XMT: Forming Request, 0 ms elapsed.
XMT:  X-- IA_NA 17:71:51:f4
XMT:  | X-- Requested renew  +3600
XMT:  | X-- Requested rebind +5400
XMT:  | | X-- IAADDR 3ffe:501:ffff:100::abcd
XMT:  | | | X-- Preferred lifetime +7200
XMT:  | | | X-- Max lifetime +7500
XMT:  V IA_NA appended.
XMT: Request on eth0, interval 1040ms.
RCV: Reply message on eth0 from fe80::200:ff:fe00:a1a1.
RCV:  X-- IA_NA 17:71:51:f4
RCV:  | X-- starts 1283929592
RCV:  | X-- t1 - renew  +50
RCV:  | X-- t2 - rebind +80
RCV:  | X-- [Options]
RCV:  | | X-- IAADDR 3ffe:501:ffff:100::abcd
RCV:  | | | X-- Preferred lifetime 100.
RCV:  | | | X-- Max lifetime 200.
RCV:  X-- Server ID: 00:01:00:01:00:06:1a:80:00:00:00:00:a1:a1
message status code Success.
PRC: Bound to lease 00:01:00:01:00:06:1a:80:00:00:00:00:a1:a1.
PRC: Renewal event scheduled in 48 seconds, to run for 30 seconds.
PRC: Depreference scheduled in 98 seconds.
PRC: Expiration scheduled in 198 seconds.
<==========================================(ifdown eth0; ifup eth0)
PRC: Renewing lease on eth0.
XMT: Forming Renew, 0 ms elapsed.
XMT:  X-- IA_NA 17:71:51:f4
XMT:  | X-- Requested renew  +3600
XMT:  | X-- Requested rebind +5400
XMT:  | | X-- IAADDR 3ffe:501:ffff:100::abcd
XMT:  | | | X-- Preferred lifetime +7200
XMT:  | | | X-- Max lifetime +7500
XMT:  V IA_NA appended.
XMT: Renew on eth0, interval 10670ms.
XMT: Forming Renew, 10680 ms elapsed.
XMT:  X-- IA_NA 17:71:51:f4
XMT:  | X-- Requested renew  +3600
XMT:  | X-- Requested rebind +5400
XMT:  | | X-- IAADDR 3ffe:501:ffff:100::abcd
XMT:  | | | X-- Preferred lifetime +7200
XMT:  | | | X-- Max lifetime +7500
XMT:  V IA_NA appended.
XMT: Renew on eth0, interval 19330ms.
PRC: Rebind event scheduled in 0 seconds, to run for 120 seconds.
PRC: Depreference scheduled in 20 seconds.
PRC: Expiration scheduled in 120 seconds.
PRC: Rebinding lease on eth0.
XMT: Forming Rebind, 0 ms elapsed.
XMT:  X-- IA_NA 17:71:51:f4
XMT:  | X-- Requested renew  +3600
XMT:  | X-- Requested rebind +5400
XMT:  | | X-- IAADDR 3ffe:501:ffff:100::abcd
XMT:  | | | X-- Preferred lifetime +7200
XMT:  | | | X-- Max lifetime +7500
XMT:  V IA_NA appended.
XMT: Rebind on eth0, interval 10560ms.
RCV: Reply message on eth0 from fe80::200:ff:fe00:a1a1.
RCV:  X-- IA_NA 17:71:51:f4
RCV:  | X-- starts 1283929672
RCV:  | X-- t1 - renew  +50
RCV:  | X-- t2 - rebind +80
RCV:  | X-- [Options]
RCV:  | | X-- IAADDR 3ffe:501:ffff:100::abcd
RCV:  | | | X-- Preferred lifetime 100.
RCV:  | | | X-- Max lifetime 200.
RCV:  X-- Server ID: 00:01:00:01:00:06:1a:80:00:00:00:00:a1:a1
message status code Success.
PRC: Bound to lease 00:01:00:01:00:06:1a:80:00:00:00:00:a1:a1.
PRC: Renewal event scheduled in 50 seconds, to run for 30 seconds.
PRC: Depreference scheduled in 100 seconds.
PRC: Expiration scheduled in 200 seconds.
Killed

Comment 20 ShanWei 2010-09-07 07:12:43 UTC
Created attachment 443413 [details]
dump file from NO.24 of RFC3646 section

The dump file is from NO.24 of RFC3646 section of DHCPv6_Self_Test_P2_1_1_0.

Comment 21 ShanWei 2010-09-07 07:14:03 UTC
(In reply to comment #19)
> (In reply to comment #11)
> > > I was again looking at the packet capture (especially on the part after
> > > restart) back and forth but can't figure out what's wrong.
> > > The only idea I have now is that TAHI probably sent badly formed Reply (as a
> > > response for the first Rebind) and dhclient threw this packet away (because it
> > > was badly formed) and kept sending Rebind messages.    
> > 
> > yeah Actually I have same idea. After got reply client still send a rebind msg.
> > This should means this reply message did not work. so the dns server address in
> > resolv.conf is not change/add. So that this test failed. I paste this reply
> > message here for u to have a check.
> 
> I hit the same problem that after rebinding, client can't send DNS query
> message to TN4(3ffe:501:ffff:100:200:ff:fe00:3e3f), but the captured packet
> sequence is not different from yours. About captured packets see comment 20.

dhclient version: dhclient-4.1.1-24.P1.fc13.x86_64

Comment 22 Jiri Popelka 2010-09-07 10:54:50 UTC
ShanWei,
this bug is filled against RHEL-6.
There's the same bug filled against Fedora (bug #574717),
so we can continue our Fedora related conversation there.

Comment 24 wang jiabo 2010-10-19 02:27:49 UTC
nobody take care the test script issue in TAHI and Ipv6ready so far. we have two choice to do : one close the bug until tahi or ipv6ready fix their suite. another continue waiting feedback from tahi or ipv6ready.
thanks
jiabo

Comment 25 Jiri Popelka 2010-11-04 15:58:40 UTC
Summary: 

4.1.4_Part_C
 - Must be some configuration problem.
   I have just tested it again and it works for me.

4.1.4_Part_D
 - Definitely (comment #12) TAHI test suite problem.

4.1.9_Part_E
 - Also works for me (tested many times).
   There's much more info in Fedora bug #574717, comment #25.

It's still notabug for me, but I don't mind leaving it open.

Comment 27 RHEL Program Management 2010-11-10 12:14:54 UTC
Development Management has reviewed and declined this request.  You may appeal
this decision by reopening this request.


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