DHCPd with multiple ipv4 subnets outside of local interface network. (300US$)

marcelloc

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.

haddock

@bennyc:

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?

shade

@marcelloc:

The sub-pools next-server is taking more time that I expected to change.

A simple reply to my PM would have been nice ;)

@marcelloc:

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.

shade

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";
}
}

haddock

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?

haddock

@marcelloc:

@haddock:

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.

bennyc

@haddock:

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...)

bennyc

for those following the bounty, got word from Marcelloc who tried another merge.
Seems not accepted yet though… ???

haddock

@bennyc:

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?

marcelloc

@haddock:

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

WriteMem

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?

doktornotor

@WriteMem:

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.

:(

bennyc

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 --

bennyc

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/1406

Confused now. So it is still ongoing business? (hoping I'm right :) )

pedymaster

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.

doktornotor

Those patches no longer apply. It'd need to be done yet again.

haddock

@doktornotor:

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.

bennyc

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 ::)

bennyc

update: the latest version of the patch breaks IPSec. You'll end up with a nice error when you try to enable IPSec:```
Fatal error: Call to undefined function gen_subnetv4() in /etc/inc/vpn.inc


This is due to the modified util.inc, where the part gen_subnetv4() is missing in total. Haven't had this error earlier on previous ipsec activations, suspecting it originates or in the latest version of Marcello's patch (post pfSense2.2) or with StrongSwan implementation of IPSEC. (Racoon worked fine)

So now I have to decide on either have the good working dhcpd (which I need), or the IPSec (which I need)

why o why me  >:(

doktornotor

As already noted, that patch is (yet again) no longer applicable and I very much doubt marcelloc will bother with rewriting it for the zillionth time. The developers probably absolutely hate the idea of using pfSense as a DHCP server. Never seen such retarded handling of a contributed no-brainer feature.