Opkg doesn't know about packages `nftables` and `libnftnl` - where are they?

#1

QUESTION REMOVED

The packages I was looking for weren't compiled for the particular target

/18.06.2/targets/brcm2708/bcm2710/packages/

I was using.

#2

Run opkg update first, nftables and its dependencies aren't target specific, but generic to aarch64_cortex-a53 (and they appear to be present and accounted for).

1 Like
#3

Thanks! Seems like it installed now.

(I could swear that opkg update and opkg upgrade were the first things I did after installation - but I could be wrong).

#4

You should never run opkg upgrade, there are no strong ABI checks and dependencies in place[1] between executables and their dependencies (libraries) - upgrading the whole lot contains a very significant chance of the system exploding spectacularly.

[1] a side effect of OpenWrt's primary development target of extremely resource (flash-) constrained systems and the realities of a small development team.

2 Likes
#5

Can't this also be a problem when using okg install since the package(s) to be installed might depend on a library that's already installed. In case the ABI of the library has changed the device and archive may have a library package with different ABI versions.

1 Like
#6

Yes (and it will, if you're using snapshots with a heavily outdated base image - stable releases less so), but the risks are slightly lower.

1 Like
#7

Please don't edit original questions after people have replied to them, as this makes the topic hard to understand and not very useful for future readers.

If you need to add clarification, you can simply include it in a reply.

2 Likes
#8

Hi Craig,

Good spot. Suggest you update the instructions, saying some packages may
well already be installed.

I know when I set up nftables, I didn't have everything I needed
installed - so I just collected a list of what I needed and installed.
Not sure if I missed the kernel modules, or not.

In the write up I just listed everything I needed to use.

Guess I should have checked closer.

Anyway hope you get nftables to work.

Regards,

David.

1 Like
#9

@mhegab - Your thinking is correct. However, I had given up and got as close to deleting the question as I could - THEN a reply arrived. And the reply was in response not to the original question but the edited stump you see above.

It was "lucky" for me that @slh saw the edited stump, because I think it resulted in a faster path success (installing pre compiled packages vs. compiling more packages.) Life and development are complicated. Sometimes you take a wrong turn and get to the right destination.

Nevertheless, your statement is absolutely correct.

#10

The strange thing is that with the "official" Openwrt RPi3 18.06.2 image, there are several kmod_nf*.ko fmodules loaded in the kernel visible with lsmod. After following @slh 's advice (update/install) I could install nftables and libnftd, but after that the kmod_nf*.ko modules had disappeared. Not anywhere in the file system either.

At that point nftables still wasn't working, and I guessed (incorrectly) that it was because the kmod_nf*.ko modules had disappeared. To try and fix that I opkg removed every kmod_nf* and kmod_ip* package and reinstalled the kmod_nf* packages. In the course of that operation I had to remove the dependency chain:

  • kmod_ipt_nat
  • firewall
  • luci-app-firewall
  • luci

After reinstalling the all the kmod_nf* packages, the kmod_nf*.ko modules still were not present, but nftables was working. I think the blockage was in the kmod_ipt_nat dependency chain, which you mentioned briefly in your other posting.

So now nftables is working.

Something not clear to me now is how to run both iptables and nftables on openwrt. I never succeeded, and ended up going straight to nftables only. I suspect the presence ofkmod_nf*.ko modules make the dual iptables and nftables possible.

At this point I also suspect a nftables only setup is possible with a RPi3 build compiling no nftables packages at all. Maybe that could exist as a separate build.

Presently there are too many uncertainties in my understanding to update instructions with certainty.

#11

Problem is you can't run iptables and nftables at the same time - you need to choose which you want to use. now iptables and nftables are really compatible, especially when it comes to NAT. So I think what is best when switching to use nftables, is just to remove all mention of iptables. So in the above, kmod_ipt_nat is probably causing problems.

I've just checked my overlay directory. Full list of what I removed:

c---------    1 root     root        0,   0 Oct 15  2018 ip6_tables.ko
c---------    1 root     root        0,   0 Oct 14  2018 ip6t_REJECT.ko
c---------    1 root     root        0,   0 Oct 14  2018 ip6table_filter.ko
c---------    1 root     root        0,   0 Oct 14  2018 ip6table_mangle.ko
c---------    1 root     root        0,   0 Oct 15  2018 ip_tables.ko
c---------    1 root     root        0,   0 Oct 14  2018 ipt_MASQUERADE.ko
c---------    1 root     root        0,   0 Oct 14  2018 ipt_REJECT.ko
c---------    1 root     root        0,   0 Oct 14  2018 iptable_filter.ko
c---------    1 root     root        0,   0 Oct 14  2018 iptable_mangle.ko
c---------    1 root     root        0,   0 Oct 14  2018 iptable_nat.ko
c---------    1 root     root        0,   0 Oct 14  2018 nf_log_common.ko
c---------    1 root     root        0,   0 Oct 14  2018 nf_log_ipv4.ko
c---------    1 root     root        0,   0 Oct 14  2018 nf_log_ipv6.ko
c---------    1 root     root        0,   0 Oct 15  2018 x_tables.ko
c---------    1 root     root        0,   0 Oct 14  2018 xt_CT.ko
c---------    1 root     root        0,   0 Oct 14  2018 xt_LOG.ko
c---------    1 root     root        0,   0 Oct 14  2018 xt_REDIRECT.ko
c---------    1 root     root        0,   0 Oct 14  2018 xt_TCPMSS.ko
c---------    1 root     root        0,   0 Oct 14  2018 xt_comment.ko
c---------    1 root     root        0,   0 Oct 14  2018 xt_conntrack.ko
c---------    1 root     root        0,   0 Oct 14  2018 xt_limit.ko
c---------    1 root     root        0,   0 Oct 14  2018 xt_mac.ko
c---------    1 root     root        0,   0 Oct 14  2018 xt_mark.ko
c---------    1 root     root        0,   0 Oct 14  2018 xt_multiport.ko
c---------    1 root     root        0,   0 Oct 14  2018 xt_nat.ko
c---------    1 root     root        0,   0 Oct 14  2018 xt_state.ko
c---------    1 root     root        0,   0 Oct 14  2018 xt_tcpudp.ko
c---------    1 root     root        0,   0 Oct 14  2018 xt_time.ko

1 Like
#12

Yes, I agree from a practical point of view, and in practice I removed iptables completely. Now nftables is functioning well.

Nevertheless, some level of dual use is possible although apparently it is either/or with regards to NAT. There is lots of documentation about gently switching with some level of dual use transition, which Is important for certain use cases. (Lots of docs and yet not complete and specific enough information to make the gentle switch method simple [and gentle] - it happens.)

#13

Until LuCI and the “stock” firewall transition to nftables, the dependency chains make it nearly impossible to rid an image of iptables. It can be nearly done in a custom-built image without LuCI, but isn’t for everyone yet. Blacklisting of kernel modules may help further, but I have not pursued that yet.

(I much prefer nftables, but don’t run NAT on any of my “live” OpenWrt instances and configure and run without LuCI.)

1 Like
#14

I agree with your main point but believe that "an be nearly done in a custom-built image without LuCI" is incorrect, based on my experience as described above following @slh 's advice:

" Run opkg update first, nftables and its dependencies aren't target specific, but generic to aarch64_cortex-a53 (and they appear to be present and accounted for)."

I started with a custom image that had some nftables packages included. It didn't work and I undid that by removing all kmod_ip* and kmod_nf* packages and all their dependencies, then reloading every kmod_nf* as well as nftables and libnftd. I believe these reloaded packages all came from the generic aarch64 build repo and not the Rpi3b+ specific build repo.

In short,
(1) first remove any ip related packages and all their dependencies,
(2) remove the nft packages to ensure that any custom specific build libs with differnt ABI nums don't interfere.
(3) Then install all the nftables packages, which by default should come from the most generic repository for the target architecture.

#15

My imprecision -- I only build images from source. As such, there is no question about API/ABI incompatibilities.

#16

I'm very impressed. I suppose you have fewer compatibility problems that way.

closed #17

This topic was automatically closed 10 days after the last reply. New replies are no longer allowed.