Re: [Dnsmasq-discuss] IP address based on switch port number (option 82)
On Wed, Feb 17, 2010 at 3:05 PM, Simon Kelley si...@thekelleys.org.uk wrote: richardvo...@gmail.com wrote: Actually, I think you can avoid that without loss of generality. By DeMorgan's theorem, the AND and NOT operations currently available are sufficient to define any expression. You just need a way to do grouping, which a syntax for setting one tag conditionally based on another tag would do. Remember that the example given doesn't need a complement applied, you can negate it in the match later. Since if is a very well understood concept, I'd propose tag-if switch1,port1 newtag Where newtag gets set if all listed tags are matched. Using multiple tag-if lines lets you effectively OR things together (this yields sum-of-products capability). Allow a user to unset a tag with tag-if #switch1,port15 #newtag for even more flexibility, but now all tag-if commands need to be processed in order. Genius! That's perfect. I think the second form might not be sensible, since the order of lines in the configuration file(s) is not significant anywhere else. The simplest scheme would ban tags defined in tag-if declarations from use in other tag-if declarations. If that wasn't done, there would be a need for multiple iterations to find all the tag values, and the possibility of unresolvable data-loops exemplified by tag-if black, white tag-if white, black as long as you're not going to prohibit tag-if set:hipower tag:uv tag-if set:hipower tag:violet tag-if set:hipower tag:indigo tag-if set:hipower tag:blue tag-if set:visible tag:violet tag-if set:visible tag:indigo tag-if set:visible tag:blue tag-if set:visible tag:green tag-if set:visible tag:yellow tag-if set:visible tag:orange tag-if set:visible tag:red which means hipower := blue + indigo + violet + uv; visible := violet + indigo + blue + green + yellow + orange + red; and then you could e.g. assign a dhcp pool to tag:visible while assigning a default gateway to tag:hipower (and a different one to tag:!hipower), and then assign a different bootp image for each color individually. Actually, instead of prohibiting use of tags set by tag-if for further tag-if, I think it's more reasonable to execute the lines in order and generate a warning if there's any attempted backpropagation. I mean, build a cumulative list of tags which appear on the condition side (tag:xyz) of tag-if lines. If any tag-if would set:xyz when xyz is in the list of matched tags, warn. But allow this: tag-if set:F tag:A,tag:B tag-if set:F tag:C tag-if set:G tag:F,tag:D which yields G := ((A*B) + C) * D; without recursive parsing. But then warn if a later line contained: tag-if set:D (any condition here) because D is already tested in a tag-if Of course this isn't really necessary, we can expand to sum-of-products as follows: G := (A*B*D) + (C*D); and get the same result via non-iterative conditional tagging: tag-if set:G tag:A,tag:B,tag:D tag-if set:G tag:C,tag:D I'd modify the syntax to match the changes in 2.53 where testing the value of a tag is always done with tag:tagname and setting a tag is always done with set:tagname, and ! is used for NOT. So we end up with tag-if set:newtag, tag:!switch1, tag:port15 I like. Back soon with a test implementation. Simon.
Re: [Dnsmasq-discuss] IP address based on switch port number (option 82)
richardvo...@gmail.com schrieb:
On Wed, Feb 17, 2010 at 3:05 PM, Simon Kelley si...@thekelleys.org.uk wrote:
richardvo...@gmail.com wrote:
[snip]
Actually, instead of prohibiting use of tags set by tag-if for further
tag-if, I think it's more reasonable to execute the lines in order and
generate a warning if there's any attempted backpropagation.
Hmmm, backpropagation is fun, this way one could build flip-flops, state
machines...
Let me think. All you need i clock gated logic.
You have an array of input states, you evalute the logic equations generating an
output state. When you are done with all equations, your output state becomes
your next input state:
STeval ST'
| a | | a'|
| b | | b'|
| c | -- | c'|
| d | | d'|
memcpy(ST, ST', sizeof(ST)); /* or swizzle the pointer */
if(ST[tag_asked_for]) {
/* whatever */
}
But this could get a little confusing for those not used to logic circuity...
I see where this will all lead to ... a tag construction tool with dnf
generation and Quine–McCluskey minimizer.
Greetings
Jan
--
programmer, n:
A red eyed, mumbling mammal capable of conversing with inanimate
monsters.
Re: [Dnsmasq-discuss] IP address based on switch port number (option 82)
Jan 'RedBully' Seiffert wrote: I see where this will all lead to ... a tag construction tool with dnf generation and Quine–McCluskey minimizer. Perfect! I look forward to the patch. My non-backpropagating tag-if evaluator took 11 lines of code. I'll give you an allowance of double that :-) Cheers, Simon
Re: [Dnsmasq-discuss] IP address based on switch port number (option 82)
Hallo, Jan, Du meintest am 18.02.10: I see where this will all lead to ... a tag construction tool with dnf generation and Quine?McCluskey minimizer. Quine/McCluskey is an awful way to minimize DNF etc. Slow and greedy. But that's another problem ... Viele Gruesse! Helmut
Re: [Dnsmasq-discuss] IP address based on switch port number (option 82)
Simon Kelley schrieb: Jan 'RedBully' Seiffert wrote: I see where this will all lead to ... a tag construction tool with dnf generation and Quine–McCluskey minimizer. Perfect! I look forward to the patch. My non-backpropagating tag-if evaluator took 11 lines of code. I'll give you an allowance of double that :-) Me and my big mouth... Maybe i didn't express myself right. I didn't thought of that as a runtime component of dnsmasq. dnsmasq would simply evaluate what it finds in its config, no fancy whatsoever. This DNF evaluation is nice and correct, but very raw (at times) and a nice brain jogging for the average admin. Simple cases are still easy (would mean no need to change a thing for the majority of setups), but it can get complex to achieve involved logic. It is like a GAL or a CD4019. Infinite in possability, but at some point you better can show some millimeter of digital guru beard (for the analog equivalent see Bob Pease). What i meant in this little comment was more like an external tool where someone can specify it's matching needs in a more practical/natural manner and klicks make it so, and it would throw out some lines of tag-if, one can cp in his config. Ideally you can klick your needs, some kind of GUI. This can be written in some scripting language, evaluation time is unimportant, some seconds is fast enough. This could even be a webpage either with scripting on the server or JS-foo. @Helmut: Yes, sure, but from the above, it is better than nothing, simple, maybe readily available (don't know, some import from logic.quine in some of those fancy languages?). ATM i'm more interrested at seeing the evaluation code, i have some thoughts going around my head how to make such an DNF evaluation efficient (with bitfields), and get in some kind of edge triggered back propagation. After i get this to_base32 code fast... Cheers, Simon Greetings Jan -- If you're sending someone Styrofoam, what do you pack it in?
Re: [Dnsmasq-discuss] IP address based on switch port number (option 82)
On Thu, Feb 18, 2010 at 4:49 AM, Helmut Hullen hul...@t-online.de wrote: Hallo, Jan, Du meintest am 18.02.10: I see where this will all lead to ... a tag construction tool with dnf generation and Quine?McCluskey minimizer. Quine/McCluskey is an awful way to minimize DNF etc. Slow and greedy. But that's another problem ... Sweet, I brought all the other EEs out of lurker status. Viele Gruesse! Helmut ___ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
Re: [Dnsmasq-discuss] IP address based on switch port number (option 82)
ignacio.br...@belden.com wrote: Simon Kelley si...@thekelleys.org.uk wrote on 16/02/2010 14:27:36: fakeroot debian/rules binary I found a problem when fakerooting (sorry for my ignorance) Do I need to install additional tools containing this lib?: Package libidn was not found in the pkg-config search path. Perhaps you should add the directory containing `libidn.pc' to the PKG_CONFIG_PATH environment variable No package 'libidn' found That's a mismatch between what's needed to compile Ubuntu's current dnsmasq package and the latest one. the fix is sudo apt-get install libidn11-dev The magic you need is that you can invert tags, so make the last line dhcp-range=net:#switch1,net:#puerto3,10.10.35.40,10.10.35.42,255.255.255.0 Then it can only be used when none of the port specific tags are in use. The problem I see here is switch1 tag is common to all switch1-ports. So I discard all switch1 ports when I write: net:#switch1 I feel I need something like: #(switch1ANDport3) instead #(switch1)AND#(port3) Is it possible to set something like #(net:switch1,net:port3)? or maybe an OR function so that different conditions (switchANDport) apply to the same range? Good point. Your requirements exceed what it's currently possible to express using the tag system. Maybe there needs to be something to calculate and arbitrary boolean expression on tags declare-tag set:newtag, !(switch1 port1) Joy, the options code finally becomes a full recusive-descent parser. Let me think about this a bit more. Simon. Thanks Ignacio DISCLAIMER: Privileged and/or Confidential information may be contained in this message. If you are not the addressee of this message, you may not copy, use or deliver this message to anyone. In such event, you should destroy the message and kindly notify the sender by reply e-mail. It is understood that opinions or conclusions that do not relate to the official business of the company are neither given nor endorsed by the company. Thank You.
Re: [Dnsmasq-discuss] IP address based on switch port number (option 82)
On Wed, Feb 17, 2010 at 5:03 AM, Simon Kelley si...@thekelleys.org.uk wrote: ignacio.br...@belden.com wrote: Simon Kelley si...@thekelleys.org.uk wrote on 16/02/2010 14:27:36: fakeroot debian/rules binary I found a problem when fakerooting (sorry for my ignorance) Do I need to install additional tools containing this lib?: Package libidn was not found in the pkg-config search path. Perhaps you should add the directory containing `libidn.pc' to the PKG_CONFIG_PATH environment variable No package 'libidn' found That's a mismatch between what's needed to compile Ubuntu's current dnsmasq package and the latest one. the fix is sudo apt-get install libidn11-dev The magic you need is that you can invert tags, so make the last line dhcp-range=net:#switch1,net:#puerto3,10.10.35.40,10.10.35.42,255.255.255.0 Then it can only be used when none of the port specific tags are in use. The problem I see here is switch1 tag is common to all switch1-ports. So I discard all switch1 ports when I write: net:#switch1 I feel I need something like: #(switch1ANDport3) instead #(switch1)AND#(port3) Is it possible to set something like #(net:switch1,net:port3)? or maybe an OR function so that different conditions (switchANDport) apply to the same range? Can't the option-matching lines which set e.g. port1 also set e.g. nopool, then use #nopool in the dhcp-range line? I guess there might need to be nosw1pool, nosw2pool, nosw3pool, and then dhcp-range such as net:switch1,net:#nosw1pool Or maybe even just net:switch1,net:#port3,net:#port4 (pool which is valid for all switch1 ports except 3 and 4) Good point. Your requirements exceed what it's currently possible to express using the tag system. Maybe there needs to be something to calculate and arbitrary boolean expression on tags declare-tag set:newtag, !(switch1 port1) Joy, the options code finally becomes a full recusive-descent parser. Actually, I think you can avoid that without loss of generality. By DeMorgan's theorem, the AND and NOT operations currently available are sufficient to define any expression. You just need a way to do grouping, which a syntax for setting one tag conditionally based on another tag would do. Remember that the example given doesn't need a complement applied, you can negate it in the match later. Since if is a very well understood concept, I'd propose tag-if switch1,port1 newtag Where newtag gets set if all listed tags are matched. Using multiple tag-if lines lets you effectively OR things together (this yields sum-of-products capability). Allow a user to unset a tag with tag-if #switch1,port15 #newtag for even more flexibility, but now all tag-if commands need to be processed in order. Let me think about this a bit more. Simon. Thanks Ignacio DISCLAIMER: Privileged and/or Confidential information may be contained in this message. If you are not the addressee of this message, you may not copy, use or deliver this message to anyone. In such event, you should destroy the message and kindly notify the sender by reply e-mail. It is understood that opinions or conclusions that do not relate to the official business of the company are neither given nor endorsed by the company. Thank You. ___ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
Re: [Dnsmasq-discuss] IP address based on switch port number (option 82)
richardvo...@gmail.com wrote: Actually, I think you can avoid that without loss of generality. By DeMorgan's theorem, the AND and NOT operations currently available are sufficient to define any expression. You just need a way to do grouping, which a syntax for setting one tag conditionally based on another tag would do. Remember that the example given doesn't need a complement applied, you can negate it in the match later. Since if is a very well understood concept, I'd propose tag-if switch1,port1 newtag Where newtag gets set if all listed tags are matched. Using multiple tag-if lines lets you effectively OR things together (this yields sum-of-products capability). Allow a user to unset a tag with tag-if #switch1,port15 #newtag for even more flexibility, but now all tag-if commands need to be processed in order. Genius! That's perfect. I think the second form might not be sensible, since the order of lines in the configuration file(s) is not significant anywhere else. The simplest scheme would ban tags defined in tag-if declarations from use in other tag-if declarations. If that wasn't done, there would be a need for multiple iterations to find all the tag values, and the possibility of unresolvable data-loops exemplified by tag-if black, white tag-if white, black I'd modify the syntax to match the changes in 2.53 where testing the value of a tag is always done with tag:tagname and setting a tag is always done with set:tagname, and ! is used for NOT. So we end up with tag-if set:newtag, tag:!switch1, tag:port15 I like. Back soon with a test implementation. Simon.
Re: [Dnsmasq-discuss] IP address based on switch port number (option 82)
Simon Kelley si...@thekelleys.org.uk wrote on 15/02/2010 22:19:21: Maybe not. Please could you split the test up: use a dhcp-range without tags, so that an address is always allocated, set log-dhcp, and check which tags are set. (Look in syslog, the set of tags is printed there.) That will help to isolate the problem. First of all sorry for my previous htmls I did your test and found: When: dhcp-range=10.10.35.2,10.10.35.5,255.255.255.0 dhcp-remoteid=switch1,00:06:00:80:63:60:e1:64 dhcp-circuitid=puerto3,b9:06:00:00:01:01:01:03 I get: dnsmasq: etiquetas: puerto3, eth0 (only last tag configured is set) And when: dhcp-range=10.10.35.2,10.10.35.5,255.255.255.0 dhcp-circuitid=puerto3,b9:06:00:00:01:01:01:03 dhcp-remoteid=switch1,00:06:00:80:63:60:e1:64 I get: dnsmasq: etiquetas: switch1, eth0 (only last tag configured is set) Best Ignacio DISCLAIMER: Privileged and/or Confidential information may be contained in this message. If you are not the addressee of this message, you may not copy, use or deliver this message to anyone. In such event, you should destroy the message and kindly notify the sender by reply e-mail. It is understood that opinions or conclusions that do not relate to the official business of the company are neither given nor endorsed by the company. Thank You.
Re: [Dnsmasq-discuss] IP address based on switch port number (option 82)
ignacio.br...@belden.com wrote: Simon Kelley si...@thekelleys.org.uk wrote on 15/02/2010 22:19:21: Maybe not. Please could you split the test up: use a dhcp-range without tags, so that an address is always allocated, set log-dhcp, and check which tags are set. (Look in syslog, the set of tags is printed there.) That will help to isolate the problem. First of all sorry for my previous htmls I did your test and found: When: dhcp-range=10.10.35.2,10.10.35.5,255.255.255.0 dhcp-remoteid=switch1,00:06:00:80:63:60:e1:64 dhcp-circuitid=puerto3,b9:06:00:00:01:01:01:03 I get: dnsmasq: etiquetas: puerto3, eth0 (only last tag configured is set) And when: dhcp-range=10.10.35.2,10.10.35.5,255.255.255.0 dhcp-circuitid=puerto3,b9:06:00:00:01:01:01:03 dhcp-remoteid=switch1,00:06:00:80:63:60:e1:64 I get: dnsmasq: etiquetas: switch1, eth0 (only last tag configured is set) Best Ignacio Ah, yes. That's a bug, a rather obvious face-plant bug ;-) What version of Ubuntu are you using? I have test release which fixes this and should solve the unicast-renewal problem and I can probably send it to you as a Debian/Ubuntu package. Simon.
Re: [Dnsmasq-discuss] IP address based on switch port number (option 82)
Simon Kelley si...@thekelleys.org.uk wrote on 16/02/2010 10:38:56: Ah, yes. That's a bug, a rather obvious face-plant bug ;-) What version of Ubuntu are you using? I have test release which fixes this and should solve the unicast-renewal problem and I can probably send it to you as a Debian/Ubuntu package. Simon. Hi Simon, Ubuntu 9.04 april 2009 Regarding your suggestion to activate Relay option in all ports and just configure a dynamic pool for 'non per port specific IPs'. I think this config would apply the 'not-port-related' pool even to those ports with an specific IP. Wouldn`t it? I did a first try and seems so, I did (iptables is activated), please let me know if fits: dhcp-range=net:switch1,10.10.35.2,10.10.35.5,255.255.255.0 -port specific range dhcp-circuitid=puerto3,b9:06:00:00:01:01:01:03 dhcp-remoteid=switch1,00:06:00:80:63:60:e1:64 dhcp-range=10.10.35.40,10.10.35.42,255.255.255.0 non specific pool All ports get an ip from the non specific pool Thanks Ignacio DISCLAIMER: Privileged and/or Confidential information may be contained in this message. If you are not the addressee of this message, you may not copy, use or deliver this message to anyone. In such event, you should destroy the message and kindly notify the sender by reply e-mail. It is understood that opinions or conclusions that do not relate to the official business of the company are neither given nor endorsed by the company. Thank You.
Re: [Dnsmasq-discuss] IP address based on switch port number (option 82)
ignacio.br...@belden.com wrote: Simon Kelley si...@thekelleys.org.uk wrote on 16/02/2010 10:38:56: Ah, yes. That's a bug, a rather obvious face-plant bug ;-) What version of Ubuntu are you using? I have test release which fixes this and should solve the unicast-renewal problem and I can probably send it to you as a Debian/Ubuntu package. Simon. Hi Simon, Ubuntu 9.04 april 2009 OK, that's the one recent version I don't have ready access too. I can talk you through building the packages from source. download http://www.thekelleys.org.uk/dnsmasq/test-releases/dnsmasq-2.53test7.tar.gz and expand it tar xzf dnsmasq-2.53test7.tar.gz make sure you have the tools needed to build sudo apt-get install build-essential sudo apt-get build-dep dnsmasq then cd in to dnsmasq-2.53 and run fakeroot debian/rules binary That should give you two .deb files one directory up. Install those with cd .. sudo dpkg -i dnsmasq-base_2.53-1_i386.deb dnsmasq_2.53-1_all.deb Regarding your suggestion to activate Relay option in all ports and just configure a dynamic pool for 'non per port specific IPs'. I think this config would apply the 'not-port-related' pool even to those ports with an specific IP. Wouldn`t it? I did a first try and seems so, I did (iptables is activated), please let me know if fits: dhcp-range=net:switch1,10.10.35.2,10.10.35.5,255.255.255.0 -port specific range dhcp-circuitid=puerto3,b9:06:00:00:01:01:01:03 dhcp-remoteid=switch1,00:06:00:80:63:60:e1:64 dhcp-range=10.10.35.40,10.10.35.42,255.255.255.0 non specific pool All ports get an ip from the non specific pool The magic you need is that you can invert tags, so make the last line dhcp-range=net:#switch1,net:#puerto3,10.10.35.40,10.10.35.42,255.255.255.0 Then it can only be used when none of the port specific tags are in use. As you expand the system, you'll have to add any other tags in there, but there's no limit on the number allowed. Cheers, Simon.
Re: [Dnsmasq-discuss] IP address based on switch port number (option 82)
Is your switch able to set the DHCP Server Identifier Override Suboption? In my network i use this suboption to tell clients to unicast my Relay-DHCP Server and not DNSMASQ directly. DNSMASQ supports this Suboption. @SIMON: I don't think thats the right place to do some changes in your sourcecode. But a new option to enable / disable the permit of unicast-messages without tags on renewals is welcome. Liebe Grüße aus Freilassing, Michael Rack RSM Freilassing -- RSM Freilassing Tel.: +49 8654 607110 Nocksteinstr. 13Fax.: +49 8654 670438 D-83395 Freilassingwww.rsm-freilassing.de Am 14.02.2010 21:50, schrieb Simon Kelley: richardvo...@gmail.com wrote: On Sun, Feb 14, 2010 at 2:16 PM, Simon Kelleysi...@thekelleys.org.uk wrote: richardvo...@gmail.com wrote: I'm going to have to think about code changes to fix this in the general case. Are you able to compile and test new versions of dnsmasq? ebtables or iptables can be used to match the source MAC address and only accept inbound DHCP requests from the relay(s). No change needed to dnsmasq. I think there's still the problem that a configured host will attempt to renew a lease by unicast direct to the DHCP server, so that the request never goes to the relay, and doesn't pick up the option-82 information. The lack of that information will make dnsmasq think that the existing address is not permitted. A simple fix would be to suppress filtering of dhcp-ranges by tags, but only for lease renewals. Simon. As far as the client knows, the lease was granted by the relay, right? So it would unicast to the switch with dhcp-relay capability. You would think so, it would certainly make life easier and make a relay a true proxy, so that routability between clients and server wasn't needed. In fact the client knows the IP address of the server from the server-id field, and uses that for unicast renewal. It sucks, but it's the standard. Cheers, Simon. ___ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
Re: [Dnsmasq-discuss] IP address based on switch port number (option 82)
There is a realy easy solution for that :-) Join your desired ports to VLANs and create some subnets. I just can't understand it, why you wish to seperate DHCP-IP-Addresses on each port? Liebe Grüße aus Freilassing, Michael Rack RSM Freilassing -- RSM Freilassing Tel.: +49 8654 607110 Nocksteinstr. 13Fax.: +49 8654 670438 D-83395 Freilassingwww.rsm-freilassing.de Am 14.02.2010 23:56, schrieb ignacio.br...@belden.com: ebtables or iptables can be used to match the source MAC address and only accept inbound DHCP requests from the relay(s). No change needed to dnsmasq. I did that also with Iptables and it works. But there is a drawback: Not all ports really need option 82 (you can activate this switch function per port so that some ports have a fixed IP and some others not) In that general case dnsmasq should receive broadcasts and unicasts. Only some broadcasts should be discarded! I feel a good idea not checking circuit-remote ID tags on DHCP requests (not only renewals), what do you think? doing this no problem with renewals nor L2 relays. L3 relays would filter the broadcasts and this change would not disturb (i may be wrong...) Should you be interested in captures from hanewin dhcp server in the same scenario please let me know by the way, ISC also loops in this situation Simon: Of course I am eager to check any new code you could provide. I am a newbie in linux, may you please (if possible) detail commands/tools I should do/have to makeinstall any possible code? I am on ubuntu Thanks again Ignacio From: richardvo...@gmail.com richardvo...@gmail.com To: Simon Kelley si...@thekelleys.org.uk Cc: ignacio.br...@belden.com, dnsmasq-discuss@lists.thekelleys.org.uk Date: 14/02/2010 21:02 Subject: Re: [Dnsmasq-discuss] IP address based on switch port number (option 82) On Sun, Feb 14, 2010 at 1:53 PM, Simon Kelley si...@thekelleys.org.uk wrote: ignacio.br...@belden.com wrote: Hello Simon, Thanks fo such a quick answer! Yes I detected that a bit later and the tag is set now. dhcp-range=net:ignacio,10.10.35.60,10.10.35.65 dhcp-circuitid=ignacio,b9:06:00:00:01:01:01:03, dhcp-remoteid=ignacio,00:06:00:80:63:60:e1:64 BUT IT STILL DOESNT WORK. the tag is set but i detected sort of a loop of discovers, NAKs and ACKs so that client does never get its IP Please find enclosed log output (dnsmasq shows loop.txt) Every dnsmasq: etiquetas: ignacio, eth0 tag is set (Spanish log, sorry) Please find enclosed capture file showing the loop (dhcp loop from wireshark at the server side): Relay: .251 server: .200 Please take into account I have a layer2 network (clientL2switch acting as dhcp relay op82---dhcp server) I feel the problem is dnsmasq receives two requests at almost the same time (the broadcasted one which is Naked and the unicasted one Acked) Of course the NACk message restarts the process at the client side Two questions: - Do you have any dnsmasq config solution for that (what´s the reason for the first request to be NAKed?)? I have experience with Hanewin and works ok in this topology without 'external help' I got one solution using iptables -A INPUT -i eth0 -p udp -s 0.0.0.0/32 -d 255.255.255.255/32 --dport 67 -j DROP (i do filter any broadcasted request or discover) You are right. It's getting one request direct (without going through the relay in the switch) and one request from the relay. Only the request that goes throught switch has the circuit-id and sets the tag. Without the tag, the dhcp-range is not avilable, so it causes an error. Part of this problem is the strange setup you have where the clients are in the same broadcast domain as the server, _and_ you have the DHCP relay. Even without that there's still a problem because clients will do DHCP renewals direct/unicast without using the relay - that will fail. Some switches can be configured to do transparent option-82 addition to _all_ DHCP packets without doing the relay function. That would fix the problem if your switch can do it. I'm going to have to think about code changes to fix this in the general case. Are you able to compile and test new versions of dnsmasq? ebtables or iptables can be used to match the source MAC address and only accept inbound DHCP requests from the relay(s). No change needed to dnsmasq. - does dnsmasq.conf do an AND with dhcp-circuitid dhcp-remoteid values?, I mean, should I have more than one switch could dnsmasq sort the first port of the first switch and the first port at the second switch? Yes, you can do that: The AND function is in dhcp-range: set tags for each switch and port and use a switch tag and a port tag in dhcp-range dhcp-range=net:switch-1,net:port-1,192.168.7.1,192.168.7.4,255.255.255.0 Cheers, Simon. ___ Dnsmasq
Re: [Dnsmasq-discuss] IP address based on switch port number (option 82)
I had completely forgotten about the server-address-override option. Thanks to Richard and Michael for reminding me about that. It is indeed supported and should solve the unicast renewal problem. Ignacio, why not configure you switch to relay all ports? Then you can block broadcasts without problems. You don't have to have special configuration in dnsmasq for all the ports, it will do boring dynamic address allocation fine on relayed requests. (Remember that the netmask is not option in dhcp-range lines used by clients behind a relay.) Michael: the change I was thinking of should be completely transparent in all other situations except this. It just inhibits filtering of available dhcp-ranges by tag on a unicast DHCP renewal. Since by that time a lease will exist and the address is known, at most one dhcp-range can match anyway. Simon.,
Re: [Dnsmasq-discuss] IP address based on switch port number (option 82)
Hallo Michael, No, my switches cannot set the dhcp server identifier suboption I just can't understand it, why you wish to seperate DHCP-IP-Addresses on each port? This layer 2 option 82 is quite interesting and used in Industrial Networks (factories or machinery for instance) where time to exchange faulty end-devices is key to reduce production stops Process control sensors and actuators (really simple devices) can be directly connected to the network (replaced) without wasting time (and reducing mistakes) asigning IPs and so on. Of course this method also reduces the skills needed to exchange these devices as the DHCP server is doing it (just connect where indicated) BR Ignacio DISCLAIMER: Privileged and/or Confidential information may be contained in this message. If you are not the addressee of this message, you may not copy, use or deliver this message to anyone. In such event, you should destroy the message and kindly notify the sender by reply e-mail. It is understood that opinions or conclusions that do not relate to the official business of the company are neither given nor endorsed by the company. Thank You.
Re: [Dnsmasq-discuss] IP address based on switch port number (option 82)
On Mon, Feb 15, 2010 at 3:57 AM, Simon Kelley si...@thekelleys.org.uk wrote: I had completely forgotten about the server-address-override option. Thanks to Richard and Michael for reminding me about that. It is indeed supported and should solve the unicast renewal problem. Sounds like an option (--relay-masquerade ?) is needed to enable this behavior even when the relay didn't request it. Or would that break something? Ignacio, why not configure you switch to relay all ports? Then you can block broadcasts without problems. You don't have to have special configuration in dnsmasq for all the ports, it will do boring dynamic address allocation fine on relayed requests. (Remember that the netmask is not option in dhcp-range lines used by clients behind a relay.) Michael: the change I was thinking of should be completely transparent in all other situations except this. It just inhibits filtering of available dhcp-ranges by tag on a unicast DHCP renewal. Since by that time a lease will exist and the address is known, at most one dhcp-range can match anyway. I don't think this is a solution. If you moved a station between ports, it would renew the address assigned to the old port, which both doesn't meet the OP's stated requirement and leaves the next device connected to the old port with no available address. Simon., ___ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
Re: [Dnsmasq-discuss] IP address based on switch port number (option 82)
ignacio.br...@belden.com wrote: Hello Simon, Yes, you can do that: The AND function is in dhcp-range: set tags for each switch and port and use a switch tag and a port tag in dhcp-range dhcp-range=net:switch-1,net:port-1,192.168.7.1,192.168.7.4,255.255.255.0 I have problems with the AND function. If I set: dhcp-range=net:port-1,10.10.35.60,10.10.35.65,255.255.255.0 dhcp-circuitid=port-1,b9:06:00:00:01:01:01:03 Port-1 tag is set and offer is sent If I set: dhcp-range=net:switch-1,10.10.35.60,10.10.35.65,255.255.255.0 dhcp-remoteid=switch-1,00:06:00:80:63:60:e1:64 switch-1 tag is set and offer is sent But in this case: dhcp-range=net:port-1,net:switch-1,10.10.35.60,10.10.35.65,255.255.255.0 dhcp-circuitid=port-1,b9:06:00:00:01:01:01:03 dhcp-remoteid=switch-1,00:06:00:80:63:60:e1:64 NO OFFER IS SEND NOT TAG SET I must be doing something wrong. Please let me know Maybe not. Please could you split the test up: use a dhcp-range without tags, so that an address is always allocated, set log-dhcp, and check which tags are set. (Look in syslog, the set of tags is printed there.) That will help to isolate the problem. Cheers, Simon.
Re: [Dnsmasq-discuss] IP address based on switch port number (option 82)
ignacio.br...@belden.com wrote: Hello Simon, Thanks fo such a quick answer! Yes I detected that a bit later and the tag is set now. dhcp-range=net:ignacio,10.10.35.60,10.10.35.65 dhcp-circuitid=ignacio,b9:06:00:00:01:01:01:03, dhcp-remoteid=ignacio,00:06:00:80:63:60:e1:64 BUT IT STILL DOESNT WORK. the tag is set but i detected sort of a loop of discovers, NAKs and ACKs so that client does never get its IP Please find enclosed log output (dnsmasq shows loop.txt) Every dnsmasq: etiquetas: ignacio, eth0 tag is set (Spanish log, sorry) Please find enclosed capture file showing the loop (dhcp loop from wireshark at the server side): Relay: .251 server: .200 Please take into account I have a layer2 network (clientL2switch acting as dhcp relay op82---dhcp server) I feel the problem is dnsmasq receives two requests at almost the same time (the broadcasted one which is Naked and the unicasted one Acked) Of course the NACk message restarts the process at the client side Two questions: - Do you have any dnsmasq config solution for that (what´s the reason for the first request to be NAKed?)? I have experience with Hanewin and works ok in this topology without 'external help' I got one solution using iptables -A INPUT -i eth0 -p udp -s 0.0.0.0/32 -d 255.255.255.255/32 --dport 67 -j DROP (i do filter any broadcasted request or discover) You are right. It's getting one request direct (without going through the relay in the switch) and one request from the relay. Only the request that goes throught switch has the circuit-id and sets the tag. Without the tag, the dhcp-range is not avilable, so it causes an error. Part of this problem is the strange setup you have where the clients are in the same broadcast domain as the server, _and_ you have the DHCP relay. Even without that there's still a problem because clients will do DHCP renewals direct/unicast without using the relay - that will fail. Some switches can be configured to do transparent option-82 addition to _all_ DHCP packets without doing the relay function. That would fix the problem if your switch can do it. I'm going to have to think about code changes to fix this in the general case. Are you able to compile and test new versions of dnsmasq? - does dnsmasq.conf do an AND with dhcp-circuitid dhcp-remoteid values?, I mean, should I have more than one switch could dnsmasq sort the first port of the first switch and the first port at the second switch? Yes, you can do that: The AND function is in dhcp-range: set tags for each switch and port and use a switch tag and a port tag in dhcp-range dhcp-range=net:switch-1,net:port-1,192.168.7.1,192.168.7.4,255.255.255.0 Cheers, Simon.
Re: [Dnsmasq-discuss] IP address based on switch port number (option 82)
On Sun, Feb 14, 2010 at 1:53 PM, Simon Kelley si...@thekelleys.org.uk wrote: ignacio.br...@belden.com wrote: Hello Simon, Thanks fo such a quick answer! Yes I detected that a bit later and the tag is set now. dhcp-range=net:ignacio,10.10.35.60,10.10.35.65 dhcp-circuitid=ignacio,b9:06:00:00:01:01:01:03, dhcp-remoteid=ignacio,00:06:00:80:63:60:e1:64 BUT IT STILL DOESNT WORK. the tag is set but i detected sort of a loop of discovers, NAKs and ACKs so that client does never get its IP Please find enclosed log output (dnsmasq shows loop.txt) Every dnsmasq: etiquetas: ignacio, eth0 tag is set (Spanish log, sorry) Please find enclosed capture file showing the loop (dhcp loop from wireshark at the server side): Relay: .251 server: .200 Please take into account I have a layer2 network (clientL2switch acting as dhcp relay op82---dhcp server) I feel the problem is dnsmasq receives two requests at almost the same time (the broadcasted one which is Naked and the unicasted one Acked) Of course the NACk message restarts the process at the client side Two questions: - Do you have any dnsmasq config solution for that (what´s the reason for the first request to be NAKed?)? I have experience with Hanewin and works ok in this topology without 'external help' I got one solution using iptables -A INPUT -i eth0 -p udp -s 0.0.0.0/32 -d 255.255.255.255/32 --dport 67 -j DROP (i do filter any broadcasted request or discover) You are right. It's getting one request direct (without going through the relay in the switch) and one request from the relay. Only the request that goes throught switch has the circuit-id and sets the tag. Without the tag, the dhcp-range is not avilable, so it causes an error. Part of this problem is the strange setup you have where the clients are in the same broadcast domain as the server, _and_ you have the DHCP relay. Even without that there's still a problem because clients will do DHCP renewals direct/unicast without using the relay - that will fail. Some switches can be configured to do transparent option-82 addition to _all_ DHCP packets without doing the relay function. That would fix the problem if your switch can do it. I'm going to have to think about code changes to fix this in the general case. Are you able to compile and test new versions of dnsmasq? ebtables or iptables can be used to match the source MAC address and only accept inbound DHCP requests from the relay(s). No change needed to dnsmasq. - does dnsmasq.conf do an AND with dhcp-circuitid dhcp-remoteid values?, I mean, should I have more than one switch could dnsmasq sort the first port of the first switch and the first port at the second switch? Yes, you can do that: The AND function is in dhcp-range: set tags for each switch and port and use a switch tag and a port tag in dhcp-range dhcp-range=net:switch-1,net:port-1,192.168.7.1,192.168.7.4,255.255.255.0 Cheers, Simon. ___ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
Re: [Dnsmasq-discuss] IP address based on switch port number (option 82)
richardvo...@gmail.com wrote: I'm going to have to think about code changes to fix this in the general case. Are you able to compile and test new versions of dnsmasq? ebtables or iptables can be used to match the source MAC address and only accept inbound DHCP requests from the relay(s). No change needed to dnsmasq. I think there's still the problem that a configured host will attempt to renew a lease by unicast direct to the DHCP server, so that the request never goes to the relay, and doesn't pick up the option-82 information. The lack of that information will make dnsmasq think that the existing address is not permitted. A simple fix would be to suppress filtering of dhcp-ranges by tags, but only for lease renewals. Simon.
Re: [Dnsmasq-discuss] IP address based on switch port number (option 82)
On Sun, Feb 14, 2010 at 2:16 PM, Simon Kelley si...@thekelleys.org.uk wrote: richardvo...@gmail.com wrote: I'm going to have to think about code changes to fix this in the general case. Are you able to compile and test new versions of dnsmasq? ebtables or iptables can be used to match the source MAC address and only accept inbound DHCP requests from the relay(s). No change needed to dnsmasq. I think there's still the problem that a configured host will attempt to renew a lease by unicast direct to the DHCP server, so that the request never goes to the relay, and doesn't pick up the option-82 information. The lack of that information will make dnsmasq think that the existing address is not permitted. A simple fix would be to suppress filtering of dhcp-ranges by tags, but only for lease renewals. Simon. As far as the client knows, the lease was granted by the relay, right? So it would unicast to the switch with dhcp-relay capability.
Re: [Dnsmasq-discuss] IP address based on switch port number (option 82)
ignacio.br...@belden.com wrote: Hello List, I try without success to assign always the same IP (or range) per switch port (no matter the mac address, only matters the port at which the client is connected) To do this I use switches with dhcp relay option 82 activated. So telling, any discover getting to dnsmasq includes circuit-id and remote-id I dont understand the usage of dhcp-circuitid and dhcp-remoteid commands, may you please post me an example? I tried the following at dnsmasq.conf: dhcp-range=net:ignacio,192.168.7.1,192.168.7.4,255.255.255.0 dhcp-circuitid=ignacio,b9:06:00:00:01:0y1:01:05, dhcp-remoteid=ignacio,00:06:00:80:63:60:e1:64 Would this suffice? I suppose not as it does not work. (Hex values got from wireshark so they should be ok) You're certainly on the right lines. As few things to check: Don't use very old dnsmasq releases, there have been bugs in the cricuit-id matching code, so you need 2.44 or later. turn on dhcp logging with --log-dhcp that will tell you if the tag is being set. I suspect that you might be matching too much data: your hex looks very much like it includes the sub-option and length bytes as the first two. dnsmasq understands the sub-option format and will not need to see that. Could you post a packet capture here, or send direct to me? Cheers, Simon. Any help is appreciatted! Thanks Ignacio DISCLAIMER: Privileged and/or Confidential information may be contained in this message. If you are not the addressee of this message, you may not copy, use or deliver this message to anyone. In such event, you should destroy the message and kindly notify the sender by reply e-mail. It is understood that opinions or conclusions that do not relate to the official business of the company are neither given nor endorsed by the company. Thank You. ___ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
Re: [Dnsmasq-discuss] IP address based on switch port number (option 82)
Hello Simon, Thanks fo such a quick answer! Yes I detected that a bit later and the tag is set now. dhcp-range=net:ignacio,10.10.35.60,10.10.35.65 dhcp-circuitid=ignacio,b9:06:00:00:01:01:01:03, dhcp-remoteid=ignacio,00:06:00:80:63:60:e1:64 BUT IT STILL DOESNT WORK. the tag is set but i detected sort of a loop of discovers, NAKs and ACKs so that client does never get its IP Please find enclosed log output (dnsmasq shows loop.txt) Every dnsmasq: etiquetas: ignacio, eth0 tag is set (Spanish log, sorry) Please find enclosed capture file showing the loop (dhcp loop from wireshark at the server side): Relay: .251 server: .200 Please take into account I have a layer2 network (clientL2switch acting as dhcp relay op82---dhcp server) I feel the problem is dnsmasq receives two requests at almost the same time (the broadcasted one which is Naked and the unicasted one Acked) Of course the NACk message restarts the process at the client side Two questions: - Do you have any dnsmasq config solution for that (what´s the reason for the first request to be NAKed?)? I have experience with Hanewin and works ok in this topology without 'external help' I got one solution using iptables -A INPUT -i eth0 -p udp -s 0.0.0.0/32 -d 255.255.255.255/32 --dport 67 -j DROP (i do filter any broadcasted request or discover) - does dnsmasq.conf do an AND with dhcp-circuitid dhcp-remoteid values?, I mean, should I have more than one switch could dnsmasq sort the first port of the first switch and the first port at the second switch? Shoul you miss any info please let me know Thanks a lot for your help Ignacio From: Simon Kelley si...@thekelleys.org.uk To: ignacio.br...@belden.com Cc: dnsmasq-discuss@lists.thekelleys.org.uk Date: 13/02/2010 10:30 Subject: Re: [Dnsmasq-discuss] IP address based on switch port number (option 82) ignacio.br...@belden.com wrote: Hello List, I try without success to assign always the same IP (or range) per switch port (no matter the mac address, only matters the port at which the client is connected) To do this I use switches with dhcp relay option 82 activated. So telling, any discover getting to dnsmasq includes circuit-id and remote-id I dont understand the usage of dhcp-circuitid and dhcp-remoteid commands, may you please post me an example? I tried the following at dnsmasq.conf: dhcp-range=net:ignacio,192.168.7.1,192.168.7.4,255.255.255.0 dhcp-circuitid=ignacio,b9:06:00:00:01:0y1:01:05, dhcp-remoteid=ignacio,00:06:00:80:63:60:e1:64 Would this suffice? I suppose not as it does not work. (Hex values got from wireshark so they should be ok) You're certainly on the right lines. As few things to check: Don't use very old dnsmasq releases, there have been bugs in the cricuit-id matching code, so you need 2.44 or later. turn on dhcp logging with --log-dhcp that will tell you if the tag is being set. I suspect that you might be matching too much data: your hex looks very much like it includes the sub-option and length bytes as the first two. dnsmasq understands the sub-option format and will not need to see that. Could you post a packet capture here, or send direct to me? Cheers, Simon. Any help is appreciatted! Thanks Ignacio DISCLAIMER: Privileged and/or Confidential information may be contained in this message. If you are not the addressee of this message, you may not copy, use or deliver this message to anyone. In such event, you should destroy the message and kindly notify the sender by reply e-mail. It is understood that opinions or conclusions that do not relate to the official business of the company are neither given nor endorsed by the company. Thank You. ___ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss DISCLAIMER: Privileged and/or Confidential information may be contained in this message. If you are not the addressee of this message, you may not copy, use or deliver this message to anyone. In such event, you should destroy the message and kindly notify the sender by reply e-mail. It is understood that opinions or conclusions that do not relate to the official business of the company are neither given nor endorsed by the company. Thank You. dnsmasq: Rango DHCP disponible: 10.10.35.60 -- 10.10.35.65 dnsmasq: Clase de fabricante: MSFT 5.0 dnsmasq: DHCPDISCOVER(eth0) 00:15:b7:8b:a5:f3 no hay dirección disponible dnsmasq: paquete DHCP: id de transacción 2378382557 dnsmasq: Rango DHCP disponible: 10.10.35.60 -- 10.10.35.65 dnsmasq: Clase de fabricante: MSFT 5.0 dnsmasq: DHCPDISCOVER(eth0) 00:15:b7:8b:a5:f3 dnsmasq: DHCPOFFER(eth0) 10.10.35.63 00:15:b7:8b:a5:f3 dnsmasq: opciones pedidas: 1:netmask, 15:domain-name, 3:router, 6:dns-server, dnsmasq: opciones pedidas: 44:netbios-ns, 46:netbios-nodetype, 47
