Dnsmasq-full, ipset support removed (in 23.05 and master)

Installing and Using OpenWrt
1

Ipset support as a compilation option has been removed from the dnsmasq-full package in favour of nftset support.

As it is supposed to be the FULL package, surely it should support both.

This is very unfortunate for those packages that use iptables-nft and ipsets (eg openNDS, Mwan3, Adblock etc) as these will now have problems.

Yes of course migration to full nftables support is desirable, but these can be a very significant workload.

And yes, Dnsmasq-full would be a bit bigger, but not hugely so....

Is there some overriding reason for this change, or is it just an oversight?

2

Does not look the way to me.

3

Do you mean it works for you?

root@OpenWrt:/tmp# dnsmasq -v
Dnsmasq version 2.88  Copyright (c) 2000-2022 Simon Kelley
Compile time options: IPv6 GNU-getopt no-DBus UBus no-i18n no-IDN DHCP DHCPv6 no-Lua TFTP conntrack no-ipset nftset auth cryptohash DNSSEC no-ID loop-detect inotify dumpfile

Note no-ipset in the compile options.

4

I mean it is there in menuconfig as an option; should qualify that with I'm on master

5

That is fine if you are compiling it yourself. But what if a package has it as a dependency?
Not many people compile everything from scratch....

If I want to install mwan3 and use it's ipset support, I don't want to have to set up a build system just to get the FULL full version.

6

See the commit and read the explanations.

The firewall4 compatible nftset should accept the same ipset config from the dhcp config file.

And like anomeome said, you can still enable the ipset support in the detailed feature config of dnsmasq-full.

1 Like
7

Not sure what the master snapshot builds include, but I would assume it is there as installable.

8

Yes it does, but what about packages that still use ipsets? I listed a few. Yes, in an ideal world everything would be migrated to nftables and use nftsets, but that is not an insignificant task.

9

Dnsmasq-full is there, but is compiled without ipset support (as indicated in my first reply to you).

10

Last week the compile option for ipset was in menuconfig to choose, but it isn’t set as standard.

To be honest, if you don’t use the precompiled standard images everything else but “build from source” is like doing something with your hands tied behind your back.

Imagebuilder is like square Lego blocks, it only puts together precompiled packages, you can’t make any adjustments or changes with imagebuilder since everything is already build.

1 Like
11

I'm talking about precompiled packages, rather than images, but it is the same principle.

We now have precompiled packages that don't work fully as one of their dependencies is no longer compiled to support its own standard functionality.

This appears to be an oversight resulting from adding nftsets pseudo compatibility with legacy ipset configuration in the new firewall4 package.

12

Are we talking about 21.02-snapshot, 22.03-snapshot or master-snapshot?

Pseudo compatibility…yea but my personal experience is that when the train rolls it rolls. Pseudo compatibility is just what you say, an imaginary transition time.
If the packages doesn’t move along they will sooner or later be left behind and probably be replaced with something new or upgraded, like BanIP now has to do some job to keep up with development.
So the fault isn’t really OpenWrt that doesn’t do iptables, it is the packages that doesn’t do nftables.

13

Master.

Absolutely true.
But either this particular issue is an oversight, or it is a deliberate move to make such packages to some degree unusable.

Most other Linux distributions go all out to make iptables support as transparent as possible in the nftables environment. Does this make OpenWrt a leader in the deprecation process of all things iptables?

Either way, efforts to rework packages that use iptables should be given a top priority by their respective developers.

I guess that one way to encourage such reworking is to discuss it more and more on this forum and get people talking about it.

14

Some one need to be pioneers!:smiley:
Wasn’t it Linus Torvalds that made nftables the no1 solution in to the future in the kernel?
And the DSA!
And Wireguard…

Maybe but these discussions are mostly decided in the mailing list and pull requests in Git hub.
http://lists.openwrt.org/pipermail/openwrt-devel/
This is the prize we pay to be on the dev front line. And if you use master then you are on the very edge of the development frontline.

15

Unfortunately unless you are actively following threads continuously, you may not notice what is going on until it is too late. In addition, with mailing lists, it is often the case that comments by "outsiders" are ignored or at best discouraged. Although I must say I don't know if it is the case here.

The same goes for PRs on Github. Team members get notifications, others do not unless you spot the PR and make a comment. It is often the case that the first time people find out that a PR has been merged is when something stops working (as in this case of dnsmasq-full).

The advantage of this forum is that it is easily accessible to everyone, not just the core OpenWrt development team.

16

Yes. And not to mention you can’t search the mail database. You have to find “something” by pure luck by reading all mail. And mail aren’t answering in chronological order so it quickly gets a mess to fallow!

Yes. It is also another problem with PR. The volume! No one has the energy to go through them all, everyone interested has their favorite tags they fallow that makes some meaning to them. But the OpenWrt database is the base OpenWrt. And then we have Luci, packages also to keep up with. And the actual kernel dev history.

Maybe, my feeling is that most of the dev have pretty low forum time compared to the time spent in the git hub and mail. I can pretty much guarantee a new functions be or not to be will never be discussed in this general forum. This is only support forum. Not even in the dev section will these discussions be.

17

Dude. Nftables is around since 2012 or something. In 2016 it was announced that most netfilter stuff ia ported to nftables in the kernel already and that iptables is just a user space wrapper but the kernel already processed as netfilter anyway. also it was not Linus but Pablo who coordinate netlink and it was spelled out more then once in the last ten years that iptables will see it's sunset.
If people simply ignore the processing and warning through years then you can't help them. It is no news that nftables and nft is the modern way to handle filtering. Also the netfilter working group did a really good job to make the delayed transition as easy and convenient as possible.

18

So 10years, that is like amazing new gadgets we have here. As I said, it is a hard work being pioneers!

19

But less than 12 months on OpenWrt.......
Before 22.03, we could not convert our packages.

1 Like
20

While I agree the ipset support should be included in dnsmasq-full package, I just searched the packages repo for "ipset" and (outside of pbr, which supports it, but where it's not a hard dependency) it's pretty much just 3 packages which mention it -- banip, crowdsec-firewall-bouncer and mwan3, so I see how the decision has been made.