[Dnsmasq-discuss] dhcp-ignore = myTag, #known was not what I thought
Hi, I just discovered that I got wrong what dhcp-ignore does... I'll try to explain what I want and what I did and see if someone can explain me what I got wrong or, better yet, a way to do what I want :-) I'm using 2.45 (but can upgrade to 2.46 if needed). I'm using dnsmasq in a firewall with three internal legs (2 different wifi networks and a local wired net). In the local wired net I'm using one class C network, but I have 2 different ranges (with different treatment in my firewall). I want to give IP addresses in one range only to MACs I know, and in the other range to others, so I wrote part of my configuration as in the file attached... in particular: dhcp-range=tagIKnowYou,192.168.1.101,192.168.1.120,4h dhcp-ignore=tagIKnowYou,#known dhcp-range=tagAllTheRest,192.168.1.161,192.168.1.174,4h dhcp-host=00:22:33:44:55:66,192.168.1.101,net:tagIKnowYou,mycompany-PC-01 dhcp-host=00:22:33:44:55:02,192.168.1.101,net:tagIKnowYou,mycompany-PC-02 dhcp-host=00:22:33:44:55:03,192.168.1.101,net:tagIKnowYou,mycompany-PC-03 At first everything went the way I wanted... my three known PCs got their addresses from the first range (192.168.1.101, 192.168.1.102 and 192.168.1.103) and all the rest got address from the second range... But when we hook up a new computer and I didn't notice that my second range was too little, instead of rejecting the DHCPREQUEST for not having enough IPs, it gave it an IP from the first range (192.168.1.104). I thought that the line: dhcp-ignore=tagIKnowYou,#known would prevent this, but clearly I'm understanding it wrong... or I hit a bug? How should I configure my dnsmasq to prevent unknown MACs from getting an IP in the tagIKnowYou range? TIA. -- Mariano Absatz - El Baby el.b...@gmail.com www.clueless.com.ar -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Common sense is the collection of prejudices acquired by age eighteen. Albert Einstein, (attributed) US (German-born) physicist (1879 - 1955) -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- * TagZilla 0.066 * http://tagzilla.mozdev.org
Re: [Dnsmasq-discuss] dhcp-ignore = myTag, #known was not what I thought
Mariano Absatz wrote: Hi, I just discovered that I got wrong what dhcp-ignore does... I'll try to explain what I want and what I did and see if someone can explain me what I got wrong or, better yet, a way to do what I want :-) I'm using 2.45 (but can upgrade to 2.46 if needed). I'm using dnsmasq in a firewall with three internal legs (2 different wifi networks and a local wired net). In the local wired net I'm using one class C network, but I have 2 different ranges (with different treatment in my firewall). I want to give IP addresses in one range only to MACs I know, and in the other range to others, so I wrote part of my configuration as in the file attached... in particular: dhcp-range=tagIKnowYou,192.168.1.101,192.168.1.120,4h dhcp-ignore=tagIKnowYou,#known This means, ignore the host if tagIKnowYou is set AND tag known is NOT set. Since either both of the tags will be set, or neither, then the condition is never met. dhcp-range=tagAllTheRest,192.168.1.161,192.168.1.174,4h dhcp-host=00:22:33:44:55:66,192.168.1.101,net:tagIKnowYou,mycompany-PC-01 dhcp-host=00:22:33:44:55:02,192.168.1.101,net:tagIKnowYou,mycompany-PC-02 dhcp-host=00:22:33:44:55:03,192.168.1.101,net:tagIKnowYou,mycompany-PC-03 At first everything went the way I wanted... my three known PCs got their addresses from the first range (192.168.1.101, 192.168.1.102 and 192.168.1.103) and all the rest got address from the second range... But when we hook up a new computer and I didn't notice that my second range was too little, instead of rejecting the DHCPREQUEST for not having enough IPs, it gave it an IP from the first range (192.168.1.104). I thought that the line: dhcp-ignore=tagIKnowYou,#known would prevent this, but clearly I'm understanding it wrong... or I hit a bug? Theres no bug, I think. How should I configure my dnsmasq to prevent unknown MACs from getting an IP in the tagIKnowYou range? You don't need to set your own tags at all, just use the known tag, which will be set whenever a dhcp-host matches the MAC address. Then do dhcp-range=net:known,192.168.1.101,192.168.1.120,4h dhcp-range=net:#known,192.168.1.161,192.168.1.174,4h That way, 192.168.1.101... will only be used when the MAC address is known, and 192.168.1.161... will only be used when the MAC address is not known. It's important to understand the two uses of tags in dhcp-range dhcp-range=tag,.. will _set_ the tag if that range is used. dhcp-range=net:tag,... will _use_ the range if the tag is set. HTH Simon.
[Dnsmasq-discuss] Re: Support for DHCP option 125
Samium Gromoff wrote: On Fri Sep 14 16:31:55 BST 2007, Simon Kelleys wrote: The existing support for non-vendor-identifying encapsulated options is in two places. The data gets laid out in the packet in the second half of do_options() in src/rfc2131.c. That's quite hairy code, but it should be extendable to option 125 without too many problems. dhcp-option lines in the config file and command line are parsed into a linked-list of struct dhcp_opt in parse_dhcp_opt() in src/option.c. That's hairy too (sorry!). option-60 encapsulated options look like: dhcp-option=vendor:some vendor string,option data That could be extended to cope with something like dhcp-option=vendor-id:enterprise-number,option data From: dnsmasq-discuss-requ...@lists.thekelleys.org.uk Subject: Welcome to the Dnsmasq-discuss mailing list Date: Thu, 04 Dec 2008 20:48:06 + I have implemented something along these lines, which, in effect, allows me to add following lines in dnsmasq.conf: dhcp-option-force= net:iscsi-client0, net:gpxe, vendor-id:175, 190, iscsi-client0 dhcp-option-force= net:iscsi-client0, net:gpxe, vendor-id:175, 191, iscsi-client0-secret and have the username and password fed to gPXE for iSCSI boot. (Yes, I know, specifying those via DHCP is a recipe for a breaking.) The patch works in just that scenario for me, but is otherwise untested. OK, this confused me for a while, until I realised that the subject is wrong. It has nothing to do with support for option 125 (as specified in RFC 3925) It looks like the gPXE folks have ignored that and gone their own merry way with option 175 to encapsulate their options. Yuck. Your patch isn't really complete: it won't cope with more than one set of encapsulated options (with different custom numbers), and will even mix up ordinary vendor-class options with the custom-option-number ones. Given what it's doing, I'd suggest a different keyword for this, maybe encapsulate. It would also be good to get proper RFC 3925 support whilst the code is being worked on. I'll take a further look at this when I get the chance. Cheers, Simon.
