" looks like we need --no-dhcpv4-interface and --no-dhcpv6-interface. That would certainly solve your problem."
Just to clarify - you are stating that these options don't currently exist and would need to be implemented in a future version? I have blocked the request via ebtables on my device for now and this seems to work until a more supported solution is available. Also, in regards to the dhcp-options/tag syntax. What is the preferred way to define multiple dhcp-options statements for different scopes? It sounds list if I have: eth1 with 192.168.1.1 eth2 with 10.10.10.1 and dhcp-range=192.168.1.50-192.168.1.100 dhcp-range=10.0.0.100-10.0.0.150 That when the requests come in on those interfaces they will be "automagically" tagged with eth1/eth2. You can add additional tags, but they are not strictly necessary. dhcp-option=ABC dhcp-option=XYZ How does dnsmasq know which of those two defined options to provide to clients in their respective scopes if I have not configured a tag, or somehow correlated them to each individual range? thanks! On Mon, Apr 10, 2023 at 4:29 PM Simon Kelley <si...@thekelleys.org.uk> wrote: > > > On 05/04/2023 19:04, Ben Hendin wrote: > > Thanks Simon (apologies - my first reply went to your direct email > > instead of back to the list which was not my intent!) > > > > There are dhcp4 ranges defined, but none with ranges for those interface. > > For example, the interface which should give out the RAs is br0, and the > > relevant lines are: > > > > ra-param=br0,10,600 > > enable-ra > > quiet-ra > > dhcp-range=lan,::,constructor:br0,ra-stateless,64,600 > > > > But the device has other interfaces, for example br1 and br2 which have > > the following configuration: > > > > interface=br1 > > dhcp-range=br1,192.168.101.2,192.168.101.254,255.255.255.0,86400s > > dhcp-option=br1,3,192.168.101.1 > > interface=br2 > > dhcp-range=br2,192.168.102.2,192.168.102.254,255.255.255.0,86400s > > dhcp-option=br2,3,192.168.102.1 > > > > My understanding is that the line "interface=X" (e.g. interface=br1) is > > needed to actually enable dnsmasq to listen *at all* on that interface. > Almost. If there are no "interface=X" options at all, then dnsmasq will > listen on all interfaces. > > > But the use of br1 on the range/option lines is an arbitrary tag to > > simply associate those two options together. > That usage seems to be common folklore, actually it does nothing in this > case. dhcp-option=br1,..... is the same as dhcp-option=set:br1,.... for > long-dead backwards compatibility reasons. So it sets the tag "br1" for > DHCP transactions which arrive via br1. But a tag with the same name as > the interface is always automagically set so a "br1" tag exists anyway, > and the presence of br1 in the dhcp-option has no effect. > > > > > IOW, a particular dhcp-range is not associated with an interface using > > any explicit command, rather if a dhcp-range is defined and an interface > > that is defined with "interface=X" is bound to that subnet it will serve > > requests from the defined range? > > That's correct. > > > > So I do have dhcp4 ranges defined, and I want those serving out those > > IPs on the interfaces that are on those ranges, but I don't expect any > > DHCPv4 traffic to be answered on br0. > > > > I'm sure I can write iptable rules to block that, but something tells me > > that isn't the elegant way and perhaps there is a dnsmasq configuration > > methodology that I am overlooking??? > > > The whole interface= access control started when dnsmasq only did DNS, > and when DHCP was added it defaulted to doing both services on the same > set of interfaces, which is sensible default. To account for > configurations where DNS would be provided on interfaces where DHCP > wasn't wanted, the --no-dhcp-interface option was added. (Providing DHCP > on an interface but not DNS is not supported.) Logically, now that DHCP > has bifurcated into DHCPv4 and DHCPv6 it looks like we need > --no-dhcpv4-interface and --no-dhcpv6-interface. That would certainly > solve your problem. > > > Cheers, > > Simon. > > > > > On Wed, Apr 5, 2023 at 12:33 PM Simon Kelley <si...@thekelleys.org.uk > > <mailto:si...@thekelleys.org.uk>> wrote: > > > > > > > > On 03/04/2023 16:54, Ben Hendin wrote: > > > I'm running Dnsmasq version 2.85-openssl-5-g989ee98 on an embedded > > > device (Entware installation) > > > > > > I am seeing log entries that state the following when clients > > come onto > > > the network to request IP addresses via DHCP: > > > > > > "no address range available for DHCP request via br0" > > > > > > br0 is a bridged interface that includes the LAN and main WiFi of > > the > > > embedded device. > > > > > > The issue is that I do not use dnsmasq on this device for DHCP on > > this > > > interface. > > > (I do have it configured to deliver dhcp-range information to > > some other > > > wireless interfaces.) > > > The main function on this interface is DNS and to deliver RAs for > > IPv6. > > > > > > It appears, in order to deliver RAs to my clients the following > > lines > > > must be configured: > > > > > > ------------------- > > > interface=br0 > > > ra-param=br0,10,600 > > > enable-ra > > > dhcp-range=lan,::,constructor:br0,ra-stateless,64,600 > > > ----------------------- > > > > > > In other words, dhnsmasq must be configured to deliver the > > "dhcp-range" > > > option in order to deliver RAs (enable-ra isn't enough) > > > Because of this you can't use the "no-dhcp-interface=br0" option > > or else > > > the dhcp-range and therefore the RA will not get delivered to > > clients. > > > > > > When a client joins the network, it requests an IPv4 address, > > which will > > > not be served by dnsmasq, but by another authoritative server on > the > > > network. > > > However, because dnsmasq is configured to provide DHCP services, > > yet has > > > no IPv4 range defined it spits out the "no address range > available" > > > > > > I have tried changing the "ra-stateless" option to "slaac" or > > "ra-only" > > > as the description of "ra-only" seems to indicate that dnsmasq > > will then > > > be made aware it is only to deliver RAs and not DHCP (though > perhaps > > > this only registers for v6). I have also tried to use > > "quiet-dhcp" to > > > suppress these unsuccessfully. Because the message is still > > logged, it > > > would fall under "error or problem" according to "quiet-dhcp" > > > specifications. > > > > > > Is this behavior expected? If so, is it considered preferable or > > should > > > dnsmasq have some configuration where it should not assume that > > an IPv4 > > > range being unconfigured is an issue worth notifying about in > > scenarios > > > like this? > > > > > > > That's not expected behaviour. The log does indeed imply that this > is a > > DHCPv4 request (it would say no address range available for DHCPv6) > but > > unless there's a valid IPv4 dhcp-range defined dnsmasq should not > even > > be listening on the DHCPv4 port. The current code doesn't, and I > don't > > remember any fixes to this the 2.85-2.89 timeframe. > > > > What does dnsmasq log when it starts up? The most obvious explantion > > for > > this is that Entware's startup is defining a DHCPv4 range somewhere > in > > the config that gets passed to dnsmasq. > > > > > > Cheers, > > > > Simon. > > > > > > > thank you > > > > > > _______________________________________________ > > > Dnsmasq-discuss mailing list > > > Dnsmasq-discuss@lists.thekelleys.org.uk > > <mailto:Dnsmasq-discuss@lists.thekelleys.org.uk> > > > > > > https://lists.thekelleys.org.uk/cgi-bin/mailman/listinfo/dnsmasq-discuss < > https://lists.thekelleys.org.uk/cgi-bin/mailman/listinfo/dnsmasq-discuss> > > > > _______________________________________________ > > Dnsmasq-discuss mailing list > > Dnsmasq-discuss@lists.thekelleys.org.uk > > <mailto:Dnsmasq-discuss@lists.thekelleys.org.uk> > > > https://lists.thekelleys.org.uk/cgi-bin/mailman/listinfo/dnsmasq-discuss < > https://lists.thekelleys.org.uk/cgi-bin/mailman/listinfo/dnsmasq-discuss> > > > > > > _______________________________________________ > > Dnsmasq-discuss mailing list > > Dnsmasq-discuss@lists.thekelleys.org.uk > > https://lists.thekelleys.org.uk/cgi-bin/mailman/listinfo/dnsmasq-discuss > > _______________________________________________ > Dnsmasq-discuss mailing list > Dnsmasq-discuss@lists.thekelleys.org.uk > https://lists.thekelleys.org.uk/cgi-bin/mailman/listinfo/dnsmasq-discuss >
_______________________________________________ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk https://lists.thekelleys.org.uk/cgi-bin/mailman/listinfo/dnsmasq-discuss
