Hi,
I stumbled upon a dhcp server problem with OpenBSD 4.6 dhcp server:
Whenever a client tries to renew its lease and the dhcp server agrees,
an ACK is returned to the client that contains option 54 (Server Id)
if the client had this option present in the renew request.
If for whatever reason, the server sees a conflict and NAK's the
clients' renew request, it doesn't return the option 54 when it was
present in the renew request.
Now according to RFC 2132 thats ok: "This option is used in DHCPOFFER
and DHCPREQUEST messages, and may
optionally be included in the DHCPACK and DHCPNAK messages"
But when using it in relation with a dhcp relay proxy setup for
subscriber management, the NAK gets dropped instead of forwarded due
to a check if the options provided from the server matches the ones
from the renew request.
Another way to look at it is that IMHO the behavior regarding the
option in question should be equal if the server response is an ACK or
a NAK. Or do I miss here something? Shall I open a bug for it?
A possible patch that copies the received server id, if present, is this:
--- dhcp.c.orig Tue Jan 26 08:05:24 2010
+++ dhcp.c Thu Jan 28 05:45:02 2010
@@ -575,6 +575,23 @@
options[DHO_DHCP_MESSAGE]->timeout = -1;
options[DHO_DHCP_MESSAGE]->tree = NULL;
+ /* If we were given Server Id with the RENEW request,
+ respond also with it. Its done for NAK as well and
+ at least one routing hardware vendor depends on it
+ when using dhcp relay proxy mode
+ */
+ if (packet->options[DHO_DHCP_SERVER_IDENTIFIER].len) {
+ /* Set SERVER_IDENTIFIER */
+ options[DHO_DHCP_SERVER_IDENTIFIER] = &dhcpmsg_tree;
+/* options[DHO_DHCP_MESSAGE]->value =
packet->options[DHO_DHCP_SERVER_IDENTIFIER]->value; */
+
bcopy(packet->options[DHO_DHCP_SERVER_IDENTIFIER].data,
options[DHO_DHCP_SERVER_IDENTIFIER]->value,
+ packet->options[DHO_DHCP_SERVER_IDENTIFIER].len);
+ options[DHO_DHCP_SERVER_IDENTIFIER]->len =
packet->options[DHO_DHCP_SERVER_IDENTIFIER].len;
+ options[DHO_DHCP_SERVER_IDENTIFIER]->buf_size =
packet->options[DHO_DHCP_SERVER_IDENTIFIER].len;
+ options[DHO_DHCP_SERVER_IDENTIFIER]->timeout = -1;
+ options[DHO_DHCP_SERVER_IDENTIFIER]->tree = NULL;
+ }
+
/* Do not use the client's requested parameter list. */
i = DHO_DHCP_PARAMETER_REQUEST_LIST;
if (packet->options[i].data) {
This patch actually solved the problem I dealt with but certainly
needs a clean rewrite I guess ;-)
many thanks
Marcel
