[Dnsmasq-discuss] Tagging DHCP request (network-id) by the
incoming interface - possible?
Simon Kelley
simon at thekelleys.org.uk
Sat Sep 3 17:57:53 BST 2005
Daniel Lohmann wrote:
> Hi,
>
> I am using dnsmasq on an OpenWRT-based router (DLink-WL500 Deluxe) and I
> am quite sold on both, the simplicity and power of dnsmasq. This is
> definitly an excellent peace of software! I especially do like the
> network-id system to filter specific client requests.
>
> Which brings me to my question: It is possible to tag a client based on
> the network interface on which the request is comming in? If not, is
> this considered as a feature for upcoming versions?
>
> Here is what I am trying to attempt: On my router, I have two interfaces
> (let's call them "lan" and "wifi"), which are briged together to a
> third interface ("bridge"). Currently dnsmasq listens on the bridge
> interface, therefore serves both, wireless (wifi) and wired (lan)
> clients in the same manner.
>
> I would like to handle wifi clients differently. For instance, IPs
> should only be delivered to well-known wifi hosts (using dhcp-host),
> while unknown lan clients should simply get an address from the
> dhcp-range pool.
> The usual approach for such scenario is to use different subnets for lan
> and wifi. This, however, is *not* possible in my case. For certain
> reasons, I do not want to break the bridge; wifi and lan should still
> reside in the same subnet. (Actually, dnsmasq is the only service that
> should be able to distinguish between lan and wifi clients).
>
> Therefore I am looking for something like:
>
> interface=lan,lan-id # tag lan clients with lan-id
> interface=wifi,wifi-id # tag wifi clients with wifi-id
> ...
> dhcp-range=net:lan-id,<range options for lan clients>
> dhcp-ragne=net:wifi-id,<range options for wifi clients>
> ...
>
>
> Any idea how to achive something like this? Other opinions?
> Or am I totally barking up the wrong tree?
>
>
I don't think what you are asking for is possible: once the packet is
bridged and arrives on the bridge interface, there's no way to determine
where is came from: the layer-two bridging is transparent to the higher
levels.
You might be able to keep the more traditional scheme with dnsmasq
listening on the two interfaces without losing the bridge provided that
you can divide your subnet into two.
It's best to illustrate this with an example.
Assume subnet is 192.168.1.xx (netmask 255.255.255.0)
and the bridge interface has address 192.168.1.10
Now also configure the lan and wifi interfaces as
192.168.1.1/255.255.255.128 - lan
192.168.1.129/255.255.255.128 - wifi
you can now configure dnsmasq to do dhcp on those two interfaces with
whatever policies you like, provided that lan clients are in the first
half of the address range and wifi ones in the second.
All clients can use 192.168.1.10 as default router and 255.255.255.0 as
netmask and therefore are on the same subnet for everything else. To do
that you will have to overide the router and netmasks that dnsmasq
normally sends using dhcp-option configs - that's easy
dhcp-option=1,255.255.255.0 # netmask
dhcp-option=3,192,168.1.10 # router
dnsmasq will also send 192.168.1.1 or 192.168.1.129 as the DNS server
unless overridden. Since you want to treat the hosts as being on one
subnet you can override that too.
dhcp-option=6,192,168.1.10 # dns server
Note that DHCP broadcasts will also be received via the bridge, so you
have to make sure that you disable DHCP on the bridge interface. To
provide DNS via the bridge but not DHCP make sure you are running 2.23
and then add
--no-dhcp-interface=<interface name>
HTH
Simon.
More information about the Dnsmasq-discuss
mailing list