1. As i understand responses is hardcoded(preset) to discover and request. DHCP-Message-Type = ... in config file is ignored, so i can't respond to RELEASE, INFORM, DECLINE. Always is NAK. Response to request also could be NAK, not always ACK. It is possible respond to request with NAK if change RLM_UPDATED to rejected or something like this. Would be nice if dhcp server check for DHCP-Message-Type is set. 2. in dhcp.c ... when checking for know packet type. (packet->data[242] >=8) should be > 8 so inform messages also be passed to proces. 3. I'd suggest #define DEFAUL_PACKET_SIZE (300), some clients refuse large packets silently. 4. couldn't find out why, but packet incoming from real ip addresses to broadcast are ignored. 0.0.0.0 -> 255.255.255.255 - processed, 10.1.0.3 -> 255.255.255.255 - ignored. Harlads
EvilEzh wrote:
1. As i understand responses is hardcoded(preset) to discover and request. DHCP-Message-Type = ... in config file is ignored,
It *should* pay attention to DHCP-Message-Type. If not, patches are welcome.
so i can't respond to RELEASE, INFORM, DECLINE. Always is NAK. Response to request also could be NAK, not always ACK. It is possible respond to request with NAK if change RLM_UPDATED to rejected or something like this. Would be nice if dhcp server check for DHCP-Message-Type is set.
That would be good, yes.
2. in dhcp.c ... when checking for know packet type. (packet->data[242]
=8) should be > 8 so inform messages also be passed to proces.
OK.
3. I'd suggest #define DEFAUL_PACKET_SIZE (300), some clients refuse large packets silently.
Yes. udhcp ignores packets > 300 bytes.
4. couldn't find out why, but packet incoming from real ip addresses to broadcast are ignored. 0.0.0.0 -> 255.255.255.255 - processed, 10.1.0.3 -> 255.255.255.255 - ignored.
I think it's a kernel thing. I'm at conferences all this week (yes, multiple), so I'll have less time for looking into these issues. Alan DeKok.
EvilEzh wrote:
1. As i understand responses is hardcoded(preset) to discover and request. DHCP-Message-Type = ... in config file is ignored,
It *should* pay attention to DHCP-Message-Type. If not, patches are welcome. i'm not strong with c programming and patching. So i can only suggest :( in dhcpd.c i think code: case: RLM_MODULE_UPDATED: there is some code that sets response type. maybe put before (if (req......) , some code that verify if DHCP-Message-Type from relay is set then request->replay->code = information from update relay ... otherwise as in code.
4. couldn't find out why, but packet incoming from real ip addresses to broadcast are ignored. 0.0.0.0 -> 255.255.255.255 - processed, 10.1.0.3 -> 255.255.255.255 - ignored.
I think it's a kernel thing.
btw .. i've idea, maybe problem is that eth1 client network is 10.10.1.0/24 . But i've ip address bind on this interface 10.2.0.15 (10.2.0.15/24). Will test.
EvilEzh wrote:
i'm not strong with c programming and patching. So i can only suggest :( in dhcpd.c i think code: case: RLM_MODULE_UPDATED: there is some code that sets response type.
Hmm... OK.
btw .. i've idea, maybe problem is that eth1 client network is 10.10.1.0/24 . But i've ip address bind on this interface 10.2.0.15 (10.2.0.15/24). Will test.
Well, yes. If the interface isn't reachable from 10.1.0.3, then the DHCP packets won't reach the interface. Alan DeKok.
Sorry, i don't know (havn't read maybe :) ) how to submit patches. I'll paste here First one ... allows receive DHCP-Inform messages. --- dhcp.c 2008-06-23 02:46:17.000000000 +0300 +++ dhcp_new.c 2008-06-23 02:45:26.000000000 +0300 @@ -190,7 +190,7 @@ if ((packet->data[240] != 53) || (packet->data[241] != 1) || (packet->data[242] == 0) || - (packet->data[242] >= 8)) { + (packet->data[242] > 8)) { fprintf(stderr, "Unknown, or badly formatted DHCP packet\n"); rad_free(&packet); return NULL; Second one ... patches for updating reply->code correctly depending on modules answer(last DHCP-Message-Type update will be in action). Actualy client must!!! supply in some update section DHCP-Message-Type. Otherwise i think no reply at all(not tested) :) . And i think there no need to respond with NAK in reject, fail and other cases (and DECLINE response is client side only). There is no need for that garbage traffic. If module fails then fails. NAK message to client will not help in this case :) Or maybe i don't want to respond at all (ignore) :) --- dhcpd.c 2008-06-23 02:38:57.000000000 +0300 +++ dhcpd_new.c 2008-06-23 02:43:19.000000000 +0300 @@ -46,17 +46,13 @@ switch (rcode) { case RLM_MODULE_OK: case RLM_MODULE_UPDATED: - if (request->packet->code == (PW_DHCP_DISCOVER)) { - request->reply->code = PW_DHCP_OFFER; - break; - - } else if (request->packet->code == PW_DHCP_REQUEST) { - request->reply->code = PW_DHCP_ACK; - break; - } - - /* FALL-THROUGH */ + vp = pairfind(request->reply->vps, DHCP2ATTR(53)); + if (vp) { + request->reply->code = vp->vp_integer + PW_DHCP_OFFSET; + break; + } + break; /* no DHCP-Message-Type in reply, maybe other modules will update.*/ default: case RLM_MODULE_REJECT: case RLM_MODULE_FAIL:
Another patch :) for dhcp.c updates to receive offer message and removes some garbage code (maybe it was here for testing ?). vp->vp_integer and packet->code - PW_DHCP_OFFSET always will be equal. with my dhcpd.c patch :) --- dhcp.c 2008-06-23 14:26:45.000000000 +0300 +++ dhcp_new.c 2008-06-23 14:30:01.000000000 +0300 @@ -190,7 +190,7 @@ if ((packet->data[240] != 53) || (packet->data[241] != 1) || (packet->data[242] == 0) || - (packet->data[242] >= 8)) { + (packet->data[242] > 8)) { fprintf(stderr, "Unknown, or badly formatted DHCP packet\n"); rad_free(&packet); return NULL; @@ -958,11 +958,6 @@ p = pp; } - vp = pairfind(packet->vps, DHCP2ATTR(53)); - if (vp && (vp->vp_integer != (packet->code - PW_DHCP_OFFSET))) { - fprintf(stderr, "Message-Type doesn't match! %d %d\n", - packet->code, vp->vp_integer); - } pairdelete(&packet->vps, DHCP2ATTR(0x35)); /*
Haralds Ulmanis wrote:
Another patch :) for dhcp.c updates to receive offer message and removes some garbage code (maybe it was here for testing ?). vp->vp_integer and packet->code - PW_DHCP_OFFSET always will be equal. with my dhcpd.c patch :)
Added, thanks. Alan DeKok.
Haralds Ulmanis wrote:
Second one ... patches for updating reply->code correctly depending on modules answer(last DHCP-Message-Type update will be in action). Actualy client must!!! supply in some update section DHCP-Message-Type. Otherwise i think no reply at all(not tested) :) .
The idea is that in *normal* circumstances, the server just Does the Right Thing. If it receives a discover, and the policy returns "ok", then the response should be an offer.
And i think there no need to respond with NAK in reject, fail and other cases (and DECLINE response is client side only). There is no need for that garbage traffic. If module fails then fails. NAK message to client will not help in this case :) Or maybe i don't want to respond at all (ignore) :)
In some cases, the server needs to send an explicit NAK, in order to force the client to re-broadcast a discover. I've committed a change that lets the policy set the message type. Alan DeKok.
In some cases, the server needs to send an explicit NAK, in order to force the client to re-broadcast a discover.
That's true, but i'll choose when send NAK and when not. Or not respond at all. Of course we can make some rfc check (discover->offer; request->ack,nak; and so on). Actualy i'm implementing it with jradius module :). Good that can work with option 82. And another good thing that i've some devices with java api, so i can directly control them togeather with dhcp server/radius auth. I've running it now for more than week in production. Everything now looks ok now. p.s. if I remember right there was some code which cheks for dhcp client "MSFT 98" there can also add code for "udhcp *" and before it was check for opcode ==3. opcode never will be 3 (1|2). Maybe this was for some testing and code isn't needed anymore.
EvilEzh wrote:
That's true, but i'll choose when send NAK and when not. Or not respond at all.
Yes. The code I committed allows that. It also allows the server to just to the right thing if you don't specify a message type.
Actualy i'm implementing it with jradius module :). Good that can work with option 82. And another good thing that i've some devices with java api, so i can directly control them togeather with dhcp server/radius auth.
That's the intent.
I've running it now for more than week in production. Everything now looks ok now.
Great!
p.s. if I remember right there was some code which cheks for dhcp client "MSFT 98" there can also add code for "udhcp *" and before it was check for opcode ==3. opcode never will be 3 (1|2). Maybe this was for some testing and code isn't needed anymore.
OK. I'll look into it. Alan DeKok.
participants (3)
-
Alan DeKok -
EvilEzh -
Haralds Ulmanis