DHCPd with multiple ipv4 subnets outside of local interface network. (300US$)
-
Testing this further, I have found an implemented feature that is not working correctly and had me spooked for a while until I figured it out.
From testing it affects DNS server / Domain name / Domain search list, including hosts with static dhcp leases, but could be more settings affected. I think it's the global definitions in dhcpd.conf that is the culprit.
option domain-name-servers
option domain-name
option domain-searchIt's pretty confusing to explain the issues but here goes, I think it will be easier if I make an example.
Let's say that the pfsense hostname under System –> General setup is:
hostname: pfsense
domain: mycorp.officeThis will then generate a global definition on the top row in /var/dhcpd/etc/dhcpd.conf as:
option domain-name "mycorp.office";
So far so good.
Now let's say we want to user different domain-name / search domain / dns for our other subnets.
We start with configuring the subnet that is locally connected to pfsense (default subnet for the LAN interface), not adding any additional pool yet.
Services --> DHCP Server --> LAN
We leave this at default settings.
That would look something like this in dhcpd.conf
subnet 192.168.1.0 netmask 255.255.255.0 {
pool {
range 192.168.1.50 192.168.1.250;
}option routers 192.168.1.1;
option domain-name-servers 192.168.1.1;Ok, no problem with this.
Then we define another subnet 192.168.2.0/24
In this subnet we will not be using pfsense as DNS resolver, so we change some settings, dns server, domain name, domain search list.
Then the following config gets generated in dhcpd.conf, as you can see option domain-name-servers get defined twice, I dont know if that is really an issue, but at least its not best practice ;)
subnet 192.168.2.0 netmask 255.255.255.0 {
pool {
option domain-name-servers 10.45.0.10,10.45.0.11;
option routers 192.168.2.1;
option domain-name "mycorp.south";
option domain-search "mycorp.south";
option domain-name-servers 10.45.0.10,10.45.0.11;
option netbios-name-servers 10.45.0.10,10.45.0.11;
option netbios-node-type 8;
range 192.168.50 192.168.2.250;
}Now, let's say we want to add a client with static dhcp from 192.168.2.0 subnet, and we dont add anything extra to that static config.
host s_lan_0 {
hardware ethernet 11:22:33:44:55;
fixed-address 192.168.2.5;
option host-name "testing";Now problems arise, this client will now get all the "global config" defined from the 192.168.1.0 subnet, it will not get dns, gateway etc. defined in the 2.0 subnet.
Also, which is what I think is the major issue here, is that the dhcpd.conf static host stanza is entered under the 192.168.1.0 subnet. Like this:
subnet 192.168.1.0 netmask 255.255.255.0 {
pool {
range 192.168.1.50 192.168.1.250;
}option routers 192.168.1.1;
option domain-name-servers 192.168.1.1;
}
host s_lan_0 {
hardware ethernet 11:22:33:44:55;
fixed-address 192.168.2.5;
option host-name "testing";I think proper config would be to place static clients after the subnet statement's. so 192.168.2.0 static hosts will have to be defined after the:
subnet 192.168.2.0 netmask 255.255.255.0 {
pool { …
}I'm sure this will sound confusing, it was even somewhat confusing writing it down, but I hope you get the picture of the problem.
Let me know if you want something explained further.
Seeing shade's post above I think my issue is the same as his:
"- Marcelloc: I reported a bug in the patch back in Feb, and not even a answer from you, therefore is in public: The "Enable network booting" options next-server and filename are not working for sub-pools, only the "head" interface have these setting written to config."
-
- Marcelloc: I reported a bug in the patch back in Feb, and not even a answer from you, therefore is in public: The "Enable network booting" options next-server and filename are not working for sub-pools, only the "head" interface have these setting written to config.
As I told you, I've pushed two times the patch to 2.1 branch but it was not merged.
I will try again to 2.2 but 2.1 accepts only patches.
The sub-pools next-server is taking more time that I expected to change.
The be honest, the parcial bounty was the main reason to it not get finished until today but I'm still working on it. Sorry for the looong delay to finish it.
-
Testing this further, I have found an implemented feature that is not working correctly and had me spooked for a while until I figured it out.
I'll test it too. Thanks for the feedback.
The main issue to get all this working together is the zones main loop on php code.
-
Hi Marcelloc,
I know it's already been a while, but I think I encountered a couple of things we missed.
Sub-pools work fine… but when adding a static mapping for a client in a sub-pool, it does not hand out WINS/DNS: not the default, not the ones I put there. (not so good ::) )
It also doesn't complain if I use an ip within the pool range? (can live with that)
When removing the static mapping (but leaving it in the sub-pool), the dhcp deamon hands out both fine.So the issue is on the static mapping creation. (writing to the dhcpd.conf to be more precise, at least I think it is)
When looking to the dhcpd.conf, it gets written correctly except for the option "domain-name-server", that part is missing even if I update it in the static mapping (it does not add it to the part "host s_lan_0":
(partial code)
host s_lan_0 { hardware ethernet 00:50:56:ad:6f:c1; fixed-address 192.168.9.11; option host-name "REMOTE-7"; option routers 192.168.9.254; } subnet 192.168.9.0 netmask 255.255.255.0 { pool { option domain-name-servers 192.168.1.254; option routers 192.168.9.254; range 192.168.9.1 192.168.9.10; }Went through the code from services_dhcp.php (quickly) as I suspect the issue is there (might be wrong), but it seems my coding knowledge is still too limited, can't point it out yet :-[
Can you still check this please?
tnx & br, Benny.
[/quote]This also seems related to the problems I am experiencing, especially this one:
"but when adding a static mapping for a client in a sub-pool, it does not hand out WINS/DNS: not the default, not the ones I put there. (not so good ::) )"
Marcello, how much time would you say it would take for you to solve the issues?
-
The sub-pools next-server is taking more time that I expected to change.
A simple reply to my PM would have been nice ;)
The be honest, the parcial bounty was the main reason to it not get finished until today but I'm still working on it. Sorry for the looong delay to finish it.
I understand.. I was/am very disappointed by the bounty starter just taking the code and running, and screwing us all over like that. But I paided my part of $500 and would like to have the bug fixed, and it would also be nice to be able to update and still could apply the patch.
-
marcelloc: Don't know if it helps, but I made a little "hack" to get the net boot wokring.. it is ugly but it does the trick.
The change is made in services.inc, like this:
@@ -673,13 +673,13 @@
// net boot information
if(isset($poolconf['netboot'])) {
- if (!empty($poolconf['nextserver']) && ($poolconf['nextserver'] != $dhcpifconf['nextserver'])) {
+ if (!empty($poolconf['nextserver'])) {
$pool_dhcpconf .= " next-server {$poolconf['nextserver']};\n";
}
- if (!empty($poolconf['filename']) && ($poolconf['filename'] != $dhcpifconf['filename'])) {
+ if (!empty($poolconf['filename'])) {
$pool_dhcpconf .= " filename "{$poolconf['filename']}";\n";
}
- if (!empty($poolconf['rootpath']) && ($poolconf['rootpath'] != $dhcpifconf['rootpath'])) {
+ if (!empty($poolconf['rootpath'])) {
$pool_dhcpconf .= " option root-path "{$poolconf['rootpath']}";\n";
}
} -
Just wondering if the dhcp conf issues are actually being worked on?
Why are people complaining on the OP not paying up when the bounty isn't completed?
-
Testing this further, I have found an implemented feature that is not working correctly and had me spooked for a while until I figured it out.
I'll test it too. Thanks for the feedback.
The main issue to get all this working together is the zones main loop on php code.
Did you manage to test it further?
Also if you could hint if you are going to put more work into this or not would be appreciated.
-
Why are people complaining on the OP not paying up when the bounty isn't completed?
It was to my understanding there is some rule on it. And the rule was there way before the bounty was started. See
Bounty board rules and guidelines - READ FIRST BEFORE STARTING A BOUNTY
https://forum.pfsense.org/index.php?topic=6948.0
Last edited, new policy of requiring money up front. Sorry but we have been burned too many times now.@Marcello, could you update the bounty if and when you will continue work on it? Most important to me now is merge in 2.2, even with it's limitations. (I just installed the 2.2RC, and seems not to be in it)
If it turns out as a not future proven or supported solution, I would like to know so I can look at alternatives… (It would be a real pitty because it has worked with 0 issues, but I just want to plan ahead...) -
for those following the bounty, got word from Marcelloc who tried another merge.
Seems not accepted yet though… ??? -
for those following the bounty, got word from Marcelloc who tried another merge.
Seems not accepted yet though… ???Has there been any update to the bountycode?
I'm thinking of updating to 2.2, but don't know if this will work.
Has anyone tried? Is it compatible with Unbound?
-
Has there been any update to the bountycode?
I've sent again a pull request to pfSense team before 2.2Release. Maybe it get merged to 2.3
-
I have been reading this with interest, and checked the updates on the repository https://github.com/pfsense/pfsense/pull/816
Have you had a chance to resubmit Marcelloc?
-
I have been reading this with interest, and checked the updates on the repository https://github.com/pfsense/pfsense/pull/816
Have you had a chance to resubmit Marcelloc?
While I cannot speak for marcelloc, let me note this: when you let something rot for ages and then close the pull req with "oh shit, it no longer applies" half year later, you generally do not get the contributor excited. When you do it twice in a row, getting the guy pissed off is almost guaranteed.
I find closing the pull request with "Patch has conflicts and cannot be merged." rather insulting, to put it mildly. No shit Sherlock, you've been sitting on it for 1,5 years. Now, do the legwork yourself, since it's your damned fault.
:(
-
Bummer. So back to square one ::)
I'm finding it difficult to understand why it isn't present as a standard functionality, and also why it seems difficult to get it integrated.
Marcello, anything we (I) can do in helping to get this code ported to whatever version is needed? Seriously. I'm willing to spend some time on it.
– yes... edited own post... It had no added value in its original state :-X --
-
Took me a while to find some time to check this out in depth, and found another "open" merge request:
https://github.com/pfsense/pfsense/pull/1406Confused now. So it is still ongoing business? (hoping I'm right :) )
-
Hi,
Iam also watching the pull request and am interested in any news regarding this. I just hope, this work will not go to waste. -
Those patches no longer apply. It'd need to be done yet again.
-
Those patches no longer apply. It'd need to be done yet again.
Jeez! Again, really? :o
I feel bad for Marcelloc.
How many times must he redo the same thing because of core team not merging?
Does anyone know why pfsense coreteam are so reluctant to merge this request?
I mean, its a really nice feature that only makes pfsense a better and more competetive product.
-
Last version I got from Marcello works on 2.2.4.
Not sure what the problem is or why it is difficult to merge.
I too feel bad for the guy, 3 or 4 attempts, lost count in meantime ::)
