Merge pull request #1484 from kernelkit/releng

Release preparations

Author: troglobit

board/aarch64/bananapi-bpi-r64/README.md

@@ -14,7 +14,7 @@ The Banana Pi BPI-R64 is a networking board based on the MediaTek MT7622
 - 8 GB eMMC storage
 - microSD card slot
 - MT7531 Gigabit Ethernet switch (4x LAN + 1x WAN)
-- MT7603E built-in 2.4 GHz WiFi
+- MT7622 WMAC built-in 2.4 GHz 802.11ac WiFi
 - USB 3.0 port
 - 2x Mini PCIe slots
 
@@ -24,7 +24,7 @@ Infix comes preconfigured with:
 
 - **LAN ports** (lan0-lan3): Bridged for internal networking
 - **WAN port**: DHCP client enabled for internet connectivity
-- **WiFi** (wifi0-ap): Bridged to LAN (MT7615 PCIe card if fitted, otherwise MT7603E)
+- **WiFi** (wifi0-ap): Bridged to LAN (MT7622 WMAC, 2.4 GHz; or MT7615 PCIe card if fitted)
 
 ## Boot Switch Reference
 
@@ -113,6 +113,19 @@ mmc partconf 0 1 1 0
 
 ## Platform Notes
 
+### WiFi
+
+The MT7622 SoC includes a built-in WMAC that provides 2.4 GHz 802.11b/g/n/ac
+(2×2) — there is no 5 GHz capability from the onboard radio.
+
+For dual-band operation, a PCIe card can be fitted in one of the two Mini PCIe
+slots.  The [Banana Pi BPI-MT7615][bpi-mt7615] is a purpose-built dual-band
+(2.4 + 5 GHz, 802.11ac 4×4) module designed for BPI router boards and is a
+natural fit.  With it installed, Infix will use it in preference to the onboard
+WMAC for the `wifi0-ap` interface.
+
+[bpi-mt7615]: https://docs.banana-pi.org/en/BPI-MT7615/BananaPi_MT7615
+
 ### mmc0 = eMMC, mmc1 = SD
 
 On MT7622, MSDC0 (mmc0) is the 8-bit eMMC controller and MSDC1 (mmc1) is the

buildroot

@@ -3,29 +3,55 @@ Change Log
 
 All notable changes to the project are documented in this file.
 
-[v26.04.0][UNRELEASED] -
+[v26.04.0][] - 2026-04-30
 -------------------------
 
 ### Changes
 
 - Upgrade Linux kernel to 6.18.25 (LTS)
 - Upgrade Buildroot to 2025.02.13 (LTS)
+- Add support for per-bridge multicast router port in operational, issue #395
+- Add support for static ARP (IPv4) and neighbor cache (IPv6) entries per
+  interface, issue #819.  Static entries are installed as permanent kernel
+  neighbor table entries that are never evicted by normal ARP/NDP aging
 - Add support for PTP/gPTP (IEEE 1588-2019 / 802.1AS) clock synchronization.
   Supported clock types: Ordinary Clock, Boundary Clock, and Transparent Clock.
   See the User Guide for configuration details
 - Add support for [Banana Pi BPI-R4][BPI-R4], quad-core Cortex-A73 router with
   4x 2.5 GbE switching, dual 10 GbE SFP+.  Variants BPI-R4-2g5 and BPI-R4P have
   one SFP+ replaced by a 2.5 GbE RJ45, with optional PoE on the R4P
+- Update [Marvell ESPRESSObin][ESPRESSObin] board support.  Allow booting with
+  stock U-Boot, which only supports ext4 rootfs partitions; to use, apply the
+  `ext4` developer snippet before building (`make apply-ext4 all`)
+- Fix onboard WiFi support on the Banana Pi BPi-R64
 
 ### Fixes
 
+- Fix #520: warn in syslog if multicast flooding is disabled
+- Fix #769: document dummy interfaces in user guide
+- Fix #790: document static multicast filters in user guide
+- Fix #1439: changing hostname does not regenerate DHCP client conf until restart
 - Fix #1458: `show ntp tracking` displaying a truncated Reference ID, e.g.,
   `92.2` instead of `92.246.137.39`
 - Fix #1466: `show container` showing no output for containers whose command
   line includes environment variables
-- Fix #1439: changing hostname does not regenerate DHCP client conf until restart
+- Fix issue with IGMP queries sent with all-zeroes source MAC address
+- Fix missing IGMP query startup burst when assuming IGMP querier role, as
+  defined in RFC3376 §8.6/§8.7
+- Fix Raspberry Pi 4 and Pi 400 display instability after soft reboot.
+  Previously the touchscreen/DSI display required a full power cycle to
+  reinitialise correctly; it now works reliably after `reboot`.  Please note,
+  you need a fairly up-to-date EEPROM version as well
+- Fix [BPI-R4][] board README showing inverted DIP switch values for eMMC and
+  SPI NAND boot modes, which would prevent the board from booting correctly
+- Fix [SAMA7G54][] U-Boot build system selection that caused build failures
+- Fix [BPI-R3][] PCIe devices failing to initialize on boot due to a missing
+  clock definition in the device tree
 
+[BPI-R3]: https://wiki.banana-pi.org/Banana_Pi_BPI-R3
 [BPI-R4]: https://docs.banana-pi.org/en/BPI-R4/BananaPi_BPI-R4
+[ESPRESSObin]: https://espressobin.net/
+[SAMA7G54]: https://www.microchip.com/en-us/development-tool/ev21h18a
 
 [v26.03.0][] - 2026-03-31
 -------------------------

doc/ChangeLog.md

@@ -183,6 +183,48 @@ In this setup we have a lot more going on.  Multiple multicast router
 ports have been detected, and behind the scenes someone has also added
 an IGMP/MLD fast-leave port.
 
+### Static Multicast Filters
+
+When IGMP/MLD snooping is in use, traffic for an unregistered group is
+flooded to all ports until a receiver joins.  For MAC multicast groups,
+or for groups where snooping cannot learn membership automatically, you
+can add static entries to the MDB that immediately restrict forwarding
+to a given set of ports.
+
+> [!NOTE]
+> Snooping must be enabled on the bridge (or per VLAN) before static
+> multicast filters can be configured.
+
+On a plain (non-VLAN) bridge, add a static IPv4 or MAC multicast filter
+like this:
+
+<pre class="cli"><code>admin@example:/> <b>configure</b>
+admin@example:/config/> <b>edit interface br0</b>
+admin@example:/config/interface/br0/> <b>set bridge multicast-filters multicast-filter 224.1.1.1 ports e2</b>
+admin@example:/config/interface/br0/> <b>set bridge multicast-filters multicast-filter 224.1.1.1 ports e3</b>
+admin@example:/config/interface/br0/> <b>set bridge multicast-filters multicast-filter 01:00:5e:01:01:01 ports e2</b>
+admin@example:/config/interface/br0/> <b>leave</b>
+admin@example:/> <b>copy running-config startup-config</b>
+</code></pre>
+
+Each `ports` entry for the same group adds one port to the filter.
+Receivers on all other ports will not see traffic for that group.
+
+On a VLAN-filtering bridge the filter is scoped per VLAN:
+
+<pre class="cli"><code>admin@example:/config/interface/br1/> <b>set bridge vlans vlan 10 multicast-filters multicast-filter 224.2.2.2 ports e5</b>
+admin@example:/config/interface/br1/> <b>set bridge vlans vlan 10 multicast-filters multicast-filter 224.2.2.2 ports e6</b>
+</code></pre>
+
+To verify the MDB — both statically configured and dynamically learned
+entries — use:
+
+<pre class="cli"><code>admin@example:/> <b>show bridge mdb</b>
+<span class="header">BRIDGE   VID  GROUP                 PORTS                              </span>
+br0           224.1.1.1             e2, e3
+br0           01:00:5e:01:01:01     e2
+</code></pre>
+
 ### Terminology & Abbreviations
 
  - **IGMP**: Internet Group Membership Protocol, multicast subscription

doc/bridging.md

@@ -138,6 +138,49 @@ admin@example:/config/interface/veth0a/> <b>set custom-phys-address chassis offs
 </code></pre>
 
 
+## Dummy Interface
+
+A dummy interface is a virtual interface that is always administratively
+and operationally UP, regardless of any physical link state.  It can
+hold IP addresses just like any other interface.
+
+The two most common uses are:
+
+- **Stable OSPF router-ID**: OSPF picks its router-ID from an interface
+  address.  If that interface goes down, adjacencies can flap.  Binding
+  the router-ID to a /32 address on a dummy avoids this.
+- **Stable management address**: A /32 on a dummy gives the device a
+  permanent identity on the network, reachable as long as at least one
+  uplink is up and the address is redistributed into the routing domain.
+
+> [!TIP]
+> WiFi interfaces also use dummies as placeholders when the radio
+> hardware is not detected at boot (e.g., a USB dongle that was
+> unplugged).  See [WiFi](wifi.md) for details.
+
+### Example: Stable OSPF Router-ID
+
+Create a dummy interface with a /32 address and use it as the OSPF
+router-ID so that the ID never changes when physical ports bounce:
+
+<pre class="cli"><code>admin@example:/> <b>configure</b>
+admin@example:/config/> <b>edit interface lo0</b>
+admin@example:/config/interface/lo0/> <b>set type dummy</b>
+admin@example:/config/interface/lo0/> <b>set ipv4 address 192.0.2.1 prefix-length 32</b>
+admin@example:/config/interface/lo0/> <b>leave</b>
+admin@example:/config/> <b>edit routing control-plane-protocol ospfv2 name default ospf</b>
+admin@example:/config/routing/…/ospf/> <b>set explicit-router-id 192.0.2.1</b>
+admin@example:/config/routing/…/ospf/> <b>leave</b>
+admin@example:/> <b>copy running-config startup-config</b>
+</code></pre>
+
+To also make the address reachable by other routers, redistribute
+connected routes (or add `lo0` as an OSPF interface):
+
+<pre class="cli"><code>admin@example:/config/routing/…/ospf/> <b>set redistribute connected</b>
+</code></pre>
+
+
 [^1]: A YANG deviation was previously used to make it possible to set
     `phys-address`, but this has been replaced with the more flexible
     `custom-phys-address`.

doc/iface.md

@@ -435,6 +435,66 @@ admin@example:/config/interface/eth0/> <b>leave</b>
 admin@example:/>
 </code></pre>
 
+## ARP and Neighbor Cache
+
+Static ARP entries (IPv4) and neighbor cache entries (IPv6) can be
+configured per interface.  The most common reasons to do so are:
+
+- **Security** — prevent ARP/NDP spoofing by locking critical hosts
+  (e.g., a default gateway) to their known MAC addresses
+- **Reliability** — ensure reachability of a host even when ARP/NDP
+  traffic is suppressed or filtered (e.g., across a strict firewall)
+
+Dynamic entries are learned automatically by the kernel using ARP and
+Neighbor Discovery Protocol (NDP), and are visible as read-only
+operational state alongside the static ones.
+
+### Static IPv4 ARP Entry
+
+<pre class="cli"><code>admin@example:/> <b>configure</b>
+admin@example:/config/> <b>edit interface eth0 ipv4</b>
+admin@example:/config/interface/eth0/ipv4/> <b>set neighbor 192.168.1.100 link-layer-address 00:11:22:33:44:55</b>
+admin@example:/config/interface/eth0/ipv4/> <b>diff</b>
++interfaces {
++  interface eth0 {
++    ipv4 {
++      neighbor 192.168.1.100 {
++        link-layer-address 00:11:22:33:44:55;
++      }
++    }
++  }
++}
+admin@example:/config/interface/eth0/ipv4/> <b>leave</b>
+admin@example:/>
+</code></pre>
+
+### Static IPv6 Neighbor Entry
+
+<pre class="cli"><code>admin@example:/> <b>configure</b>
+admin@example:/config/> <b>edit interface eth0 ipv6</b>
+admin@example:/config/interface/eth0/ipv6/> <b>set neighbor 2001:db8::100 link-layer-address 00:11:22:33:44:55</b>
+admin@example:/config/interface/eth0/ipv6/> <b>diff</b>
++interfaces {
++  interface eth0 {
++    ipv6 {
++      neighbor 2001:db8::100 {
++        link-layer-address 00:11:22:33:44:55;
++      }
++    }
++  }
++}
+admin@example:/config/interface/eth0/ipv6/> <b>leave</b>
+admin@example:/>
+</code></pre>
+
+The full neighbor table — including dynamically learned entries (origin:
+*dynamic*) — is available as operational state via NETCONF or RESTCONF.
+
+> [!NOTE]
+> Static neighbor entries take effect immediately on `leave` (commit).
+> They are installed as *permanent* entries in the kernel neighbor table,
+> which means they are never evicted by the normal ARP/NDP aging process.
+
 [1]: https://www.rfc-editor.org/rfc/rfc3442
 [2]: https://www.rfc-editor.org/rfc/rfc8344
 [3]: https://www.rfc-editor.org/rfc/rfc8981