Description of problem: It's about the No.30 case of rfc3633 for dhcp server testing in DHCPv6_Self_Test tool. The case is Part E with title "NoPrefixAvail status" of DHCP_CONF.11.3.1. See the procedure from IPv6 READY Phase II Test Specification DHCPv6. Version-Release number of selected component (if applicable): dhcp-4.1.1-24.P1.fc13.x86_64 Steps to Reproduce: 1. NUT start dhcpd service. #dhcpd -6 -cf /tmp/dhcp6s.conf eth1 #cat /tmp/dhcp6s.conf default-lease-time 20000; preferred-lifetime 20000; option dhcp-renewal-time 50; option dhcp-rebinding-time 80; subnet6 3ffe:501:ffff:100::/64 { range6 3ffe:501:ffff:100::10 3ffe:501:ffff:100::11; option dhcp6.name-servers 3ffe:501:ffff:100:200:ff:fe00:3f3e; } 2. TN send solicit message with IA-PD option and IA-PD prefix option. The message if below: | | | Udp_DHCPv6_Solicit (length:73) | | | | Type = 1 | | | | Identifier = 100 | | | | Opt_DHCPv6_CID (length:18) | | | | | Code = 1 | | | | | Length = 14 | | | | | DHCPv6_DUID_LLT_Ether (length:14) | | | | | | Type = 1 | | | | | | HardwareType = 1 | | | | | | Time = 300000 | | | | | | LinkLayerAddress = 0:0:0:0:a2:a2 | | | | Opt_DHCPv6_IA_PD (length:45) | | | | | Code = 25 | | | | | Length = 41 | | | | | Identifier = 303030 | | | | | Time1 = 50 | | | | | Time2 = 80 | | | | | Opt_DHCPv6_IA_Prefix (length:29) | | | | | | Code = 26 | | | | | | Length = 25 | | | | | | PreferredLifetime = 100 | | | | | | ValidLifetime = 200 | | | | | | PrefixLength = 48 | | | | | | Prefix = 2002:db8:ffff:: | | | | Opt_DHCPv6_ElapsedTime (length:6) | | | | | Code = 8 | | | | | Length = 2 | | | | | Time = 0 Actual results: TN can't received advertise message. Expected results: TN can received advertise message including status code and status code is set with NoPrefixAvail. Additional info: 1. Send solicit message with IA-PD option and IA-PD prefix option is available. See section 11.2.(Delegating router behavior) of rfc3633: If the requesting router includes an IA_PD Prefix option in the IA_PD option in its Solicit message, the delegating router MAY choose to use the information in that option to select the prefix(es) or prefix size to be delegated to the requesting router. 2. The behavior is defined for DHCP server(delegating router) when there is no prefix avail. See section 11.2.(Delegating router behavior) of rfc3633: If the delegating router will not assign any prefixes to any IA_PDs in a subsequent Request from the requesting router, the delegating router MUST send an Advertise message to the requesting router that includes the IA_PD with no prefixes in the IA_PD and a Status Code option in the IA_PD containing status code NoPrefixAvail and a status message for the user.
Did you pass the test "DHCP_CONF.11.1.8: Status Code Option Format" ? To me it seems that "DHCP_CONF.11.3.1 Part E" is pretty much the same as "DHCP_CONF.11.1.8" with the difference that: - "11.1.8" checks whether the Advertise has correct status code - "11.3.1 Part E" checks whether the Advertise contains IA_PD with correct status code
I was able to reproduce the problem. Steps to Reproduce: 1. NUT (delegating router) # cat /etc/dhcp/dhcpd6.conf subnet6 3ffe:501:ffff:100::/64 { prefix6 3ffe:501:ffff:100:: 3ffe:501:ffff:200:: /64; } # > /var/lib/dhcpd/dhcpd6.leases; dhcpd -6 -d -cf /etc/dhcp/dhcpd6.conf eth1 2. TN (requesting router) # > /var/lib/dhclient/dhclient6.leases; dhclient -6 -P -d eth1 # (press Ctrl+c after client gets the prefix) # dhclient -6 -P -d -r eth1 (release the prefix) 3. NUT # ctrl+c (stop the running dhcpd) # (remove the prefix6 line from dhcpd6.conf) # > /var/lib/dhcpd/dhcpd6.leases; dhcpd -6 -d -cf /etc/dhcp/dhcpd6.conf eth1 4. TN # dhclient -6 -P -d eth1 Actual results: NUT receives Solicit messages from TN but doesn't respond (with Advertise).
I made a scratch-build. I'm still not completely happy with the fix, but you can test it if you want. http://koji.fedoraproject.org/koji/taskinfo?taskID=2473890
(In reply to comment #3) > I made a scratch-build. > I'm still not completely happy with the fix, > but you can test it if you want. > http://koji.fedoraproject.org/koji/taskinfo?taskID=2473890 So sorry to reply you so later. I have test this packet, but the result is still fail. Can you send me the fixed patch? I try to debug this problem, and find the problem is in lease_to_client(). When dhcp server received the solicit message, and handled it with below code. See the comment in the code. ##server/dhcpv6.c lease_to_client(): ..skip.. reply.pd_count = 0; oc = lookup_option(&dhcpv6_universe, packet->options, D6O_IA_PD); for (; oc != NULL ; oc = oc->next) { isc_result_t status; /* Start counting resources (prefixes) offered. */ reply.client_resources = 0; reply.resources_included = ISC_FALSE; status = reply_process_ia_pd(&reply, oc); *<==handle IA_PD prefix, and return ISC_R_NORESOURCES!!* /* * We continue to try other IA_PD's whether we can address * this one or not. Any other result is an immediate fail. */ if ((status != ISC_R_SUCCESS) && (status != ISC_R_NORESOURCES)) goto exit; /* * If any prefix cannot be given to any IA_PD, then * set the NoPrefixAvail status code. */ if (reply.client_resources == 0) no_resources_avail = ISC_TRUE; } ##reply.ia_count and reply.pd_count are all equal to 0. And the message type is solicit. So exit the handle directly. So NUT don't send any Advertise message. if ((reply.ia_count == 0) && (reply.pd_count == 0)) { if (reply.packet->dhcpv6_msg_type != DHCPV6_INFORMATION_REQUEST) goto exit; ..skip.. }
Created attachment 449184 [details] first attempt Yes, you are right. Thanks for your effort ! So you see that lease_to_client() calls reply_process_ia_pd() which calls reply_process_prefix() which calls reply_process_try_prefix(). So I changed (the previous week; I have had no time for this problem since then) the reply_process_prefix() to return ISC_R_ADDRNOTAVAIL when there's no prefix available. When reply_process_ia_pd() discovers that reply_process_prefix() returned ISC_R_ADDRNOTAVAIL it puts an Status Code option with 'NoPrefixAvail' value into the Advertise packet. This was my first attempt (it was friday evening). I know it's not perfect yet. I'll continue investigate it when I find some more time. The patch is here only because you asked for it. I made this comment to this patch into spec file: # 1) When server has empty pool of addresses/prefixes it must send Advertise with NotAddrsAvail status in response to clients Solicit. # Without this patch server having empty pool of addresses/prefixes ignored client's' Solicit when client was also sending address in IA_NA or prefix in IA_PD as a preference. # 2) When client sends address in IA_NA as a preference and server doesn't have this address in any pool the server offers other free address. # Without this patch server ignored client's Solicit in which the client was sending prefix in IA_PD (as a preference) and this prefix was not in any of server's pools.
Hello ShanWei, sorry for the delay, seem like I get to this bug only on fridays evenings ;-) I improved the patch (it was correct but not complete) so I hope you can now pass the 11.3.1_E (and also 11.1.8) tests. Scratch-build is here: http://koji.fedoraproject.org/koji/taskinfo?taskID=2522510 I have this comment by the patch in spec file: When server has empty pool of addresses/prefixes it must send Advertise with NoAddrsAvail/NoPrefixAvail status in response to clients Solicit. Without this patch server having empty pool of addresses/prefixes ignored client's' Solicit when client was also sending address in IA_NA or prefix in IA_PD as a preference. But there's still one question regarding the Status Code option. RFC3315 (17.2.2) says that we MUST send (except for server/client DUID) *only* Status Code option in Advertise in this situation. RFC 3633 (11.2) says that we send an Advertise in the same way as described in 17.2.2 of RFC 3315 and we MUST send (except for server/client DUID) IA_PD with no prefixes and Status Code option (in the IA_PD) in Advertise. At the moment I send Status Code option in IA_PD and also another Status Code option (both with NoPrefixAvail) in Advertise.
(In reply to comment #6) > But there's still one question regarding the Status Code option. > RFC3315 (17.2.2) says that we MUST send (except for server/client DUID) *only* > Status Code option in Advertise in this situation. RFC 3633 (11.2) says that > we send an Advertise in the same way as described in 17.2.2 of RFC 3315 and > we MUST send (except for server/client DUID) IA_PD with no prefixes and > Status Code option (in the IA_PD) in Advertise. > At the moment I send Status Code option in IA_PD and also another > Status Code option (both with NoPrefixAvail) in Advertise. ShanWei, you can ignore this comment because I have just found the answer for my question in Errata to RFC-3315 http://www.rfc-editor.org/errata_search.php?rfc=3315 Errata ID: 2472 Status: Reported Type: Technical Reported By: Ole Troan Date Reported: 2010-08-17 Section 17.2.2 says: If the server will not assign any addresses to any IAs in a subsequent Request from the client, the server MUST send an Advertise message to the client that includes only a Status Code option with code NoAddrsAvail and a status message for the user, a Server Identifier option with the server's DUID, and a Client Identifier option with the client's DUID. It should say: If the server will not assign any addresses to an IA in a subsequent Request from the client, the server MUST send an Advertise message to the client that includes the IA containing a Status Code option with status code NoAddrsAvail and a status message for the user, a Server Identifier option with the server's DUID, and a Client Identifier option with the client's DUID. The server SHOULD include other stateful IA options (like IA_PD) and other configuration options in the Advertise message.
Created attachment 452928 [details] dump file for latest dhcp packet (In reply to comment #7) I have test the latest dhcp packet that you provided on comment #6 according to your reproduce steps. The result is very good, see the attachment. But I have a question about the Status Code option. In this case, the advertise message should includes which one of following. The advertise message in attached dump file is with format#1. But 11.2 section of rfc3633 takes format#3. So can you fix dhcp packet with format#3? 1. a) an IA_PD option(There is no IA_PD Prefix option in IA_PD option. There is Status Code option in IA_PD option.) b) an Status Code option format like this: ____________a________________________________b___________ | IA_PD option | Status Code option | | _____________________ | | | |Status Code | | |...... | | option | | | | |____________________| | | |_____________________________|__________________________| 2. a) an IA_PD option(There is no IA_PD Prefix option in IA_PD option. There is *no* Status Code option in IA_PD option.) b) an Status Code option format like this: ____________a________________________________b___________ | IA_PD option | Status Code option | | | | | | |...... | | | | | | |_____________________________|__________________________| 3. a) an IA_PD option(There is no IA_PD Prefix option in IA_PD option. There is Status Code option in IA_PD option.) #b) There is no an Status Code option near the IA_PD option. format like this: ____________a__________________ | IA_PD option | | _____________________ | | |Status Code | | | | option | | | |____________________| | |_____________________________|
Hi Jiri. The dhcp-4.1.1-26.P1 packet that you provided on comment #6 can't fix the bug. I make a patch against on the source of dhcp-4.1.1-26.P1. This patch is ok to me. Please review it. [root@(none) server]# diff -Nuarp dhcpv6-orig.c dhcpv6.c --- dhcpv6-orig.c 2010-10-13 07:41:46.368098708 -0400 +++ dhcpv6.c 2010-10-13 07:40:41.630094976 -0400 @@ -3766,7 +3766,7 @@ reply_process_try_prefix(struct reply_st struct iaddrcidrnet *pref) { isc_result_t status = ISC_R_NORESOURCES; struct ipv6_pool *pool; - int i; + int i, find_pd_pool = 0; struct data_string data_pref; if ((reply == NULL) || (reply->shared == NULL) || @@ -3789,11 +3789,14 @@ reply_process_try_prefix(struct reply_st for (i = 0 ; (pool = reply->shared->ipv6_pools[i]) != NULL ; i++) { if (pool->pool_type != D6O_IA_PD) continue; + find_pd_pool = 1; status = try_client_v6_prefix(&reply->lease, pool, &data_pref); if (status == ISC_R_SUCCESS) break; } + if (!find_pd_pool) + return ISC_R_ADDRNOTAVAIL; data_string_forget(&data_pref, MDL); /* Return just the most recent status... */
(In reply to comment #8) > The advertise message in attached dump file is with format#1. But 11.2 section > of rfc3633 takes format#3. I also think that format#3 is the correct one. But I'm not sure you don't need format#1 to pass 11.1.8 test. Let's try format format#3 and see. > So can you fix dhcp packet with format#3? Done (In reply to comment #9) > This patch is ok to me. Please review it. Thank you, but I think the same as does you patch can be done with this change: @@ -3766,7 +3766,7 @@ reply_process_try_prefix(struct reply_st struct iaddrcidrnet *pref) { - isc_result_t status = ISC_R_NORESOURCES; - isc_result_t status = ISC_R_ADDRNOTAVAIL; struct ipv6_pool *pool; Next time try to add some more info to the patch. Trust me that I know how difficult it is to describe to somebody else why you do the change when all you actually know is that the changed code is working for you. I made the above mentioned change and other scratch-build follows (hope it's the last). http://koji.fedoraproject.org/koji/taskinfo?taskID=2530400
(In reply to comment #10) > (In reply to comment #8) > > The advertise message in attached dump file is with format#1. But 11.2 section > > of rfc3633 takes format#3. > I also think that format#3 is the correct one. > But I'm not sure you don't need format#1 to pass 11.1.8 test. The case of 11.1.8 also expects to receive advertise message with format#3. So, the authors of TAHI have same thought with us. So, the test result is also PASS. > Let's try format format#3 and see. > > > So can you fix dhcp packet with format#3? > Done > > (In reply to comment #9) > > This patch is ok to me. Please review it. > Thank you, but I think the same as does you patch can be done with this change: > @@ -3766,7 +3766,7 @@ reply_process_try_prefix(struct reply_st > struct iaddrcidrnet *pref) { > - isc_result_t status = ISC_R_NORESOURCES; > - isc_result_t status = ISC_R_ADDRNOTAVAIL; > struct ipv6_pool *pool; > > Next time try to add some more info to the patch. > Trust me that I know how difficult it is to describe to somebody else > why you do the change when all you actually know is that the changed code is > working for you. If you need help, please tell me. I will tell you what i know. > I made the above mentioned change and other scratch-build follows (hope it's > the last). > http://koji.fedoraproject.org/koji/taskinfo?taskID=2530400 Great Job. With your packet, these case are all pass. Did you have plan to back-pot this patch(dhcp-4.1.1-P1-addrnotavail.patch) to other Fedora system including non-born Fedora14, Fedora15? Because we will use dhcpv6 on those Fedora system.
Commited http://pkgs.fedoraproject.org/gitweb/?p=dhcp.git;a=commitdiff;h=8d570191de2b3272950daa0aff51efe5c713a122 (In reply to comment #11) > Did you have plan to back-pot this patch(dhcp-4.1.1-P1-addrnotavail.patch) to > other Fedora system including non-born Fedora14, Fedora15? Back-porting means applying a change to an older version, e.g. from Fedora14 to Fedora13. In general: Changes done in one branch should (to avoid regressions) always be done also in all newer branches, so this change will be available in F13 and later (F14, rawhide).
dhcp-4.2.0-12.fc14 has been submitted as an update for Fedora 14. https://admin.fedoraproject.org/updates/dhcp-4.2.0-12.fc14
dhcp-4.1.1-26.P1.fc13 has been submitted as an update for Fedora 13. https://admin.fedoraproject.org/updates/dhcp-4.1.1-26.P1.fc13
dhcp-4.2.0-12.fc14 has been pushed to the Fedora 14 testing repository. If problems still persist, please make note of it in this bug report. If you want to test the update, you can install it with su -c 'yum --enablerepo=updates-testing update dhcp'. You can provide feedback for this update here: https://admin.fedoraproject.org/updates/dhcp-4.2.0-12.fc14
dhcp-4.2.0-12.fc14 has been pushed to the Fedora 14 stable repository. If problems still persist, please make note of it in this bug report.
dhcp-4.1.1-26.P1.fc13 has been pushed to the Fedora 13 stable repository. If problems still persist, please make note of it in this bug report.