lf-edge
WIP: Support dnsmasq socket communications
- Thanks for picking up a newer dnsmasq version
Welcome :-)
- How likely are the patched to be accepted into dnsmasq?
They will probably end up in the /contrib directory
- Can we remove pkg/dnsmasq/patches/prefix_le_64.patch ? It is in the new version?
I dropped it in this PR. It has been included in the mainline repo.
if (new->prefix > 64)
{
if (new->flags & CONTEXT_RA)
err=(_("prefix length must be exactly 64 for RA subnets"));
else if (new->flags & CONTEXT_TEMPLATE)
err=(_("prefix length must be exactly 64 for subnet constructors"));
}
else if (new->prefix < 64)
err=(_("prefix length must be at least 64"));
if (!err && !is_same_net6(&new->start6, &new->end6, new->prefix))
err=(_("inconsistent DHCPv6 range"));
They will probably end up in the /contrib directory
That seems quite painful, because it means we have to maintain the patch forver and it is non-trivial. Can you explore whether they are interested in getting this type of functionality into their mainline/
- Can we remove pkg/dnsmasq/patches/prefix_le_64.patch ? It is in the new version?
I dropped it in this PR. It has been included in the mainline repo.
The code you included still returns an error if the prefix < 64. So AFAICT we still need our patch to remove that error check.
That seems quite painful, because it means we have to maintain the patch forver and it is non-trivial. Can you explore whether they are interested in getting this type of functionality into their mainline/
While it would be worthwhile to check @eriknordmark -- I wouldn't hold my breath -- all these projects only ever recognize one message bus to be included into the mainline and that is DBus. Things like ubus (from OpenWRT) etc. constantly struggle with custom patches that need to be forever maintained.
Hey @temerkhanov -- how do you propose we proceed on this one? @eriknordmark what's your take on taking it as-is if we can't upstream it?
We should probably start using it by ourselves, then we can try to upstream the patches
[the hostess took up the broom] @milan-zededa any thoughts on this? or we can close it?
@milan-zededa @giggsoff @eriknordmark Folks, do we still need the dnsmasq control over a socket? I assume @temerkhanov never tried to upstream the dnsmasq changes, so can be difficult to port to a newer version of dnsmasq (if we need to roll to a newer version of course). So if feature sounds interesting for zedrouter - let's discuss, I can help with trying to upstream dnsmasq changes, tidy up patches, etc. If not - let's close the PR.
From my understanding, the purpose of this patch is to avoid restarting dnsmasq on every lease add/del event or when ipsets change. This happens when app is (un)deployed or ACL config changes. I don't think this happens very often and it is probably not worth to maintain the patch ourselves.
