[PATCH] udhcpc6: add support IETF RFC3315 section-19.1.2 retransmission strategy
Frank TEO
frank128 at ymail.com
Fri Sep 28 08:27:58 UTC 2012
Sorry, I got the RFC3315 section number wrong for client.
It should be section 14. But very much the same concept that timeout is double of previous one for retransmission as according to the patch.
Patch does not consider RAND.
RFC3315 Section 14
The client retransmission behavior is controlled and described by the following variables:
RT Retransmission timeout
IRT Initial retransmission time
MRC Maximum retransmission count
MRT Maximum retransmission time
MRD Maximum retransmission duration
RAND Randomization factor
RT for the first message transmission is based on IRT:
RT = IRT + RAND*IRT (Mean: first timeout is 1sec + RAND)
RT for each subsequent message transmission is based on the previous value of RT:
RT = 2*RTprev + RAND*RTprev (Mean: Subsequent is 2x of prev timeout + RAND)
if (RT > MRT)
RT = MRT + RAND*MRT (Mean: Upper bound of timeout is 30 sec, assume RAND=ZERO)
RFC3315 Section 18.1.1
The client transmits the message according to section 14, using the
following parameters:
IRT REQ_TIMEOUT
MRT REQ_MAX_RT
MRC REQ_MAX_RC
RFC3315 Section 5.5
REQ_TIMEOUT 1 sec Initial Request timeout
REQ_MAX_RT 30 secs Max Request timeout value
REQ_MAX_RC 10 Max Request retry attempts
----- Original Message -----
From: Frank TEO <frank128 at ymail.com>
To: "busybox at busybox.net" <busybox at busybox.net>
Cc:
Sent: Friday, 28 September 2012, 15:22
Subject: [PATCH] udhcpc6: add support IETF RFC3315 section-19.1.2 retransmission strategy
IETF RFC3315 section-19.1.2 Time Out and Retransmission said
If the server does not receive a Renew or Information-request message
from the client in REC_TIMEOUT milliseconds, the server retransmits
the Reconfigure message, doubles the REC_TIMEOUT value and waits
again. The server continues this process until REC_MAX_RC
unsuccessful attempts have been made, at which point the server
SHOULD abort the reconfigure process for that client.
Where
REC_TIMEOUT 2 secs Initial Reconfigure timeout
REC_MAX_RC 8 Max Reconfigure attempts
udhcpc6 option to be use : -T 2 -t 8
It is up to user to decide abort or tryagain timeout after REC_MAX_RC attempt.
The attached busybox-udhcpc6-rfc3315-section-19-1-2.patch is patch without
applying discover_retries == 0 (infinite) patch 1c7a58dfb82ea04c525e0c19f94f2d800dee99e3.
I believe "discover_retries == 0 (infinite) patch" cannot reset "packet_num = 0;" which is required by this patch.
Since I am using -t greater than 0, so I am not affected.
diff -Naupr busybox-orig/networking/udhcp/d6_dhcpc.c busybox-new/networking/udhcp/d6_dhcpc.c
--- busybox-orig/networking/udhcp/d6_dhcpc.c 2012-08-16 22:52:27.000000000 +0800
+++ busybox-new/networking/udhcp/d6_dhcpc.c 2012-08-23 14:58:29.894235000 +0800
@@ -1116,7 +1116,7 @@ int udhcpc6_main(int argc UNUSED_PARAM,
xid = random_xid();
/* multicast */
send_d6_discover(xid, requested_ipv6);
- timeout = discover_timeout;
+ timeout = discover_timeout << packet_num;
packet_num++;
continue;
}
@@ -1143,7 +1143,7 @@ int udhcpc6_main(int argc UNUSED_PARAM,
if (packet_num < discover_retries) {
/* send multicast select packet */
send_d6_select(xid);
- timeout = discover_timeout;
+ timeout = discover_timeout << packet_num;
packet_num++;
continue;
}
http://lists.busybox.net/mailman/listinfo/busybox
More information about the busybox
mailing list