This service will be undergoing maintenance at 00:00 UTC, 2016-08-01. It is expected to last about 1 hours
Bug 634842 - dhcpd can't send advertise message when there is no prefix avail
dhcpd can't send advertise message when there is no prefix avail
Status: CLOSED ERRATA
Product: Fedora
Classification: Fedora
Component: dhcp (Show other bugs)
13
All Linux
medium Severity medium
: ---
: ---
Assigned To: Jiri Popelka
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2010-09-17 03:17 EDT by ShanWei
Modified: 2010-11-01 16:48 EDT (History)
1 user (show)

See Also:
Fixed In Version: dhcp-4.1.1-26.P1.fc13
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2010-11-01 16:48:27 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)
first attempt (2.51 KB, patch)
2010-09-23 07:13 EDT, Jiri Popelka
no flags Details | Diff
dump file for latest dhcp packet (4.92 KB, application/octet-stream)
2010-10-12 06:04 EDT, ShanWei
no flags Details

  None (edit)
Description ShanWei 2010-09-17 03:17:43 EDT
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.
Comment 1 Jiri Popelka 2010-09-17 06:00:44 EDT
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
Comment 2 Jiri Popelka 2010-09-17 09:02:08 EDT
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).
Comment 3 Jiri Popelka 2010-09-17 13:15:03 EDT
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
Comment 4 ShanWei 2010-09-23 06:36:41 EDT
(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..
	}
Comment 5 Jiri Popelka 2010-09-23 07:13:33 EDT
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.
Comment 6 Jiri Popelka 2010-10-08 12:31:12 EDT
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.
Comment 7 Jiri Popelka 2010-10-11 07:02:48 EDT
(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.
Comment 8 ShanWei 2010-10-12 06:04:21 EDT
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             |   | 
|    |____________________|   |
|_____________________________|
Comment 9 ShanWei 2010-10-12 07:35:55 EDT
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... */
Comment 10 Jiri Popelka 2010-10-12 11:56:51 EDT
(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
Comment 11 ShanWei 2010-10-13 01:38:46 EDT
(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.
Comment 12 Jiri Popelka 2010-10-13 06:55:09 EDT
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).
Comment 13 Fedora Update System 2010-10-13 07:11:10 EDT
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
Comment 14 Fedora Update System 2010-10-13 07:20:07 EDT
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
Comment 15 Fedora Update System 2010-10-13 17:21:46 EDT
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
Comment 16 Fedora Update System 2010-11-01 16:48:07 EDT
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.
Comment 17 Fedora Update System 2010-11-01 16:48:51 EDT
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.

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