On Tuesday 31 May 2011 17:37, Nigel Hathaway wrote:
> Package: busybox
> Version: v1.18.4
> Severity: low
>
> This patch applies on top of my previous VLAN and numeric DHCP option
> recognition patch.
>
> Whist this previous patch allows you to have DHCP options that are unknown to
> Busybox to be passed numerically to the udhcpc script, I found that there was
> no way of actually adding them to the list of requested options passed to the
> DHCP server. This rectifies this in that you can now request DHCP options by
> number. For example:
>
> udhcpc -O43
>
> This adds option 43 (vendor specific information) to the set of requested
> options.
+ uint8_t opt_remainder_mask[256 / 8];
udhcp_add_simple_option(packet, DHCP_MAX_SIZE, htons(IP_UDP_DHCP_SIZE));
@@ -398,6 +399,7 @@
* from stubborn DHCP servers. Pull the data from the struct in
common.c.
* No bounds checking because it goes towards the head of the packet. */
end = udhcp_end_option(packet->options);
+ memcpy(opt_remainder_mask, client_config.opt_mask,
sizeof(opt_remainder_mask));
len = 0;
for (i = 0; (c = dhcp_optflags[i].code) != 0; i++) {
if (( (dhcp_optflags[i].flags & OPTION_REQ)
@@ -406,9 +408,16 @@
|| (client_config.opt_mask[c >> 3] & (1 << (c & 7)))
) {
packet->options[end + OPT_DATA + len] = c;
+ opt_remainder_mask[c >> 3] &= ~(1 << (c & 7));
len++;
}
}
+ for (c = 1; c < 254; c++) {
+ if (opt_remainder_mask[c >> 3] & (1 << (c & 7))) {
+ packet->options[end + OPT_DATA + len] = c;
+ len++;
+ }
+ }
Why do you need opt_remainder_mask[]?
Why existing code, which uses client_config.opt_mask[],
can't be used to track unknown options too?
--
vda
_______________________________________________
busybox mailing list
[email protected]
http://lists.busybox.net/mailman/listinfo/busybox
