There is no decent way to use the option 'unknown clients' in IPFire. It is, however, very useful. And it's a normal feature in dhcpd; it just isn't possible to use it in IPFire. See also http://forum.ipfire.org/viewtopic.php?f=50&t=11431 for example. Please add a possibility to use this option, per individual dhcp scope.
Created attachment 716 [details] dhcp.cgi with unknown-clients extension Es wurde eine zusätzliche Checkbox in der dhcp.cgi eingeführt, die bei Bedarf die Option "deny unknown-clients" einfügt.
https://wiki.ipfire.org/devel/submit-patches *** This bug has been marked as a duplicate of bug 10788 ***
dhcp.cgi with unknown-clients extension Additional checkbox added in dhcp.cgi (see attachment). A simple click will add option "deny unknown-clients" to dhcp.conf
Is this bug still valid? Please provide a link to a repository commit when setting things on MODIFIED.
As discribed in the thread, the bug is still alive. I found a solution, that is working fine for me. Since I'm not a developer I'm not able to verify if my modified dhcp-cgi is a vaild solution, which may be usable for everyone. So someone has to check this, and to build a acceptable patch ...
Created attachment 800 [details] Modified dhcp.cgi file to include deny unknown or deny known clients
Could you please submit all patches to the mailing list?
I took Henning's file as a starting point. The deny/allow unknown-clients commands when used in a global scope, directly within the subnet, are deprecated. The recommendation is to use the allow/deny unknown-clients/known-clients commands with a pool declaration. IPFire uses a single set of options etc per subnet and so does not need to use a pool declaration but it can be added. This is what I have done to the file, together with making the selection a radio button set to allow inclusion of deny known-clients to meet the requirements of Garp in his original bug submission. The file now offers:- allow all clients deny unknown-clients deny known-clients The allow all clients option gives the same setup as currently and is the default setting for the radio button set. I have tested this out in my IPFire virtual test bed setup and it worked as I expected. It would be useful if Henning and/or Garp can evaluate the modified file to see if it addresses the cause of this bug as they highlighted it. If that feedback is positive then I will create and submit a patch for it.
Hi Michael, This is not yet a patch but just a modified version of the dhcp.cgi file which I would like to get the feedback of Henning and/or Garp on to ensure that what I have created actually addresses what they saw as the issue. My plan was to create and submit a patch if I got that positive feedback.
(In reply to Adolf Belka from comment #9) > My plan was to create and submit a patch if I got that positive feedback. Okay. Thank you.
Sorry, we are on the way to leave the ipfire world, because Michael was blocking to add WireGuard support in the past. So there is no more time left to spend for tests with ipfire.
(In reply to Henning Ryll from comment #11) > Sorry, we are on the way to leave the ipfire world, because Michael was > blocking to add WireGuard support in the past. This is incorrect. I have posted my personal opinion on WireGuard here, in very much detail: > https://blog.ipfire.org/post/why-not-wireguard I didn't say that IPFire won't have it. I just stated why I think it is a very bad idea to use it. I hope this post is not misunderstood. > So there is no more time left to spend for tests with ipfire. @Adolf: Will you send it to the mailing list so that people are aware and we can find some other testers?
Testing feedback from Matthias Fischer:- Hi, Tested - sorry, didn't work - 'dhcp' wouldn't start. Perhaps my fault. I have suspected something like this for my machine. /var/log/messages tells me: ... Nov 14 16:36:27 ipfire dhcpd: /etc/dhcp/dhcpd.conf line 16: Pool declaration with no address range. Nov 14 16:36:27 ipfire dhcpd: } Nov 14 16:36:27 ipfire dhcpd: ^ Nov 14 16:36:27 ipfire dhcpd: Pool declarations must always contain at least Nov 14 16:36:27 ipfire dhcpd: one range statement. Nov 14 16:36:27 ipfire dhcpd: /etc/dhcp/dhcpd.conf line 30: Pool declaration with no address range. Nov 14 16:36:27 ipfire dhcpd: } Nov 14 16:36:27 ipfire dhcpd: ^ Nov 14 16:36:27 ipfire dhcpd: Pool declarations must always contain at least Nov 14 16:36:27 ipfire dhcpd: one range statement. Nov 14 16:36:27 ipfire dhcpd: Configuration file errors encountered -- exiting ... And...yes... [Hrm!]...I'm running 'dhcpd' on GREEN and BLUE with NO address pools. Only fixed leases. Anything I can do to test this without address ranges? Best, Matthias
I have been thinking further about this. It seems to me that deny unknown-clients is redundant within IPFire. deny unknown-clients implies allow known-clients but within IPFire all host declarations in the dhcpd.conf file will have a fixed address. Within dhcpd.conf generally you can have a host declaration that specifies the mac address but does not allocate a fixed address. In this case you could have a known host that can access a range. Within IPFire this will never exist as all host declarations (fixed lease) have to have a fixed address specified. So if you have a range statement and then also have a deny unknown-clients statement you have the situation where there is a range that no unknown client can use and no known client is allowed to use. If you don't have a range statement then there can be no pool and therefore the pool scope allow/deny statements can not be used. The global allow/deny statements should not be used as they are deprecated. If you have just a range statement say in blue then if you are not using vlans you could have the situation where a known host in green might end up getting a lease from the blue range. Here a deny known-clients makes sense. Your range in this case would be limited to only unknown clients. This also implies that if you don't have a range specified then there is no point in having the radio buttons. I am working on an updated modification that will go back to a checkbox but only for deny known-clients and will only be shown if a range has been specified in the subnet.
Patch to add "deny known-clients" onto the dhcp WUI submitted to patchwork. https://patchwork.ipfire.org/patch/3724/
https://git.ipfire.org/?p=ipfire-2.x.git;a=commit;h=9dbf3c4936395bebc5db124382209b8cd3fcb241
https://blog.ipfire.org/post/ipfire-2-25-core-update-154-available-for-testing
When working on another bug related to dhcp.cgi, I realised that I had made an error with the placement of a { in patch 3724. I have created a new patch which corrects this error. https://patchwork.ipfire.org/patch/3892/
Fix for errant curly bracket has been committed to Core Update 154 https://git.ipfire.org/?p=ipfire-2.x.git;a=commit;h=896fa74d68e83b344235dbd147b0e429aafb14d3
fix patch has been released with Core Update 154