thanks Brian, perhaps the backstory might be interesting - by the time i emailed the list here, it was after a while of trying to troubleshoot and try different things (the ol' throw-enough-sh*t at the wall and maybe something will stick-approach. def not the brightest idea on my part).
i added the dhcp-option= part when i was getting desperate about not getting the subnet correctly, but by then i had I failed to realize the impact of earlier adding dhcp-option-force as it was in there from before, for a different reason (i thought it would bypass the is-there-a-dhcp-server checks openwrt does before starting up).. i just checked the man page (admittedly something I probably should have done earlier) and realized that dhcp-option-force=lan,1 means option 1 (subnet) is affected.. i'm not sure what the outcome was supposed to be of having both (sems to be allowed?), but it seems the option 1 was not sent at all regardless of client querying for it then (i was informed on the forum linked before that it was due to the force though).. i removed it and the right subnet started to appear, so i got rid of both and lived happily again (well, until the next issue i end up running into). On Tue, 19 Sept 2023 at 15:20, Brian Davidson <davidson.br...@gmail.com> wrote: > You appear to have competing settings for subnet. > > dhcp-option=lan,1,255.255.255.0 > dhcp-option-force=lan,1 > > Is it intentional? > > On Tue, Sep 19, 2023 at 9:28 AM AleksM <a+dnsm...@alek.cx> wrote: > > > > Hi all, > > > > I'm running on OpenWRT (SNAPSHOT r23935+13-c1206675a4) which has > installed dnsmasq 2.89 and my client is a macbook running MacOS 12.3.1 and > I recently switched from a single dnsmasq instance to a multi-instance > dnsmasq setup (because i wanted a different subdomain name given for the > different networks i have dnsmasq listen on and that was the approach > suggested in openwrt forum), > > > > But when i performed this change, i found out (after many days of > troubleshooting) that the dhcp response no longer contained a subnet-mask > field (which was causing my client to use the default /16 for a classful > CIDR of that address space, which caused connectivity issues that were > hilariously baffling at first). > > > > Is there some bug here, or am I doing something wrong? > > > > Attaching both the single-instance dnsmasq.conf (working) and the > DHCPOFFER response as well as the offending instance in the multi-instance > dnsmasq.conf (broken) and the DHCPOFFER response, where the subnet-mask > option is omitted (despite me attempting to add it as an extra DHCPOPTION > #1 even!) > > > > Any advice or anything else to look at? > > > > Warm regards, > > Aleks > > _______________________________________________ > > 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
