I’m asking because with the release of Nethsecurity 8.7.2 more functionality (live flows) depend on netifyd. I cloud try to build Nethsecurity with netifyd 5.x.x from the public sources published on the Netify Gitlab. However, I think that’s not going to help much, the Flow Actions Processor Plugin seems to be closed source.
From the netify website:
This guide covers installation of Netify Agent v5 for OpenWrt on x86 architecture. If you require support for ARM, MIPS, or other hardware platforms, please contact us - we have additional builds available for many targets.
Could contact them directly but I guess they do not give de closed source builds to me.
Aggregator Plugin, which is found in “Top Talkers” tab, and down on the line will replace even the handmade one we’ve built for the “Daily Traffic” tab, both in the Monitoring section
There are some rumors the precomplied binaries for netifyd v5.x are in the making.
So lets hope those rumors are true.
To be frank, I kind of paused the (back)port to ARM64 awaiting a solution for netifyd. Did some research compiling netifd 5.x from the open sources in the (Openwrt) build tree, but haven’t figured this out yet. Again, fingers crossed.
Out of curiosity, which ARM64 hardware are you aiming for?
To my understanding it’s because of the integration in their automated workflow (CI), which is feasible because you do not want to create a manual build for ARM64 every update.
Nethsecurity is still on the Openwrt 24.x branch but in time it most certainly goes to 25.x.
However the binaries have arrived and are hosted in the nethsecurity testing repositories.
Even if needs some further coordination on aarch/target names, a first test build (8.8.0 beta-1 based on openwrt 25.12.4) for the 64 bit armsr target succeeded including netifyd-5.2.8.
Still need to install and test the results and foremost dive in to {signing, serving} apk- instead of ipk packages.
Here are the test build results / changes:
(links could be short lived due to further development)
I’ve already published the fixed package as Mark was hinting, since I’ve spotted an issue with netifyd 5.2.8, that upstream devs quickly fixed. Also mark found out an issue with the initial build of netifyd for arm, which it’s addressed.
The armsr image booted out of the box as a (emulated) qemu-vm; first boot wizard worked fine and no more missing /etc/config/dpi as we have the fully fledged nethifyd on aarch64:
root@NethSec:/etc/config# cat dpi
config main ‘config’
option log_blocked ‘0’
option enabled ‘1’
option firewall_exemption ‘0’
list popular_filters ‘netify.facebook’
list popular_filters ‘netify.amazon-prime’
list popular_filters ‘netify.whatsapp’
list popular_filters ‘netify.instagram’
list popular_filters ‘netify.netflix’
list popular_filters ‘netify.telegram’
list popular_filters ‘netify.tiktok’
list popular_filters ‘netify.youtube’
list popular_filters ‘netify.facebook-messenger’
list popular_filters ‘netify.twitter’
list popular_filters ‘netify.vimeo’
list popular_filters ‘netify.snapchat’
list popular_filters ‘netify.pinterest’
list popular_filters ‘netify.nordvpn’
list popular_filters ‘DoT’
list popular_filters ‘netify.twitch’
list popular_filters ‘netify.teamviewer’
list popular_filters ‘DoH’
config rule ‘ns_bcc7c4a6’
option enabled ‘1’
option device ‘br-lan’
option action ‘block’
list application ‘netify.facebook’
list application ‘netify.amazon-prime’
list application ‘netify.instagram’
list application ‘netify.twitch’
list application ‘netify.pinterest’
list application ‘netify.twitter’
list application ‘netify.tiktok’
list application ‘netify.netflix’
list application ‘netify.youtube’
list application ‘netify.vimeo’
list application ‘netify.snapchat’
list protocol ‘DoT’
list protocol ‘DoH’
So no more choking of pyrhon3-nethsec when creating “objects” such as DNS records.
Still need to iron out a few wrinkles such as a custom URL for the package repository Speaking of which: kudos the arch isn’t hard-coded in the feeds list any more.
Also need to do some real life testing…anyways so far so good
EDIT:
For real life testing installed my custom 8.8.0-beta1 on my daily driver the Nanopi R5S:
To be frank I thought is was becoming not feasible to run Nethsecurity on arm devices… but most definitely the opposite happened.
Besides 2 missing build dependencies (python3-dev / python3-pyelftools) for Uboot only the ns-storage package is stubborn.
Already knew ns-storage can not handle the partition naming scheme of SD-cards and eMMC’s which is similar to nvme’s: partitions are numberd px in stead of just a number (x)
mmcblk0 179:96 0 29.7G 0 disk ├─mmcblk0p1 179:97 0 16M 0 part ├─mmcblk0p2 179:98 0 300M 0 part /rom └─mmcblk0p3 179:99 0 29.3G 0 part /mnt/data
addressed this issue in this commit:
Recently at removal of a permanent storage finding the rootfs / rom partition has changed. Unfortunately now we are looking for the boot-partition instead of the rom-partition. As one can see in the partition scheme above, booting with uboot we do not have a (fat32) boot-partition
Also found a bug in the recently introduced permanent storage of dhcp-leases, the call to get path to the dhcp-lease file in list_active_leases has one argument to much (second " dhcp"):
Apologies I missed this;
I did a git grep ; missed it as the euci class is initialized as uci instead of u
I wonder if the changes I propose to the ns-storage package can be accepted;
If so i’m going to test them extensive on x86_64 VM’s and hardware;
to open a PR on a pass
I’m cautiously optimistic as some issues are getting addressed in the main codebase. So by the upcoming release some tweaks/modifications can be dropped.
Not sure I official support will ever materialize, but who knows what the future will bring (even proxmox has an official arm64 repository now)
A community based form of support should be possible;
Meanwhile using nethsecurity on aarch64 as a daily-driver since I opened this thread a year ago. As an opensource adept (and to be sure I do not violate any Licenses) I publish all modifications I made and host the results.
