Thanks, I like problems that are solved while I sleep ... 
Edit: the typo is fixed in my dev version, too.
3 Likes
When do you sleep helpful hand? 
Update with the typo fix is in master with this commit:
3 Likes
on 1.5.0-r4 after flag tcp udp 80 443 is applied to outbound. the outbound feeds no longer work.
Set details
Set Count Inbound (packets) Outbound (packets) Port / Protocol Elements
cinsscore.v4 12253 ON: (0) - - -
debl.v4 14550 ON: (0) - - -
doh.v4 1756 - - - -
turris.v4 8502 ON: (3) - - -
hagezi.v4 81838 - - - -
Anything in the logs?
Nothing in the processing logs.
reverting to 1.5.0-r3 and all back to normal.
If you don't see any processing errors, than it's only a reporting glitch. The firewall entries will be set correctly.
cool. i will test and feedback if other wise.
Reporting issue fixed in 1.5.0-5:
3 Likes
I'm getting the following errors for feeds tagged with "Outbound"..
Mon Jan 27 10:59:45 2025 kern.warn kernel: [ 108.454065] percpu: allocation failed, size=16 align=8 atomic=1, atomic alloc failed, no space left
Mon Jan 27 10:59:45 2025 kern.info kernel: [ 108.454331] percpu: limit reached, disable warning
I will investigate further
Update #1
To test.. only enabled DOH on the feed and here is the snippet of the log
Mon Jan 27 11:12:23 2025 user.debug banIP-1.5.0-r5[5584]: f_nftload ::: file: tmp.igpkjN.allowlist.v6.nft, load_rc: 0, cnt: 1, max_cnt: 5
Mon Jan 27 11:12:23 2025 user.debug banIP-1.5.0-r5[5584]: f_down ::: feed: allowlist.v6, policy: inout, complete: -, cnt_dl: 28, cnt_set: 10, split_size: 16384, time: 0, rc: 0
Mon Jan 27 11:12:23 2025 user.debug banIP-1.5.0-r5[5584]: f_restore ::: feed: doh.v6, file: banIP.doh.v6.gz, in_rc: -, rc: 0
Mon Jan 27 11:12:23 2025 user.debug banIP-1.5.0-r5[5584]: f_restore ::: feed: doh.v4, file: banIP.doh.v4.gz, in_rc: -, rc: 0
Mon Jan 27 11:12:23 2025 kern.warn kernel: [ 48.629391] percpu: allocation failed, size=16 align=8 atomic=1, atomic alloc failed, no space left
Mon Jan 27 11:12:23 2025 user.debug banIP-1.5.0-r5[5584]: f_nftload ::: file: tmp.igpkjN.doh.v6.nft, load_rc: 0, cnt: 1, max_cnt: 5
Mon Jan 27 11:12:23 2025 kern.warn kernel: [ 48.727505] percpu: allocation failed, size=16 align=8 atomic=1, atomic alloc failed, no space left
Mon Jan 27 11:12:23 2025 user.debug banIP-1.5.0-r5[5584]: f_down ::: feed: doh.v6, policy: out, complete: -, cnt_dl: 1811, cnt_set: 1219, split_size: 16384, time: 0, rc: 0
Mon Jan 27 11:12:23 2025 user.debug banIP-1.5.0-r5[5584]: f_nftload ::: file: tmp.igpkjN.doh.v4.nft, load_rc: 0, cnt: 3, max_cnt: 5
Mon Jan 27 11:12:23 2025 user.debug banIP-1.5.0-r5[5584]: f_down ::: feed: doh.v4, policy: out, complete: -, cnt_dl: 2508, cnt_set: 1753, split_size: 16384, time: 0, rc: 0
So far, only feeds as tagged as "out" or "inout" have this error... still doing some further invetigation.. currently with ban_nftcount set to '1'
Update #2
After a reboot, error is not always showing after a "reload" or "restart" of banip
Update #3
- Changed
ban_nftcountto0
Still getting the error, but it's a hit/miss thing.. i've been doing "restart" or "reload" every 2 mins, and error doesn't always get triggered.
I don't know the exact parameters/scenario when or why the error is being triggered.
By the way, I'm testing it on an x86 VM before actually using the changes on my routers.
Just ignore the error, it is a known error when loading the nft set when the counters are activated. The error is not deterministic and is related to the exclusive memory requirements of nft when loading the sets (with counters). As a workaround, the loader in banIP simply tries again (5 times by default). This is the main reason not to backport banIP 1.5.x to 23.x, because the kernel is too old.
Hopefully this get fixed one day with a newer kernel/nft version.
4 Likes
Ok thanks..
Thanks for the great work on this project. Hoping to test the latest 24.10 compatible build once gl-inet update to op24 from the Flint 2.
One small favour. Would it be possible to put the date next to the change log release versions? Thanks.
1 Like
It's compatible with the op24 build. I've got it in my Flint 2 and Beryl AX (both using op24 build). You can use the IPK files from openwrt and install the luci-app and main package manually.
2 Likes
I'm using a couple of feeds, including doh. There are some websites, like dbrand.com, that share an ip with a doh-server in that feed, so I put those websites in the allowlist. This used to work fine, but since 1.5.0, it seems that after a reload the allowlist gets ignored. If I do a restart the allowlist works again. Is this expected or a bug? Should I put a restart in my daily cron instead of a reload now?
Thanks for the great work!
I've got 3 routers using BanIP and doh is one of the feeds enabled on all 3 of them. I know the issue with dbrand.com which is also the same issue with tailscale.com.
I've got tailscale.com added to my Allowlist and i'm using daily reload for banip. I haven't had the same issue as yours and I can access tailscale.com.
Did you check the logs on the reload? maybe there is some error when the reload is triggered.
Update: tailscale.com and dbrand.com uses the smae IP address. I can access both sites. Below is how it looks like (just a snippet) on my /etc/banip/banip.allowlist (the IP's are auto-generated by banip)
tailscale.com
76.76.21.21 # 'tailscale.com' added on 2024-10-14 11:10:34
2600:9000:a602:b1e6:5b89:50a1:7cf7:67b8 # 'tailscale.com' added on 2024-10-14 11:10:34
2600:9000:a51d:27c1:6748:d035:a989:fb3c # 'tailscale.com' added on 2024-10-14 11:10:34
1 Like
You're right, I'm getting the following errors in the log:
Sun Feb 2 12:00:15 2025 user.info banIP-1.5.0-r5[28770]: start banIP download processes
Sun Feb 2 12:00:32 2025 user.info banIP-1.5.0-r5[28770]: can't load initial file to nfset 'doh.v6', /tmp/tmp.BbeCdC/tmp.LlEefC.doh.v6.nft:4:23-28: Error: Could not process rule: Resource busy delete set inet banIP doh.v6 ^^^^^^
Sun Feb 2 12:00:32 2025 user.info banIP-1.5.0-r5[28770]: can't load initial file to nfset 'doh.v4', /tmp/tmp.BbeCdC/tmp.LlEefC.doh.v4.nft:4:23-28: Error: Could not process rule: Resource busy delete set inet banIP doh.v4 ^^^^^^
If I try to execute the failed files in /tmp/banIP-error manually I get the same error:
medina /tmp/banIP-error # nft delete set inet banIP doh.v4
Error: Could not process rule: Resource busy
delete set inet banIP doh.v4
^^^^^^
Looks like it might be more a problem with the firewall or nftables than with banip itself?
It's odd that it does work fine if I do a restart instead of a reload. Then the doh.v4 and doh.v6 sets are deleted and recreated fine.
Not sure.. what's your current openwrt version? Can also be problems with the router itself. What's your router, and how much memory does it have?
1 Like
It's 24.10.0-rc7, running on a NanoPi R5C, 4 GB of RAM and plenty still free during the reload.