[prev in list] [next in list] [prev in thread] [next in thread]
List: busybox
Subject: /networking/udhcp/dhcpc.c is not comletely RFC-3442 complaint
From: Mustafa Albayati <Mustafa.Albayati () axis ! com>
Date: 2023-10-06 8:34:14
Message-ID: PAVPR02MB9746904D102B2CF25FC28919EAC9A () PAVPR02MB9746 ! eurprd02 ! prod ! outlook ! com
[Download RAW message or body]
[Attachment #2 (multipart/alternative)]
package: busybox
version: 1.36.1
Busybox DHCP client is RFC-3442 (option 121) compliant according to the doc=
umentations. However, it's stated under section "DHCP Client Behavior" that
"
DHCP clients that support this option and send a parameter request
list MAY also request the Static Routes option, for compatibility
with older servers that don't support Classless Static Routes. The
Classless Static Routes option code MUST appear in the parameter
request list prior to both the Router option code and the Static
Routes option code, if present.
"This requirement is currently not fulfilled. Instead, the "add_client_opti=
ons" function pulls the options from the struct in common.c, in the same or=
der as they are defined. Placing option 121 further down. The patch attache=
d to this email solves this issue by modifying the placement of the option =
while generating the request section in the "add_client_options" function. =
As this ordering requirement is only true when option 121 is selected, I ch=
oose to not modify the order in the struct. Aside from the risk of breaking=
other functionality.
[Attachment #5 (text/html)]
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1">
<style type="text/css" style="display:none;"> P {margin-top:0;margin-bottom:0;} \
</style> </head>
<body dir="ltr">
<div style="font-family: Calibri, Arial, Helvetica, sans-serif; font-size: 12pt; \
color: rgb(0, 0, 0);" class="elementToProof"> <div class="x_x_elementToProof \
x_x_ContentPasted0 x_ContentPasted0 ContentPasted0" data-ogsc="rgb(0, 0, 0)" \
style="font-size: 12pt; color: rgb(0, 0, 0);">
package: busybox<br class="ContentPasted0">
version: 1.36.1</div>
<div class="x_x_elementToProof x_x_ContentPasted0" data-ogsc="rgb(0, 0, 0)" \
style="font-size: 12pt; color: rgb(0, 0, 0);"> <br class="x_ContentPasted0 \
ContentPasted0"> </div>
<div class="x_x_elementToProof x_x_ContentPasted0 x_x_ContentPasted1 x_ContentPasted0 \
ContentPasted0" data-ogsc="rgb(0, 0, 0)" style="font-size: 12pt; color: rgb(0, 0, \
0);"> Busybox DHCP client is RFC-3442 (option 121) compliant according to the \
documentations. However, it's stated under section "DHCP Client Behavior" \
that</div> <div class="x_x_elementToProof x_x_ContentPasted0 x_x_ContentPasted1" \
data-ogsc="rgb(0, 0, 0)" style="font-size: 12pt; color: rgb(0, 0, 0);"> <br \
class="x_ContentPasted0 ContentPasted0"> </div>
<div class="x_x_elementToProof x_x_ContentPasted0 x_x_ContentPasted1 x_ContentPasted0 \
ContentPasted0" data-ogsc="rgb(0, 0, 0)" style="font-size: 12pt; color: rgb(0, 0, \
0);"> "</div>
<div class="x_x_elementToProof x_x_ContentPasted0 x_x_ContentPasted1 \
x_x_ContentPasted2 x_ContentPasted0 ContentPasted0" data-ogsc="rgb(0, 0, 0)" \
style="font-size: 12pt; color: rgb(0, 0, 0);"> DHCP clients that support this \
option and send a parameter request <div class="x_x_ContentPasted2 x_ContentPasted0 \
ContentPasted0" data-ogsc=""> list MAY also request the Static Routes \
option, for compatibility</div> <div class="x_x_ContentPasted2 x_ContentPasted0 \
ContentPasted0" data-ogsc=""> with older servers that don't support \
Classless Static Routes. The</div> <div class="x_x_ContentPasted2 \
x_ContentPasted0 ContentPasted0" data-ogsc=""> Classless Static Routes \
option code MUST appear in the parameter</div> <div class="x_x_ContentPasted2 \
x_ContentPasted0 ContentPasted0" data-ogsc=""> request list prior to both \
the Router option code and the Static</div> Routes option code, if \
present.</div> <span class="x_x_elementToProof x_x_ContentPasted0 x_x_ContentPasted1 \
x_x_ContentPasted2 x_ContentPasted0 ContentPasted0" data-ogsc="rgb(0, 0, 0)" \
style="font-size: 12pt; color: rgb(0, 0, 0);">"</span><span \
class="x_x_elementToProof x_x_ContentPasted0 x_x_ContentPasted1 x_x_ContentPasted2 \
x_x_ContentPasted3 x_x_ContentPasted4 x_x_ContentPasted5 x_ContentPasted0 \
ContentPasted0" data-ogsc="rgb(0, 0, 0)" style="font-size: 12pt; color: rgb(0, 0, \
0);">This requirement is currently not fulfilled. Instead, the \
"add_client_options" function pulls the options from the struct in \
common.c, in the same order as they are defined. Placing option 121 further down. The \
patch attached to this email solves this issue by modifying the placement of \
the option while generating the request section in the "add_client_options" \
function. As this ordering requirement is only true when option 121 is selected, I \
choose to not modify the order in the struct. Aside from the risk of breaking other \
functionality.</span><br> </div>
</body>
</html>
["rfc3442-compliant-option-list-ordering.patch" (text/x-patch)]
diff --git a/networking/udhcp/dhcpc.c b/networking/udhcp/dhcpc.c
index c757fb37c..9bc0039bf 100644
--- a/networking/udhcp/dhcpc.c
+++ b/networking/udhcp/dhcpc.c
@@ -627,8 +627,20 @@ static void add_client_options(struct dhcp_packet *packet)
* No bounds checking because it goes towards the head of the packet. */
end = udhcp_end_option(packet->options);
len = 0;
+ /* If option 121 requested. Place it before option 3 and 33 in parameter
+ * request list in accordance with RFC-3442 */
for (i = 1; i < DHCP_END; i++) {
+ if (i == 121) {
+ /* Skipping 121 as it's placed before option 3 (when i == 3) */
+ continue;
+ }
if (client_data.opt_mask[i >> 3] & (1 << (i & 7))) {
+ if (i == 3) {
+ if (client_data.opt_mask[121 >> 3] & (1 << (121 & 7))) {
+ packet->options[end + OPT_DATA + len] = 121;
+ len++;
+ }
+ }
packet->options[end + OPT_DATA + len] = i;
len++;
}
_______________________________________________
busybox mailing list
busybox@busybox.net
http://lists.busybox.net/mailman/listinfo/busybox
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic