BACKUP branch: interface_configure() after unsetting enable is a no-op #17

New issue

Closed

opened 2026-10-22 17:36:11 -07:00 by eric · 0 comments

eric commented

2026-10-22 17:36:11 -07:00

Owner

Summary

In the BACKUP branch, the interface_configure() call that follows unset($config['interfaces'][$ifkey]['enable']) returns immediately and does nothing. The comment and dry-run text suggest it does real work.

Where

10-wancarp, BACKUP branch (around lines 789–799):

interface_reset($ifkey);                        // tear down current config
unset($config['interfaces'][$ifkey]['enable']); // in-memory only (not persisted)
interface_configure(false, $ifkey, true, false);

and the dry-run line "DRYRUN: would interface_reset('{$ifkey}'), unset enable (in-memory), interface_configure(), ifconfig {$realif} down."

Why it's a no-op

Current OPNsense core (src/etc/inc/interfaces.inc, interface_configure()) begins with:

$wancfg = config_read_array('interfaces', $interface, false);
...
if (!isset($wancfg['enable'])) {
    return $loaded;
}

config_read_array() reads the global $config (config.inc), so after the unset the function returns before the $reload handling or anything else.

Fix

Either:

remove the unset + interface_configure() lines and update the dry-run message and any header/README text that lists it (README "On BACKUP: resets each interface, forces the link down, ..." is already accurate), or
if there's a reason to keep it (e.g. older OPNsense releases behaved differently), add a comment saying it's a no-op on current OPNsense.

Before removing it, check that nothing later in the same process relies on enable being unset in memory. Nothing in this script does, but interface_reset() and system_routing_configure() read $config. Keeping only the unset (to stop in-process routing code from treating WAN as enabled) is a reasonable middle ground.

Acceptance

php -l passes; behaviour unchanged on a live BACKUP transition (WAN down, result=ok).
CHANGELOG [Unreleased] entry.

## Summary In the BACKUP branch, the `interface_configure()` call that follows `unset($config['interfaces'][$ifkey]['enable'])` returns immediately and does nothing. The comment and dry-run text suggest it does real work. ## Where `10-wancarp`, BACKUP branch (around lines 789–799): ```php interface_reset($ifkey); // tear down current config unset($config['interfaces'][$ifkey]['enable']); // in-memory only (not persisted) interface_configure(false, $ifkey, true, false); ``` and the dry-run line `"DRYRUN: would interface_reset('{$ifkey}'), unset enable (in-memory), interface_configure(), ifconfig {$realif} down."` ## Why it's a no-op Current OPNsense core (`src/etc/inc/interfaces.inc`, `interface_configure()`) begins with: ```php $wancfg = config_read_array('interfaces', $interface, false); ... if (!isset($wancfg['enable'])) { return $loaded; } ``` `config_read_array()` reads the global `$config` (`config.inc`), so after the `unset` the function returns before the `$reload` handling or anything else. ## Fix Either: - remove the `unset` + `interface_configure()` lines and update the dry-run message and any header/README text that lists it (README "On BACKUP: resets each interface, forces the link down, ..." is already accurate), or - if there's a reason to keep it (e.g. older OPNsense releases behaved differently), add a comment saying it's a no-op on current OPNsense. Before removing it, check that nothing later in the same process relies on `enable` being unset in memory. Nothing in this script does, but `interface_reset()` and `system_routing_configure()` read `$config`. Keeping only the `unset` (to stop in-process routing code from treating WAN as enabled) is a reasonable middle ground. ## Acceptance - `php -l` passes; behaviour unchanged on a live BACKUP transition (WAN down, `result=ok`). - CHANGELOG `[Unreleased]` entry.

eric added the

enhancement

label

2026-10-22 17:36:11 -07:00

eric referenced this issue from a commit

2026-10-23 15:41:12 -07:00

fix: drop the no-op interface_configure() from the BACKUP branch

eric closed this issue

2026-10-23 15:41:12 -07:00

eric referenced this issue

2026-10-23 15:42:47 -07:00

Release test plan: live checks before tagging the next release #21