Skip to content

The network page works on any bridge layout

A board whose interfaces file was split by hand into two bridges, with no br0, showed no address and failed every change with a bare 500. The page now finds the address on whatever interface carries it, says what it is looking at, and replaces a hand-written file only after you confirm, keeping a copy.

Firmware v2.45.0, 31 October 2026 — the first image to carry bmcd 2.41.0, BMC-UI 4.2.0. Every item below is the repository's own changelog entry, taken apart; the whole entry is a click away under each one.

The network page assumed the board's only bridge is br0. A user report on Discord came from a board whose /etc/network/interfaces was split by hand into br-wan and br-lan, with no br0: the page showed no address, every change failed with a 500, and tpi info printed "Unknown" for the IP.

The Network page tells a board without br0 what it is looking at

Section titled “The Network page tells a board without br0 what it is looking at”

BMC-UI 4.2.0

It manages br0 only; on a board without it the card is read-only and says so, lists the interfaces the board has, and points to SSH (or the default layout) for changes.

Every interface, with its addresses, MAC and default route,

Section titled “Every interface, with its addresses, MAC and default route,”

BMC-UI 4.2.0

Listed read-only under the address form.

A hand-written interfaces file is replaced only after you agree

Section titled “A hand-written interfaces file is replaced only after you agree”

BMC-UI 4.2.0

The card explains that a confirmed change replaces the whole file and keeps a copy as /etc/network/interfaces.hand-written.<time>, asks before applying, and afterwards says where the old file was kept.

The demo can show these layouts: ?layout=split (no br0) and

Section titled “The demo can show these layouts: ?layout=split (no br0) and”

?layout=handwritten (a hand-written file), with documentation addresses BMC-UI 4.2.0

Unit tests for the card's decisions (npm test now runs every

Section titled “Unit tests for the card's decisions (npm test now runs every”

src/lib/api/*.test.mjs) BMC-UI 4.2.0

Reported by a user on Discord.

  • The dashboard, the Network page and tpi info work on any bridge layout. The board's address is read from its primary interface: br0 when it exists and has an address, otherwise the interface holding the default route, otherwise the first up interface with a global IPv4 address.

    The whole entry

    The dashboard lists each interface with an address (default route first), and the Network page lists every interface with its addresses, MAC and default route, read-only.

  • A board without br0 gets an explanation, not a 500. The Network page manages br0 only; on a board without it the card is read-only, says so, lists the interfaces the board has and points to SSH for changes.

    The whole entry

    The daemon refuses the change with a clear message and touches nothing.

  • A hand-written /etc/network/interfaces is replaced only after you agree. The card explains that a confirmed change replaces the whole file and asks first; the old file is kept as /etc/network/interfaces.hand-written.<time> (the newest five copies), and the page says where.

    The whole entry

    If the copy cannot be made, the file is not touched.

  • The red "put back" banner says when and why, and goes away. It shows the time of the failure and the daemon's reason, and clears after ten minutes (or after the next successful change) instead of staying until the daemon restarts.

  • A file restored by hand is noticed. The daemon re-reads the interfaces file when it changes, so restoring it over SSH needs no restart.

  • A refused change shows the daemon's own message. (the command that failed and what it printed) instead of "Request failed with status code 500"; reverting, which had no error message at all, has one now.

  • The board's address is read from the primary interface, not from br0. The primary interface is br0 when it exists and has a global IPv4 address (so a USB modem or a VPN holding the default route does not take the page away from the bridge it manages); otherwise the device of the IPv4 default route, or, with no default route, the first up non-loopback interface with a global IPv4 address. bmcd 2.41.0

    The whole entry

    Its address is the first global, non-alias one (a br0:1 alias or a secondary address never wins over the main one). GET /api/bmc/network/address now reports it as live.address with the device name in the new live.interface, plus interfaces: every up, non-loopback interface with a global IPv4 address as {name, addresses, mac, default_route}, the default route's first. tpi info (and /api/bmc?opt=info) use the same interface for ip and mac, and fall back to the kernel's address list (as before) if ip is missing or the board has no global address yet. One reading of ip serves a whole GET, taken off the web workers.

  • PUT /api/bmc/network/address answers 409 when there is no br0. The message lists what the board has ("This board has no br0 bridge (it has: br-wan, br-lan). ..."). Nothing is changed: no pending change, no last_revert. bmcd 2.41.0

    The whole entry

    The view says so beforehand with managed_interface (br0) and managed_interface_present. The switch's apply and validate endpoints and the network restart (ifdown br0 && ifup br0) answer 409 the same way instead of failing one command at a time.

  • A hand-written /etc/network/interfaces is not replaced unless the request says so. PUT answers 409 unless the body carries "replace_hand_written": true, for a file the daemon did not write (readable or not). The image's own default file counts as the daemon's: it is replaced without ceremony. bmcd 2.41.0

  • Other failures keep their 500, but the body is the daemon's own message. (the command that failed and what it printed), without the doubled "Failed to ..." wrapper, in the usual {"response":[{"result": ...}]} shape. bmcd 2.41.0

  • last_revert records why. It gains detail, the error text of a failed apply (a plain sentence for a revert that was requested or not confirmed). bmcd 2.41.0

    The whole entry

    It is cleared by a later successful apply and by a confirm; a failed apply used to stay in the view until the daemon restarted.

  • The interfaces file is read again when it changes. The view re-reads and re-parses it whenever its modification time differs from the last read, and recomputes file and configured, so a file restored by hand over SSH is noticed without restarting the daemon. bmcd 2.41.0

    The whole entry

    A change made between an apply and its confirmation is noticed at the confirmation.

  • Confirming an address change no longer silently destroys a hand-edited /etc/network/interfaces. It used to rewrite the file with only lo and br0, losing any second bridge, VLAN or post-up hook for good.

    The whole entry

    A confirm whose file write failed also no longer reports success: the change stays pending and the window puts the old address back.

Reported by a user on Discord.

  • A confirmed address change used to overwrite a hand-edited /etc/network/interfaces without keeping a copy. Confirming rewrote the whole file with only lo and br0, so any other stanza (a second bridge, a VLAN, a post-up hook) was lost for good, and a file that could not be read was replaced just the same. bmcd 2.41.0

    The whole entry

    Whenever the file was not written by the daemon, confirm now first copies it, byte for byte, to /etc/network/interfaces.hand-written.<unix seconds> in the same directory (a -1, -2, ... suffix if that name is taken, as on a board with no clock) and reports the path as file_backup. The newest five copies are kept. If the copy cannot be made, the file is not touched. The image's own default file is not kept: it is nobody's work.

  • A confirm whose file write failed no longer pretends it succeeded. The copy and the write now happen before the change is committed, so a full or read-only overlay leaves the change pending (confirm it again, or the window puts the old address back) instead of leaving the new address live with nothing pending and a file that still says the old one. bmcd 2.41.0

  • An interfaces file that is not valid UTF-8, or cannot be read, is treated as hand-written. It used to read as "no file", i.e. DHCP, and was replaced without the opt-in. bmcd 2.41.0

  • The dashboard shows the board's address on any bridge layout. A board with its interfaces split by hand (br-wan and br-lan, no br0) showed an empty IP on the dashboard. BMC-UI 4.2.0

    The whole entry

    With more than one interface carrying an address, the dashboard now lists each as name address, the one with the default route first.

  • A failed apply no longer sits on the Network page in red for ever. The banner stayed for as long as the daemon remembered the revert. It now shows the time of the failure and the daemon's reason, and goes away after ten minutes. BMC-UI 4.2.0

  • A refused change says why. Applying, confirming or reverting an address showed axios's "Request failed with status code 500"; it now shows the daemon's own message. Reverting had no error message at all. BMC-UI 4.2.0


Every release of the firmware · the roadmap · follow by feed

Last updated: