Keenetic
Requirements
- Keenetic router with OPKG support
- Entware installed (required)
Install Entware
Newer models (with built-in storage)
- The router web interface is opened
- Section System settings
- The OPKG package manager component is enabled
Older models (USB drive required)
- A USB drive is attached to the router
- Entware is installed through the package manager
More details: help.keenetic.com
Netfilter components
Keenetic NDMS does not ship all the netfilter kernel modules b4 needs out of the box. The required components have to be enabled before b4 is installed:
- In the router web interface: System settings → Component options
- Netfilter - the base netfilter component - is enabled
- Once Netfilter is enabled, a new option appears: Xtables-addons for Netfilter (provides
xt_connbytesand other extensions b4 relies on) - The changes are applied, followed by a router reboot or a component reload
Then, over SSH, the iptables userspace is installed:
opkg install iptables
Install b4
Over an SSH connection to the router:
curl -fsSL https://raw.githubusercontent.com/DanielLavrushin/b4/main/install.sh | sh
Service control
/opt/etc/init.d/S99b4 start
/opt/etc/init.d/S99b4 stop
/opt/etc/init.d/S99b4 restart
Paths
| What | Where |
|---|---|
| Binary | /opt/sbin/b4 |
| Configuration | /opt/etc/b4/b4.json |
| Service | /opt/etc/init.d/S99b4 |
Architecture
- Older models (MT7621) -
mipsle_softfloat - Newer models (aarch64) -
arm64
The installer detects the architecture automatically.
Without Entware, b4 is placed in /tmp, which is cleared on every reboot. For persistent operation, Entware is required.
Firewall rewrites
NDMS rebuilds its netfilter tables on its own schedule: a UPnP port mapping renewal, a WAN reconnect, a change to a policy or a component. Each rebuild drops the chains it does not own, including those of b4, and then runs every script under /opt/etc/ndm/netfilter.d/ with the table name in $table and the family in $type.
The installer places 50-b4.sh in that directory. The script sends SIGUSR1 to the running b4 process, which re-checks its rules as soon as the rebuild settles and restores what is missing. Without the hook, the tables monitor still restores the rules on its next poll, which is up to system.tables.monitor_interval seconds later (10 by default).
The rules of the Expose to internet switches sit in the filter table, which NDMS rewrites as well, and are re-checked on the same signal and at the same interval. b4 logs putting them back at the WARN level as Expose: the rules opening ... were missing from ..., usually after the firewall was reloaded; restored them, whether the hook or the poll found them missing, so that line follows a rewrite even when the hook works.
A rewrite announced by the hook leaves Tables rules missing after a firewall rewrite, restoring... followed by Tables rules restored successfully in the log, at the INFO level. The same line at the WARN level, without the rewrite wording, means the poll found the rules gone with no signal from the hook: either the hook is missing or something other than NDMS removed them. The same re-check can be requested by hand:
kill -USR1 $(cat /var/run/b4.pid)
In TUN mode the signal also makes the TUN engine re-check its capture chain B4_TUN and the jumps into it at once. The engine logs a rebuilt chain at the WARN level as TUN: capture chain B4_TUN lost N of M rules (removed outside b4) ..., whether the hook or the poll found it, and the tables monitor's lines cover only the masquerade, MSS clamp, DSCP and routing-set rules. The poll interval in this mode is at least 10 seconds.
Troubleshooting
After the service starts, the log is worth checking:
cat /var/log/b4/errors.log
The line xt_connbytes kernel module is not available means the Netfilter components were not enabled correctly - see Netfilter components above, where both Netfilter and Xtables-addons for Netfilter have to be active.
If the log is empty (or has no errors), the b4 web interface should be reachable on the router's LAN IP.