The wi-fi architecture in infix require udev to run and remove the kernel automatic wlan-interface
this. Unclear reason, but it seems that udev sometimes miss the add event.
This is a decision right now, that we support multi ssid AP, but
only one station interface, this is the only thing the c-code support
right now, so only allow this in the yang validation.
Service descriptions or command arguments may contain special characters
that need to be escaped in JSON strings.
Example:
{
...
"command": "udhcpc -f -p /run/dhcp-client-wan.pid -t 3 -T 5 -A 30 -a1000 -S -R -o -O 1 -O 3 -O 6 -O 12 -O 15 -O 28 -O 42 -i wan -V "NanoPi R2S"",
...
}
Also, wrap add_services() in a try/except instead of testing for keys.
Signed-off-by: Joachim Wiberg <troglobit@gmail.com>
The table_width() class method was lost in b826bcb9d, so we take the
opportunit to refactor to SimpleTable.
Signed-off-by: Joachim Wiberg <troglobit@gmail.com>
Verified with latest Finit 4.15 that reboot after resize works.
Added a comment to the board-specific .mk file about the broken
WDT on the RK3328 SoC, or rather the NanoPi R2S board.
Fixes#1292
Signed-off-by: Joachim Wiberg <troglobit@gmail.com>
Board probing cannot copy board specific files to /usr (read-only), so
let's share this script with all other aarch64 boards.
Signed-off-by: Joachim Wiberg <troglobit@gmail.com>
When interfaces were moved from firewall zones to become bridge or LAG
ports (e.g., sfp1/sfp2 moved from WAN zone to lan-br), the firewall
configuration was not regenerated. This caused stale entries in
/etc/firewalld/zones/*.xml where interfaces remained listed in their
old zones despite no longer being L3 interfaces.
Root cause: firewall_change() only triggered on firewall model changes,
but interface membership changes (bridge-port/lag-port) occur in the
ietf-interfaces model. When interfaces become member ports, they
transition from L3 to L2, which affects the result of
interfaces_get_all_l3() used for default zone assignment.
Fix: Expand the diff check to also trigger firewall regeneration when
bridge-port or lag-port configuration changes, ensuring firewall zones
stay synchronized with actual L3 interface topology.
Fixes#1345
Signed-off-by: Joachim Wiberg <troglobit@gmail.com>
When users modified firewall zone services (e.g., enabling SSH on WAN),
firewalld.conf would disappear from /etc/firewalld/, causing firewalld
to fail with "Failed to load '/etc/firewalld/firewalld.conf': [Errno 2]
No such file or directory".
Root cause: After switching to the "roll in" staging directory approach
late in development, firewalld.conf generation was still conditional on
changes to "default" or "logging" settings. When other changes (zones,
services, policies) were made:
1. Code created /etc/firewalld+/ staging directory
2. Skipped generating firewalld.conf (no default/logging in diff)
3. On commit: rm -rf /etc/firewalld (deleted firewalld.conf!)
4. Renamed /etc/firewalld+ → /etc/firewalld (incomplete config)
Fix: Always generate firewalld.conf whenever firewall configuration is
being staged, not just for default/logging changes.
Fixes#1346
Signed-off-by: Joachim Wiberg <troglobit@gmail.com>
Replace BusyBox udhcpc6 with OpenWrt's odhcp6c for improved DHCPv6
functionality and better integration with Router Advertisements (RA).
The primary motivation is support for a common ISP deployment scenario
where IPv6 addresses are assigned via SLAAC (from Router Advertisements)
and DHCPv6 is used in stateless/information-only mode to provide DNS
servers and other configuration options. This hybrid RA+DHCPv6 setup is
standard practice for many ISPs but was not supported by udhcpc6, which
treats RA and DHCPv6 as separate, non-integrated mechanisms.
Additional benefits of odhcp6c:
- Better IPv6 Prefix Delegation (IA-PD) support with proper handling
of delegated prefix lifetimes and renewal
- Native integration of RA-provided configuration (DNS servers, routes,
addresses) with DHCPv6-provided options
- Support for stateless DHCPv6 via information-only mode
To verify stateless DHCPv6 integration with SLAAC addresses - the ISP
scenario that motivated this migration, a new test case has been added.
Signed-off-by: Joachim Wiberg <troglobit@gmail.com>
Almost full support for WireGuard
admin@server:/> show interface wg0
name : wg0
type : wireguard
index : 10
mtu : 1420
operational status : up
ipv4 addresses : 10.0.0.1/24 (static)
ipv6 addresses : fd00::1/64 (static)
peers : 2
Peer 1:
public key : ROaZyvJc5DzA2XUAAeTj2YlwDsy2w0lr3t+rWj2imAk=
status : UP
endpoint : 192.168.10.2:51821
latest handshake : 2025-12-09T22:51:38+00:00
transfer tx : 1412 bytes
transfer rx : 1324 bytes
Peer 2:
public key : Om9CPLYdK3l93GauKrq5WXo/gbcD+1CeqFpobRLLkB4=
status : UP
endpoint : 2001:db8:3c4d:20::2:51822
latest handshake : 2025-12-09T22:51:38+00:00
transfer tx : 1812 bytes
transfer rx : 428 bytes
in-octets : 1752
out-octets : 3224
admin@server:/>
This is described on the internet as:
"If you are unlucky and have a device with wrong MAC address,
too bad"
For us: We set mac addresses static, and do not use hostapds, insane
MAC address allocation (radio MAC + n).
ael-bot