Re: [Dnsmasq-discuss] How to pin IP range on an interface?

2019-11-06 Thread bln 77


> Am 05.11.2019 um 22:31 schrieb Geert Stappers :
> 
> On Tue, Nov 05, 2019 at 01:26:55PM -0600, Lonnie Abelbeck wrote:
>>> On Nov 5, 2019, at 12:39 PM, bln 77  wrote:
>>> 
>>> Hi everyone,
>>> 
>>> I have a 10.1.0.0/16 network.
>>> I want to have clients in the same network because I want to be able to 
>>> receive IP-broadcast for autodiscovery.
>>> I configured two VLANs and the router has an interface/ip in both:
>>> lan1: 10.1.1.0 with subnet mask 255.255.0.0
>>> lan2: 10.1.2.0 with subnet mask 255.255.0.0
>>> 
>>> Both interfaces are bridged together and I filter/firewall the traffic with 
>>> etables rules.
>>> I have a filter that blocks DHCP traffic from being bridged/forwarded.
>>> 
>>> Now I want to configure dnsmasq to offer the following ranges on the 
>>> interfaces so I can easily recognise in which net the client belongs:
>>> 
>>> dhcp-range=set:lan1,10.1.1.50,10.1.2.199,255.255.0.0,12h
>>> dhcp-range=set:lan2,10.1.2.50,10.1.3.199,255.255.0.0,12h
>>> 
>>> Unfortunately the clients on the second interface also getting an offer 
>>> from the 10.1.1.x range.
>>> 
>>> I think both ranges are active on both interfaces?
>>> 
>>> Is there any way to pin a range to an interface?
>>> 
>>> Any help is appreciated.
>> 
>> Alternatively, use isolated subnets with 255.255.255.0 masks, no bridge, and 
>> enable "avahi-daemon" to share the broadcasts you need between subnets.
>> 
>> Everything is now simple ... except possibly configuring "avahi-daemon". :-)
>> 
> 
> Here another person that doesn't understand the use case of O.P.
> 
> But I think the question is
>>> Is there any way to pin a range to an interface?
> 
> 
> Two snippets from http://thekelleys.org.uk/dnsmasq/docs/dnsmasq-man.html
> 
> 1: The tag "bootp" is set for BOOTP requests, and a tag whose name is the
>   name of the interface on which the request arrived is also set.
> 
> 2: --dhcp-range=[tag:[,tag:],][set:,]
> [,|][,[,]][,]
> 
> 
> Let us, this mailinglist, know how helpfull this posting was.
> 

This helped a lot. Didn’t knew that a tag is set automatically:)

Seems to work now:
dhcp-range=tag:eth0.1,10.1.1.50,10.1.1.199,255.255.0.0,12h
dhcp-range=tag:eth0.2,10.1.2.50,10.1.2.199,255.255.0.0,12h
lan1 and lan2 (openwrt) wasn’t set, instead the “real” name was used by dnsmasq

Thanks.



___
Dnsmasq-discuss mailing list
Dnsmasq-discuss@lists.thekelleys.org.uk
http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss


Re: [Dnsmasq-discuss] dhcp-name-match ?

2019-11-06 Thread James Feeney
Hey Simon

On 10/30/19 3:32 PM, Simon Kelley wrote:
> The question is, [if] the client-provided name and the dhcp-host name
> differ, which one should be matched? Since this is broken, there's no
> pre-existing behaviour to consider. Any configurations relying on one or
> the other are currently broken [by] definition.
> 
> I've decided that if both exist, then the name from dhcp-host should be
> matched. It seems that if the config explicitly nails a MAC address or
> client-id to a name, that's the one that should be used.

Hmm - if you would, let me make sure I understand, then, how this will work.

I would have thought to make "dhcp-name-match" match against the client 
provided name, since there is nothing that will assure that the client provided 
name is anything different from what the client wants to provide.  The client 
is not, necessarily, going to adopt the hostname provided by the dhcp server.

So then, does the "new" behavior mean that, effectively, "dhcp-name-match" is 
really a kind of "MAC-address-match", or "DUID-match", by way of the dhcp-host 
specified hostname?

I should, then, simply write "dhcp-name-match=", where the 
name is just the name associated with the dhcp-host MAC address, or with the 
DUID?

Also, then, if there is *no* dhcp-host hostname specified, will 
"dhcp-name-match" still match the client provided name?  Or, will that no 
longer work, at all?

A difficulty I see here, is that, if the client DUID or MAC address is *not* 
known, and only the persistent client provided name is offered by the client, 
then there will be no way to actually tag the client, unless every client DUID 
or MAC address is first discovered and manually configured with a hostname.

And then, why not simply have a "dhcp-DUID-match" or a "dhcp-MAC-addr-match", 
instead?

James

___
Dnsmasq-discuss mailing list
Dnsmasq-discuss@lists.thekelleys.org.uk
http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss