[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