Bug 574717
| Summary: | dhclient did not send DNS query message. | |||
|---|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | Yang Ren <ryang> | |
| Component: | dhcp | Assignee: | Jiri Popelka <jpopelka> | |
| Status: | CLOSED NOTABUG | QA Contact: | Fedora Extras Quality Assurance <extras-qa> | |
| Severity: | medium | Docs Contact: | ||
| Priority: | low | |||
| Version: | 13 | CC: | jpopelka, llim, shanwei | |
| Target Milestone: | --- | |||
| Target Release: | --- | |||
| Hardware: | All | |||
| OS: | Linux | |||
| Whiteboard: | ||||
| Fixed In Version: | Doc Type: | Bug Fix | ||
| Doc Text: | Story Points: | --- | ||
| Clone Of: | ||||
| : | 592163 (view as bug list) | Environment: | ||
| Last Closed: | 2010-11-26 16:29:39 UTC | Type: | --- | |
| Regression: | --- | Mount Type: | --- | |
| Documentation: | --- | CRM: | ||
| Verified Versions: | Category: | --- | ||
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | ||
| Cloudforms Team: | --- | Target Upstream Version: | ||
| Embargoed: | ||||
| Bug Depends On: | ||||
| Bug Blocks: | 592163 | |||
| Attachments: | ||||
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.
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.
(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. 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. Created attachment 443482 [details]
ShanWei's packet dump from 4.1.9_Part_E (rfc3464, test 24)
Yang,
as you maybe already know, ShanWei is also dealing with TAHI test suite.
I'm adding his results to this bug report so we can share our experiences.
ShanWei, your packet dump looks actually much better than the Yang's. I think the only problem is that you don't have TN4 machine (i.e. machine with 3ffe:501:ffff:100:200:ff:fe00:3e3f address). Can you add such a machine to your network (so you will have: dhcp server, dhcp client, TN3, TN4) and rerun the test ? (In reply to comment #6) > ShanWei, > > your packet dump looks actually much better than the Yang's. > I think the only problem is that you don't have TN4 machine > (i.e. machine with 3ffe:501:ffff:100:200:ff:fe00:3e3f address). > Can you add such a machine to your network > (so you will have: dhcp server, dhcp client, TN3, TN4) > and rerun the test ? As your request, configure DNS server with 3ffe:501:ffff:100:200:ff:fe00:3e3f. But it's still fail. TN can capture all packets on the interface that be used to communicate with NUT. So we don't need to configure any interface with 3ffe:501:ffff:100:200:ff:fe00:3e3f. TN3 and TN4 are all virtual interface. The DNS query message is like following. The source address is 3ffe:501:ffff:100::abcd, 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. I thought It's a bug of dhclient. Packet_IPv6 (length:89) | | Hdr_IPv6 (length:40) | | | Version = 6 | | | TrafficClass = 0 | | | FlowLabel = 0 | | | PayloadLength = 49 | | | NextHeader = 17 | | | HopLimit = 64 | | | SourceAddress = 3ffe:501:ffff:100::abcd | | | DestinationAddress = 3ffe:501:ffff:100:200:ff:fe00:3f3e | | Upp_UDP (length:49) | | | Hdr_UDP (length:8) | | | | SourcePort = 53910 | | | | DestinationPort = 53 | | | | Length = 49 | | | | Checksum = 64888 calc(64888) | | | Udp_DNS (length:41) | | | | Identifier = 53171 | | | | QR = 0 | | | | Opcode = 0 | | | | AA = 0 | | | | TC = 0 | | | | RD = 1 | | | | RA = 0 | | | | Reserved = 0 | | | | RCode = 0 | | | | QDCount = 1 | | | | ANCount = 0 | | | | NSCount = 0 | | | | ARCount = 0 | | | | DNS_Question (length:29) | | | | | DNS_QuestionEntry (length:29) | | | | | | Name = dhcpv6.test.example.com. | | | | | | Type = 28 (AAAA) | | | | | | Class = 1 Created attachment 443517 [details] Jiri's packet capture from test 24 (no TAHI) > The DNS query message is like following. The source address is > 3ffe:501:ffff:100::abcd, 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. I thought It's a bug of dhclient. Before you accuse dhclient/dhcpd you should verify that it's not a TAHI test suite problem. You should try to reproduce it without the TAHI test suite. And I always need to see the packet capture. I tried to reproduce it without TAHI and it works for me (see attached packet capture). That means that TAHI probably sends something (wrong Reply message) that dhclient doesn't understand. See also bug #592163, comment #11. So for me this is a TAHI test suite bug because 1) I passed the test when not using TAHI 2) We (Yang) already passed a test 1.1.1_Part_D that verifies that the client is able to accept the Reply in response to Rebind. ShanWei, your first packet dump looks good and also from bug #592163, comment #19 it seems that the client correctly received the Reply in response to Rebind. 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. So make sure there are TN3 and TN4 somewhere (real or virtual). Run the test, attach the packet dump and show me what does 'ip addr show eth0' on the client after it receives the Reply. (In reply to comment #8) > Created attachment 443517 [details] > Jiri's packet capture from test 24 (no TAHI) > > > The DNS query message is like following. The source address is > > 3ffe:501:ffff:100::abcd, 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. I thought It's a bug of dhclient. > Before you accuse dhclient/dhcpd you should verify that it's not a TAHI test > suite problem. You should try to reproduce it without the TAHI test suite. > And I always need to see the packet capture. > I tried to reproduce it without TAHI and it works for me (see attached packet > capture). Can you send out the reproduce steps and the config? > That means that TAHI probably sends something (wrong Reply message) that > dhclient doesn't understand. See also bug #592163, comment #11. > > So for me this is a TAHI test suite bug because > 1) I passed the test when not using TAHI > 2) We (Yang) already passed a test 1.1.1_Part_D that verifies that the client > is able to accept the Reply in response to Rebind. This case is different from No.24. This case don't ifdown interface, so the configured address won't be deleted. But, in No.24, we ifdown interface. The test flow of NO.24 is below: TN NUT solicit <----------------- advertise ------------------> request <----------------- reply ------------------> ping6 -n -c 1 -i 1 -s 2 -M want -p 00 -w 2 -I eth0 \ dhcpv6.test.example.com DNS query <----------------- ifdown eth0;ifup eth0 renew <----------------- renew <----------------- rebind <----------------- reply(for rebind) ------------------> ping6 -n -c 1 -i 1 -s 2 -M want -p 00 -w 2 -I eth0\ dhcpv6.test.example.com (In reply to comment #10) > Can you send out the reproduce steps and the config? Yes I can (and will) do that, but first I mention where (I think) we differ. See lower comment. > This case don't ifdown interface, so the configured address won't be deleted. > But, in No.24, we ifdown interface. You are right, sorry. > The test flow of NO.24 is below: > > TN NUT > solicit > <----------------- > advertise > ------------------> > request > <----------------- > reply > ------------------> > > ping6 -n -c 1 -i 1 -s 2 -M want -p 00 -w 2 -I eth0 \ > dhcpv6.test.example.com > DNS query > <----------------- > > ifdown eth0;ifup eth0 The IPv6Ready document says (4.1.9_Part_E): " 34. Disconnect TN1 from the link, after time T2 (80) seconds, reconnect TN1 into the link. " So I think this step should be ifdown eth0; sleep 80; ifup eth0 RFC3315 says (18.1.2) that whenever client reboots, it MUST initiate a Confirm/Reply message exchange. So now follows confirm/reply: confirm <----------------- reply (for confirm) ------------------> > renew > <----------------- > renew > <----------------- Here shouldn't be any renew because T2 already passed. So the client should now send only rebind. > rebind > <----------------- > reply(for rebind) > ------------------> > > ping6 -n -c 1 -i 1 -s 2 -M want -p 00 -w 2 -I eth0\ > dhcpv6.test.example.com Grrrr ... I was writing a looong comment with all my steps and configurations and when I wanted to send it Firefox said that I'm offline (which was true because of my experiments) and the BIG comment disappeared. :-( So now only the important. (In reply to comment #11) > The IPv6Ready document says (4.1.9_Part_E): > " 34. Disconnect TN1 from the link, after time T2 (80) seconds, reconnect TN1 > into the link. " > So I think this step should be > ifdown eth0; sleep 80; ifup eth0 I mixed up TN1 and NUT. The document talks about TN1, but there's NOTHING about disconnection/reconnecting of NUT. So I think there shouldn't be any ifdown/ifup on NUT. This can be one part of the problem (with TAHI). But in my case it works even if I ifdown/ifup the client, so I will AGAIN try to describe my steps and configurations. (In reply to comment #11) > > The test flow of NO.24 is below: > > > > TN NUT > > solicit > > <----------------- > > advertise > > ------------------> > > request > > <----------------- > > reply > > ------------------> > > > > ping6 -n -c 1 -i 1 -s 2 -M want -p 00 -w 2 -I eth0 \ > > dhcpv6.test.example.com > > DNS query > > <----------------- > > > > ifdown eth0;ifup eth0 > > The IPv6Ready document says (4.1.9_Part_E): > " 34. Disconnect TN1 from the link, after time T2 (80) seconds, reconnect TN1 > into the link. " But, actually, test scripts disconnect NUT's interface. Down TN1's interface and Down NUT's interface has material difference. The former won't cancel NUT's global address, But the later will cancel it. Firstly, let's ignore this TAHI tools bug. > So I think this step should be > ifdown eth0; sleep 80; ifup eth0 > I fix the test script like above and configure DNS server(3ffe:501:ffff:100:200:ff:fe00:3f3e, 3ffe:501:ffff:100:200:ff:fe00:3e3f) and then test again. It's still fail. About the dump file see comment 13 . > RFC3315 says (18.1.2) that whenever client reboots, it MUST initiate a > Confirm/Reply message exchange. So now follows confirm/reply: > > confirm > <----------------- > reply (for confirm) > ------------------> This is our material difference. In my test, I never saw dhcp client send any confirm message. > > > > renew > > <----------------- > > renew > > <----------------- > > Here shouldn't be any renew because T2 already passed. > So the client should now send only rebind. > > > rebind > > <----------------- > > reply(for rebind) > > ------------------> Now, the configure of NUT's eth0 is : [root@(none) ~]# ifconfig eth0 eth0 Link encap:Ethernet HWaddr 00:15:17:71:51:F4 inet addr:192.168.0.21 Bcast:192.168.0.255 Mask:255.255.255.0 inet6 addr: fe80::215:17ff:fe71:51f4/64 Scope:Link UP BROADCAST RUNNING PROMISC MULTICAST MTU:1500 Metric:1 RX packets:1142 errors:0 dropped:0 overruns:0 frame:0 TX packets:1907 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:168394 (164.4 KiB) TX bytes:194454 (189.8 KiB) Interrupt:16 Memory:fd440000-fd460000 > > > > ping6 -n -c 1 -i 1 -s 2 -M want -p 00 -w 2 -I eth0\ > > dhcpv6.test.example.com Created attachment 446028 [details]
Shan Wei 's packet of NO.24 of RFC3646（add sleep 80s between ifdown and ifup）
I'm so sorry I confused you. Do you agree with the following statement ? The IPV6Ready document talks (4.1.9_Part_E) about disconnecting/reconnecting the TN1, but there's nothing about disconnecting/reconnecting the NUT, so the TAHI should NOT ifdown/ifup the clients interface. With the following configurations and steps I pass the 4.1.9_Part_E test.
Configurations:
[TN1]
# cat /etc/sysconfig/network-scripts/ifcfg-eth1 (TN1 interface configuration)
DEVICE=eth1
BOOTPROTO=none
ONBOOT=no
NM_CONTROLLED=no
IPV6INIT=yes
IPV6ADDR=3ffe:501:ffff:100:200:ff:fe00:1/112
# cat /etc/dhcp/dhcpd6.conf (TN1 configuration)
option dhcp-renewal-time 50;
option dhcp-rebinding-time 80;
option dhcp6.name-servers 3ffe:501:ffff:100:200:ff:fe00:3f3e;
subnet6 3ffe:501:ffff:100:200:ff:fe00:0/112 {
range6 3ffe:501:ffff:100:200:ff:fe00:abcc 3ffe:501:ffff:100:200:ff:fe00:abcd;
}
[NUT]
# cat /etc/sysconfig/network-scripts/ifcfg-eth1 (NUT interface configuration)
DEVICE=eth1
BOOTPROTO=none
ONBOOT=no
NM_CONTROLLED=no
IPV6INIT=yes
DHCPV6C=yes
# cat /etc/dhcp/dhclient.conf (NUT configuration)
interface "eth1" {
request dhcp6.name-servers;
}
Steps to reproduce:
[TN1]
# ifup eth1 (up the TN1 interface)
# ip addr add 3ffe:501:ffff:100:200:ff:fe00:3f3e/112 dev eth1 (add TN3 address)
# ip addr add 3ffe:501:ffff:100:200:ff:fe00:3e3f/112 dev eth1 (add TN4 address)
# ip addr show eth1 (check the interface addresses)
2: eth1:
inet6 3ffe:501:ffff:100:200:ff:fe00:3e3f/112 scope global
valid_lft forever preferred_lft forever
inet6 3ffe:501:ffff:100:200:ff:fe00:3f3e/112 scope global
valid_lft forever preferred_lft forever
inet6 3ffe:501:ffff:100:200:ff:fe00:1/112 scope global
valid_lft forever preferred_lft forever
# > /var/lib/dhcpd/dhcpd6.leases; (clear old leases)
# dhcpd -6 -d -cf /etc/dhcp/dhcpd6.conf eth1 (start TN1)
# (start wireshark to capture on eth1)
[NUT]
# ifdown eth1 (make sure the interface is down)
# rm -f /var/lib/dhclient/dhclient6* (remove old leases)
# ifup eth1; (get address and TN3 address)
# ip addr show eth1 (verify that NUT has address)
# cat /etc/resolv.conf (verify there's TN3 address)
# ping6 dhcpv6.test.example.com (send DNS query to TN3)
[back to TN1]
# stop the dhcpd
# change TN3 to TN4 in /etc/dhcp/dhcpd6.conf (i.e. change
option dhcp6.name-servers 3ffe:501:ffff:100:200:ff:fe00:3f3e;
to
option dhcp6.name-servers 3ffe:501:ffff:100:200:ff:fe00:3e3f;)
# sleep 80 (wait for T2)
# dhcpd -6 -d -cf /etc/dhcp/dhcpd6.conf eth1 (start again TN1)
[back to NUT]
# ifdown eth1; ifup eth1 (As I stated in my previous commend I think we should NOT do this step, because IPv6Ready document doesn't say anything about restarting NUT. But it works with it too. If you do this step, you should see one additional Confirm/Reply msq exchange.)
# ip addr show eth1 (verify that NUT has address)
# cat /etc/resolv.conf (verify there's TN4 address)
# ping6 dhcpv6.test.example.com (send DNS query to TN4)
(In reply to comment #15) > I'm so sorry I confused you. > > Do you agree with the following statement ? Yes，I very agree with it. > > The IPV6Ready document talks (4.1.9_Part_E) about > disconnecting/reconnecting the TN1, > but there's nothing about disconnecting/reconnecting the NUT, > so the TAHI should NOT ifdown/ifup the clients interface. (In reply to comment #16) > With the following configurations and steps I pass the 4.1.9_Part_E test. The informations you provided are very...very valuable. I know why this case failed. I can let it PASS according to your provided informations. The eth1 of NUT is configured with "DHCPV6C = yes". When we ifup eth1, initscripts will start dhclient. When we ifdown eth1, dhclient will be killed. When NUT restart the eth1 a second time, dhclient sends confirm message to TN according to the release file. But, for TAHI test case, When NUT restart the eth1 a second time, we don't restart dhclient program. So, this leads to that dhclient doesn't send confirm message to TN. You can reproduce TAHI's test procedures like this: (The difference includes killing DHCPV6C=yes from eth1 of NUT and start dhclient only once.) Configurations： [TN1](same with yours) # cat /etc/sysconfig/network-scripts/ifcfg-eth1 (TN1 interface configuration) DEVICE=eth1 BOOTPROTO=none ONBOOT=no NM_CONTROLLED=no IPV6INIT=yes IPV6ADDR=3ffe:501:ffff:100:200:ff:fe00:1/112 # cat /etc/dhcp/dhcpd6.conf (TN1 configuration) option dhcp-renewal-time 50; option dhcp-rebinding-time 80; option dhcp6.name-servers 3ffe:501:ffff:100:200:ff:fe00:3f3e; subnet6 3ffe:501:ffff:100:200:ff:fe00:0/112 { range6 3ffe:501:ffff:100:200:ff:fe00:abcc 3ffe:501:ffff:100:200:ff:fe00:abcd; } [NUT](*kill DHCPV6C=yes*) # cat /etc/sysconfig/network-scripts/ifcfg-eth1 (NUT interface configuration) DEVICE=eth1 BOOTPROTO=none ONBOOT=no NM_CONTROLLED=no IPV6INIT=yes # cat /etc/dhcp/dhclient.conf (NUT configuration) interface "eth1" { request dhcp6.name-servers; } Steps to reproduce: [TN1] # ifup eth1 (up the TN1 interface) # ip addr add 3ffe:501:ffff:100:200:ff:fe00:3f3e/112 dev eth1 (add TN3 address) # ip addr add 3ffe:501:ffff:100:200:ff:fe00:3e3f/112 dev eth1 (add TN4 address) # ip addr show eth1 (check the interface addresses) 2: eth1: inet6 3ffe:501:ffff:100:200:ff:fe00:3e3f/112 scope global valid_lft forever preferred_lft forever inet6 3ffe:501:ffff:100:200:ff:fe00:3f3e/112 scope global valid_lft forever preferred_lft forever inet6 3ffe:501:ffff:100:200:ff:fe00:1/112 scope global valid_lft forever preferred_lft forever # > /var/lib/dhcpd/dhcpd6.leases; (clear old leases) # dhcpd -6 -d -cf /etc/dhcp/dhcpd6.conf eth1 (start TN1) # (start wireshark to capture on eth1) [NUT] # rm -f /var/lib/dhclient/dhclient6* (remove old leases) # dhclient -6 -d -cf /etc/dhcp/dhclient.conf eth1 # ip addr show eth1 (verify that NUT has address) # cat /etc/resolv.conf (verify there's TN3 address) # ping6 dhcpv6.test.example.com (send DNS query to TN3) [back to TN1] # stop the dhcpd # change TN3 to TN4 in /etc/dhcp/dhcpd6.conf (i.e. change option dhcp6.name-servers 3ffe:501:ffff:100:200:ff:fe00:3f3e; to option dhcp6.name-servers 3ffe:501:ffff:100:200:ff:fe00:3e3f;) # sleep 80 (wait for T2) # dhcpd -6 -d -cf /etc/dhcp/dhcpd6.conf eth1 (start again TN1) [back to NUT] # ifdown eth1; ifup eth1 # ip addr show eth1 (NUT has not configured with address) # cat /etc/resolv.conf (there's TN4 address) # ping6 dhcpv6.test.example.com =====QUESTION======================================================= Why don't we listen NIC event and send confirm message if NIC has changed status form down to up like dhcpv6-client, although dhcpv6-client is abandoned? I think this feature is useful for user who manually start the dhcp client and don't take any conflict with 18.1.2 section of RFC3315. RFC3315: 18.1.2. Creation and Transmission of Confirm Messages Whenever a client may have moved to a new link, the prefixes from the addresses assigned to the interfaces on that link may no longer be appropriate for the link to which the client is attached. Examples of times when a client may have moved to a new link include: o The client reboots. o The client is physically connected to a wired connection. o The client returns from sleep mode. o The client using a wireless technology changes access points. In any situation when a client may have moved to a new link, the client MUST initiate a Confirm/Reply message exchange. (In reply to comment #18) > The informations you provided are very...very valuable. Thanks > I know why this case failed. I can let it PASS according to your provided > informations. The eth1 of NUT is configured with "DHCPV6C = yes". When we ifup > eth1, initscripts will start dhclient. When we ifdown eth1, dhclient will be > killed. When NUT restart the eth1 a second time, dhclient sends confirm message > to TN according to the release file. Correct > But, for TAHI test case, When NUT restart > the eth1 a second time, we don't restart dhclient program. So, this leads to > that dhclient doesn't send confirm message to TN. > > You can reproduce TAHI's test procedures like this: > (The difference includes killing DHCPV6C=yes from eth1 of NUT and start > dhclient only once.) But it is you who configure the NUT's interface so it's up to you whether you put DHCPV6C=yes in ifcfg-eth1. Am I wrong ? If you leave it there, then the dhclient is restarted with interface restart. But then when TAHI manually starts dhclient you need to tell it to start it the same way as ifup script does, i.e. with '-lf /var/lib/dhclient/dhclient6-eth1.leases'. This ensures that the same leases file is always used. We don't need to use a ' -cf /etc/dhcp/dhclient.conf' because /etc/dhcp/dhclient.conf is used by default. So my suggestion how to pass the TAHI test: Configurations: Put the 'DHCPV6C=yes' back into /etc/sysconfig/network-scripts/ifcfg-eth1 Steps: [NUT] Start dhclient like this: dhclient -6 -lf /var/lib/dhclient/dhclient6-eth1.leases eth1 BTW. Did you pass the 1.1.1_Part_B test ? I ask because this test is about restarting the NUT's interface to make the client send Confirm message. > =====QUESTION======================================================= > Why don't we listen NIC event and send confirm message if NIC has > changed status form down to up like dhcpv6-client, although dhcpv6-client > is abandoned? I'm afraid this is too much work. And I don't see any reason for it when DHCPV6C variable does actually the same. > I think this feature is useful for user who manually start > the dhcp client and don't take any conflict with 18.1.2 section of RFC3315. I doubt somebody needs (except in some experiments) to start dhclient manually. You can always use the DHCPV6C variable. And if somebody (like you) need to start dhclient manually and also restart the interface, (s)he should start the dhclient the same way as ifup script does. Created attachment 447218 [details] Content of bug 559400 We have already been solving this with Yang in bug #559400. Because #559400 is marked as private I'm attaching the content here (there's NOTHING private in it). This message is a reminder that Fedora 12 is nearing its end of life. Approximately 30 (thirty) days from now Fedora will stop maintaining and issuing updates for Fedora 12. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as WONTFIX if it remains open with a Fedora 'version' of '12'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version prior to Fedora 12's end of life. Bug Reporter: Thank you for reporting this issue and we are sorry that we may not be able to fix it before Fedora 12 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora please change the 'version' of this bug to the applicable version. If you are unable to change the version, please add a comment here and someone will do it for you. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete. The process we are following is described here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping I still see this as NOTABUG but leave it open for now. I understand this properly is a bug in tahi test suit. We still got some failure about tahi dhcp test. In order to allow other people know what we meet in tahi dhcp testing I keep this bug open. We always testing the nearest package So the version should not be a problem. So Jiri Should we close this bug? I understand this properly is a bug in tahi test suit. We still got some failure about tahi dhcp test. In order to allow other people know what we meet in tahi dhcp testing I keep this bug open. We always testing the nearest package So the version should not be a problem. So Jiri Should we close this bug? Ok, I'll try to summarise what's this bug (and it's clone bug #592163) actually all about because after few months it will be (even now it is) hard to remember. We are talking about 4.1.9_Part_E (rfc3464, test 24) from http://www.ipv6ready.org/docs/Phase2_DHCPv6_Conformance_Latest.pdf Summary of this test (we are testing client here): 1) Server sends address of DNS server TN3 to client and we make sure client is able to use it (TN3). 2) Server disconnects, waits for T2 (80 seconds) and connects again. 3) Client sends Rebind and server sends address of DNS server TN4 (different from TN3) in Reply. 4) Again we make sure than client is able to use it (TN4). The problem here is that YangRen reports different behaviour than ShanWei. Packet dump from YangRen's report shows that server sends Reply, but client ignores it. We both think that TAHI *probably* sends wrong Reply and that's the reason why client ignores it (so the client doesn't get the TN4). From ShanWei's packet dump (https://bugzilla.redhat.com/attachment.cgi?id=443482) it seems (bug #574717, comment #9) to me that the client had got the Reply with TN4 but hadn't sent a query to it because there had been no interface with TN4 address where to send the query (see no response for Neighbor solicitation in the end of packet capture). Then (bug #574717, comment #17) we both with ShanWei agreed that TAHI *should not* restart client's interface (because there's nothing such mentioned in the test description). Note: Would be great if you could report (or make sure it's reported) upstream (TAHI). But it should work even with the restart of client's interface (see bug #574717, comment #19). ShanWei: is there any progress ? (In reply to comment #25) > Then (bug #574717, comment #17) we both with ShanWei agreed > that TAHI *should not* restart client's interface (because there's nothing such > mentioned in the test description). > Note: Would be great if you could report (or make sure it's reported) upstream > (TAHI). This bug is trivial. I have submitted some patches to fix other problems for TAHI test cases. But there is no reply. :-( > But it should work even with the restart of client's interface (see bug > #574717, comment #19). > ShanWei: is there any progress ? After adding 'DHCPV6C=yes' back into ifcfg-eth1, test result is pass. Your summaries is sufficiency, there is no other supplementary information for me. (In reply to comment #26) > After adding 'DHCPV6C=yes' back into ifcfg-eth1, test result is pass. Then I think we can eventually close this. |
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.