Bug 629894

Hi again ShanWei,

I'm glad you are using dhclient instead of dhcpv6-client.
It seem that you are dealing with TAHI test suite, aren't you ?
Good news is that you are not alone, who hit this problem.
This bug is actually duplicate of bug #574717 (and bug #592163),
but I'll leave it as a separate bug for now.
Please read those bugs, you can find useful informations there.
You can also contact Yang Ren, he's experienced in this area.

Back to your problem:

The only problem that I see with your configuration is the configuration of
dhclient.
 interface " eth1 "
 {
   request dhcp6.name-servers;
   request dhcp6.oro;
   request dhcp6.info-refresh-time;
 }

1) interface " eth1 "
- remove the spaces between " and eth1, i.e. replace " eth1 " with "eth1", otherwise this interface configuration will be ignored
2) request dhcp6.name-servers;
- please read bug #574717, comment #1
- if you want ONLY name-servers, then it's ok, otherwise remove this line, because name-servers option is requested by default
3) request dhcp6.oro;
- this is nonsense. What are you trying to achieve ?
- see dhcp-options man page:
option dhcp6.oro uint16 [ , uint16, ... ];
      The  Option  Request  Option  ("ORO") is the DHCPv6 equivalent of the parameter-request-list. Clients supply this option to ask servers to reply with options relevant to their  needs and use.  This option must not be directly configured, the request syntax in dhclient.conf (5) should be used instead.
- remove this line and do not use this option anymore
4)  request dhcp6.info-refresh-time;
- please read bug #574717, comment #1
- this request overrides the previous and the default request option list

Few examples:
interface "eth1" {
 request dhcp6.name-servers, dhcp6.info-refresh-time;
}
will request ONLY name-servers and info-refresh-time. I guess this is what you want.

interface "eth1" {
 request dhcp6.name-servers;
 request dhcp6.info-refresh-time;
}
will request ONLY info-refresh-time.

interface "eth1" {
 also request dhcp6.info-refresh-time;
}
will request name-servers, domain-search and info-refresh-time.

If you use empty (or no) configuration file, the name-servers and domain-search options will be requested (by default).
This is your situation now, because the configuration for your interface is ignored at the moment, see (1).

To get more information about what's wrong I need you to 
A) Start client and server with -d parameter so we can see their output
B) run wireshark on client (install wireshark-gnome package)
to see messages going from (firs to DHCP server and then to DNS server) and to client

Steps:
1) fix the dhclient configuration
2) on client machine install wireshark-gnome, run wireshark
3) in menu Capture->Options..., select your interface (i.e. eth1), press Start
4) Start server, this time add the -d option
 dhcpd -6 -d -cf /tmp/dhcp6s.conf eth1
5) Start client, this time add the -d option
 dhclient -6 -d -S  -cf /tmp/dhcp6c.conf eth1
6) ping the dhcpv6.test.example.com
 ping6 -n -c 1 -i 1 -s 2 -M want -p 00 -w 2 -I eth1 dhcpv6.test.example.com
7) after a while stop the capturing in wireshark
8) save the packet capture (Save as...) and attach it here
9) show me the output from running server and client
10) show me what's in client's /etc/resolv.conf

thank you

(In reply to comment #1)
> Hi again ShanWei,
> 
> I'm glad you are using dhclient instead of dhcpv6-client.
> It seem that you are dealing with TAHI test suite, aren't you ?

Yes. you are right. 
Thanks for your reply and explanation about option configure very much.

> Good news is that you are not alone, who hit this problem.
> This bug is actually duplicate of bug #574717 (and bug #592163),
> but I'll leave it as a separate bug for now.
> Please read those bugs, you can find useful informations there.
> You can also contact Yang Ren, he's experienced in this area.

OK, got it.

> 
> To get more information about what's wrong I need you to 
> A) Start client and server with -d parameter so we can see their output
> B) run wireshark on client (install wireshark-gnome package)
> to see messages going from (firs to DHCP server and then to DNS server) and to
> client
> 
> Steps:
> 1) fix the dhclient configuration
> 2) on client machine install wireshark-gnome, run wireshark
> 3) in menu Capture->Options..., select your interface (i.e. eth1), press Start
> 4) Start server, this time add the -d option
>  dhcpd -6 -d -cf /tmp/dhcp6s.conf eth1
> 5) Start client, this time add the -d option
>  dhclient -6 -d -S  -cf /tmp/dhcp6c.conf eth1
> 6) ping the dhcpv6.test.example.com
>  ping6 -n -c 1 -i 1 -s 2 -M want -p 00 -w 2 -I eth1 dhcpv6.test.example.com
> 7) after a while stop the capturing in wireshark
> 8) save the packet capture (Save as...) and attach it here
> 9) show me the output from running server and client
> 10) show me what's in client's /etc/resolv.conf
> 
> thank you

*Server*:
[root@TN rfc3736]# dhcpd -6 -d -cf /tmp/dhcp6s.conf eth1
Internet Systems Consortium DHCP Server 4.2.0
Copyright 2004-2010 Internet Systems Consortium.
All rights reserved.
For info, please visit https://www.isc.org/software/dhcp/
Wrote 0 leases to leases file.
Bound to *:547
Listening on Socket/5/eth1/3ffe:501:ffff:100::/64
Sending on   Socket/5/eth1/3ffe:501:ffff:100::/64
Information-request message from fe80::215:17ff:fe71:51f4 port 546, transaction ID 0xC6237B00
Sending Reply to fe80::215:17ff:fe71:51f4 port 546

*Client*:
[root@(none) ~]# dhclient -6  -d -S  -cf /tmp/dhcp6c.conf eth0
Internet Systems Consortium DHCP Client 4.1.1-P1
Copyright 2004-2010 Internet Systems Consortium.
All rights reserved.
For info, please visit https://www.isc.org/software/dhcp/

Bound to *:546
Listening on Socket/eth0
Sending on   Socket/eth0
PRC: Requesting information (INIT).
XMT: Forming Info-Request, 0 ms elapsed.
XMT: Info-Request on eth0, interval 930ms.
RCV: Reply message on eth0 from fe80::225:86ff:fe9d:3efa.
PRC: Done.
[root@(none) ~]# ping6 -n -c 1 -i 1 -s 2 -M want -p 00 -w 2 -I eth0 dhcpv6.test.example.com
PATTERN: 0x00

unknown host
[root@(none) ~]# cat /etc/resolv.conf 
; generated by /sbin/dhclient-script
nameserver 3ffe:501:ffff:100:200:ff:fe00:3f3e

Created attachment 443260 [details]
dump file about dhcpv6

Hi

1) When did you stop the packet capture ? Before or after the 'ping6' ?
2) Is there any 3ffe:501:ffff:100:200:ff:fe00:3f3e machine on your network ?
If not, please make a machine with address 3ffe:501:ffff:100:200:ff:fe00:3f3e and perform the test again. Stop the packet capture after the 'ping6' returns 'unknown host'. Attach the new packet capture. Outputs from client and server are not needed this time. thanks

(In reply to comment #4)
> Hi
> 
> 1) When did you stop the packet capture ? Before or after the 'ping6' ?
after the ping6

> 2) Is there any 3ffe:501:ffff:100:200:ff:fe00:3f3e machine on your network ?
> If not, please make a machine with address 3ffe:501:ffff:100:200:ff:fe00:3f3e
> and perform the test again. Stop the packet capture after the 'ping6' returns
> 'unknown host'. Attach the new packet capture. Outputs from client and server
> are not needed this time. thanks

There is no 3ffe:501:ffff:100:200:ff:fe00:3f3e machine.

Configure which machine with this address? at server, right?
(do ping6 on client.)

which interface? eth1 on server, or other?

Ok. We are talking about tests from this document, aren't we ?
http://www.ipv6ready.org/docs/Phase2_DHCPv6_Conformance_Latest.pdf    

Probably one (or many) of them is not doing what you want and you
are trying to discover what's wrong, right ?

Then you can tell me which test are we talking about so I would know
what we are trying to achieve.

But I guess we are trying to verify that the client is able to obtain
and use adress of DNS server.
At this time we know, that the DHCP server sent the address (3ffe:501:ffff:100:200:ff:fe00:3f3e) of DNS server and that the client
received it and saved it into his resolver.conf.
(BTW. so we know now that the dhcpv6 client is working correctly)

And now when you ping6 dhcpv6.test.example.com the client machine should
1) try to find out (from DNS) what the ip address of dhcpv6.test.example.com is
2) if it discovers the ip address it sends ICMP echo to that address.

When you ping6 dhcpv6.test.example.com we should see in the packet capture that
1) client machine sends a Neighbor solicitation message to the DNS server (i.e. to 3ffe:501:ffff:100:200:ff:fe00:3f3e)
2) DNS server answers with Neighbor advertisement
3) client sends DNS query to DNS server
I don't know what do you need to pass the test, but I guess that step (3) is sufficient.

If you don't have machine with 3ffe:501:ffff:100:200:ff:fe00:3f3e than the client don't know where (to which link-layer address) to send the DNS query.

Yes, it can be the same machine as the server.
But it would be better if it could be a different machine,
so we could distinguish the addresses of DHCP server and DNS server in the packet capture.

Created attachment 443316 [details]
the newer dhcpv6 dns dump file

(In reply to comment #6)
> Ok. We are talking about tests from this document, aren't we ?

Yes. we are talking about the same thing. The test case is NO.2(Test DHCP_CONF.7.1.1 : Basic Message Exchange) of RFC3736 directory.

> And now when you ping6 dhcpv6.test.example.com the client machine should
> 1) try to find out (from DNS) what the ip address of dhcpv6.test.example.com is
> 2) if it discovers the ip address it sends ICMP echo to that address.
> 
> When you ping6 dhcpv6.test.example.com we should see in the packet capture that
> 1) client machine sends a Neighbor solicitation message to the DNS server (i.e.
> to 3ffe:501:ffff:100:200:ff:fe00:3f3e)
> 2) DNS server answers with Neighbor advertisement
> 3) client sends DNS query to DNS server
> I don't know what do you need to pass the test, but I guess that step (3) is
> sufficient.

Previous, I don't configure eth0 of NUT with global IPv6 address and DNS server.
and don't map domain name with address on /etc/hosts. Now I fixed them, and attached the newer dump file(see comment 7). From the newer dump file, we saw that ping6 is successful, but NUT(client) still doesn't send DNS query to DNS server. Have I missed something?

> 
> If you don't have machine with 3ffe:501:ffff:100:200:ff:fe00:3f3e than the
> client don't know where (to which link-layer address) to send the DNS query.
> 
> Yes, it can be the same machine as the server.
> But it would be better if it could be a different machine,
> so we could distinguish the addresses of DHCP server and DNS server in the
> packet capture.

(In reply to comment #8)
> Previous, I don't configure map domain name with address on /etc/hosts.

Map domain name with address like this:
#cat /etc/hosts
3ffe:501:ffff:100:200:ff:fe00:3f3e dhcpv6.test.example.com

> Map domain name with address like this:
> #cat /etc/hosts
> 3ffe:501:ffff:100:200:ff:fe00:3f3e dhcpv6.test.example.com
Ok, this explains why the client sends ICMPv6 Echo request
directly to 3ffe:501:ffff:100:200:ff:fe00:3f3e
when you ping dhcpv6.test.example.com

If you have configured /etc/hosts like so, then when you
'ping6 dhcpv6.test.example.com'
client finds in /etc/hosts that the IP address of dhcpv6.test.example.com
is 3ffe:501:ffff:100:200:ff:fe00:3f3e
and sends ICMPv6 Echo request (that's what ping6 sends) directly
to that address.
But that's NOT what you need.
3ffe:501:ffff:100:200:ff:fe00:3f3e is the address of DNS server.
And dhcpv6.test.example.com is some other machine - it's not existing, but we don't care about this.

From the IPv6Ready document:
Observable Results:
 Step 5: The NUT must process the correct Reply message and transmit a DNS Standard Query to TN3.

So you don't need the ping6 to be succesfull.
All you need is to see that the client sends a DNS query to 3ffe:501:ffff:100:200:ff:fe00:3f3e

So, remove the
3ffe:501:ffff:100:200:ff:fe00:3f3e dhcpv6.test.example.com
line from /etc/hosts
and it should be ok (as it is in my case).

(In reply to comment #11)
> So, remove the
> 3ffe:501:ffff:100:200:ff:fe00:3f3e dhcpv6.test.example.com
> line from /etc/hosts
> and it should be ok (as it is in my case).

hoho... yes, you are right. :-)
Killed the mapper from /etc/hosts, It's PASS.