Ignore DHCP for a group of MAC addresses?
-
I've just tested it and it works.
In your case, use
class "mitel" {
match if ( substring(hardware,0,4) = 01:08:00:0f );For your tests, you'll need to manually edit /var/dhcpd/etc/dhcpd.conf on the pfsense box, kill dhcpd and restart it from command-line. Note that the /var/dhcpd/ files are regenerated and overwritten on each reboot.
-
I went about this a slightly different way, that doesn't require manual killing/restarting dhcpd. I inserted the following clause right before the "{$custoptions}" line (~line 136) in /etc/inc/services.inc so this way it gets preserved even if I make changes via the GUI. Of course this won't survive an upgrade so I'll just have to remember to re-patch after any upgrades. Hopefully one day the GUI will have a box for easier customizing of dhcpd.conf …
class "mitel" {
match if binary-to-ascii(16,8,":",substring(hardware,0,4)) = "1:8:0:f";
ignore booting;
}Is my match string correct? I have seen some examples omit the whole binary-to-ascii conversion step but I was following the notes of Michael Lucas (who wrote a BSD book) at http://blather.michaelwlucas.com/archives/962
-
Okay, the above isn't working for me. I am not at the site to test hands on but my contact there said he rebooted a phone and it failed to boot. I checked the DHCP leases and I actually don't see any entries for the phone's MAC address (that's a good thing I suppose) so DHCPd isn't handing out an IP. But when I go to System Log it is overflowing (pages and pages) of
dhcpd: parse_option_buffer: malformed option vendor-class. <unknown>(code 1027): code tag at end of buffer - missing length field.
Any more ideas? Should I try to packet filter / firewall this so no traffic whatsoever from the phones ever reaches the pfSense box? (not sure how to even go about that)
EDIT: sorry, actually upon further inspection, I looked at the DHCP tab of Logs and I see that the daemon is actually handing out an IP – so my "ignore booting" is apparently not having the desired effect. See below:
dhcpd: DHCPNAK on 10.161.157.158 to 08:00:0f:53:b8:70 via em0
Feb 27 14:26:38 dhcpd: DHCPREQUEST for 10.161.157.158 (10.167.0.32) from 08:00:0f:53:b8:70 via em0: wrong network.</unknown> -
Well, as I mentioned in my previous post, the isc dhcpd method I suggested seems to work in my test setup. The logfile now includes a lines like DHCPDISCOVER from <excluded mac="" addr="">via em1: network 192.168.150.0/24: no free leases.
The ipfw L2 method should also work in theory, but I haven't tested it yet.</excluded>
-
Actually just looking again at this and it looks like the phone is getting a 10.161.157.158 address from somewhere (not my pfSense box for sure) so it appears maybe the "ignore booting" directive was working after all(?). But again not sure why the phone then sends a DHCPREQUEST for 10.161.157.158 to pfSense, perhaps that was the last IP it had cached in its memory so it's trying to reclaim it – which pfSense correctly responds "wrong network" to.
re: ipfw, I scoured the whole GUI and couldn't find anywhere to configure this-- is this going to be another hack via CLI? I saw some posts about the Captive Portal system making use of ipfw, do I need to enable Captive Portal first??
-
Have you considered asking pfsense's commercial support to add this feature ? Doing a little google-ing one finds out that it is not uncommon to want dhcpd to withhold leases to certain MAC addresses, especially in larger environments.
A case similar to yours can be found here :
The infrastructure department doesn't want to pre-configure the phones when they are delivered (which is very comprehensible, because they would have to administrate several thousands of them), so the phones don't know anything about a local configuration. Connecting the phones to a special "VLANned" port of the floor switch is not possible, either. The reason is that the phones contain a built-in switch which allows to connect computers to it to avoid that the phones "block" additional network wall sockets, as cables are rare in some office rooms.
So what they are doing is the following: The phones shout out an DHCP request. Our institute's DHCP (Mac OS X) should stay quiet and ignore it. The DHCP of the phone infrastructure department (which is present in every subnets of the institutes due to a special switch configuration) answers and does "AVA" (automatic VLAN assignment). That means: Their DHCP forces the telephones to go then into a special phone VLAN. The VLAN termination is then done in the phones (not in the floor switch), so a computer which is connected to the switch that is embedded into the phones won't be in the telephone VLAN, but stays in the institute's LAN.
-
I found a solution, I had to enable the directive
not authoritative;
What this does is stop dhcpd from sending DHCPNAK responses to the requesting device, allowing it to receive additional replies from the other server on the network.
I did this by editing /etc/inc/services.inc ~line 150:
$dhcpdconf .= "authoritative;\n"; → $dhcpdconf .= "not authoritative;\n";So far so good. :)
Would be wonderful to have an option to control this via the GUI. I see the include file already "supports" this because it has the following clause which queries the "disableauthoritative" variable:if(!isset($dhcpifconf['disableauthoritative']))
-
I hope a GUI option to control this flag might be added for pfSense 2.1
-
I'm running all ISC DHCP servers on Linux, including largest one - for ~500 hosts.
I never thought that this option:
not authoritative;
has that meaning.So there can be 2 or more DHCP servers running on same subnet? Doesn't it cause conflicts?
Since additional connected DHCP-enabled devices always caused problems I was about to ALLOW only authorized DHCP server on the network (by setting specific options on every switch)..I run it on Linux, since I can set every option separate for every host, for example: different gateways, different DNS servers, next-server for TFTP boot etc..
-
Just a quick heads-up that such a feature (http://redmine.pfsense.org/issues/2241) has been implemented.
Commits:
https://github.com/bsdperimeter/pfsense/commit/1f1a08c85b7e8ddc6473795534ed5422a2c5aaaf
https://github.com/bsdperimeter/pfsense/commit/80d30a83463f3ee8160bbd9b38cd2f2f510560d7 -
I would like to comment: Thank you for this patch! :), but… :( I am not sure the patch on issue #2241 does really address the problem I have outlined here. I see it adds a "MAC address control" area to the GUI of DHCP but it still doesn't seem to add a way to configure the "not authoritative" flag that is so crucial to this working. As far as I can tell, my manual edits to /etc/inc/services.inc would still be required. I added a comment to the issue to request again a checkbox for this.
-
this limits the toal # of devices that can ever connect to about 253. That's a deal breaker.
Just to address this (false) assumption based on the default configuration:
You can have 16,777,214 devices (assuming NAT - thats a /8 or Class A - 10.X.X.X). Nothing (other than lots of stuff including pfSense defaulting to class C, and usually 192.168.1.X (sometimes .0.X or .100.X) says you have to stick to a /24 subnet on NAT. I'm currently running a /22 (1022) and a /18 (16382) precisely because 253 became a problem. Other than learning a new subnet mask, and possibly gateway addresses, nothing to it. I also chose to shift to the class B space when doing this, but didn't feel I really needed 65534 spaces in any timeframe I could imagine, so I picked sizes that seemed likely to be (more than) adequate for the foreseeable future for my nets.
-
Just curious, on a /18 (that's pretty big :o ) how do you deal with broadcast traffic? That doesn't become a problem?? Also, yes I understand that using larger subnets allows for >253 devices but it still doesn't solve the problem of having to enter/manage hundreds of MAC addresses – which is not scalable. I still think adding some simple conf options to the DHCPd GUI page would quickly solve this issue. If I knew more about how to contribute to the project I would probably try to author this patch myself.
-
Data entry can be cut way back by using the https://pfsense/status_dhcp_leases.php page to automatically create the static mappings. I only had to type a few MAC addresses for devices that it was easier to do that for than to find and power up.
I'm using a /22 from the old Class B range myself, I logically divided stuff up into ranges just to make things easy to remember.
172.16.0.X = Servers
172.16.1.X = Wired workstations / devices
172.16.2.X = Wireless laptops / tablets
172.16.3.X = DHCP (usually vacant)With the equivalent of four Class C blocks I'm not having any issues with broadcasts or scanning looking for services.
-
If it actually had 16382 items on it, broadcast might (or might not - I'm not sure without trying it) be a bit of an issue - actual number of hosts on it now would fit in a /22, but it was enough of a pain re-addressing everything that I thought long and hard about how far it might grow, and then added a couple of bits to be safe. That net has a larger number of users, and more "personal devices" on it - when it was a /24, I ran out of DHCP addresses for 85 users when users started to have a computer, and a phone, and an iPod (or equivalent), and an iPad or other tablet, and an e-book-reader, and who knows what else all looking for an address. Not every user, but enough.
My crystal ball said go absurdly big, but still didn't think I needed to go all the way to a /16. If that one was a /22, I'd be getting close already. The one that's a /22 is an inherently smaller number of users, but I quadrupled it anyway when I had to re-address it for other reasons, as the other one showed me the writing on the wall. I'm pulling for IPv6 to finally deliver the promised land one of these days…
<edit>Similar to Stan, I use the increased address space to apply some logic to my addresses. I used to have that on a /24, but as things grew over 15 years it became harder to manage as the reserved addresses for this had to be used so that would fit. I have both "types of service" and physical location prefixes.</edit>
