mediatek: filogic: fix Keenetic phy1 MAC collision

The fixup set the 5 GHz phy address to the base MAC with only the
locally administered bit set. The userspace VIF address allocator
derives additional VIF addresses on a phy the same way: the second
interface brought up on the 2.4 GHz radio gets base | 0x02, the exact
value this fixup assigned to phy1. Any configuration with two VIFs on
the 2.4 GHz radio (AP + mesh, AP + STA, a second AP) therefore ended
up with two interfaces sharing one MAC address. Observed on a KN-3811
running an 802.11s mesh alongside the regular APs: the 2.4 GHz mesh
VIF came up with the same address as the 5 GHz AP, and every
batman-adv loop-avoidance announce returning from the mesh made the
bridge log "received packet on bat0 with own address as source" and
flap the FDB entry for that address.

Simply dropping the override is not an option on these boards. Without
it mt76 falls back to the second MAC slot in the calibration data
(MT_EE_MAC_ADDR2, eeprom offset 0xa), but the DTS of every board here
already consumes that slot as the ethernet/label address, so phy1
would collide with a wired interface instead - verified on a KN-3811,
where the slot holds the WAN MAC. On KAP-630/NAP-630 that ethernet
port and the 5 GHz AP even sit in the same bridge.

Shifting the base is not enough either: the allocator's MBSSID scheme
varies the last octet (addr[5] ^= idx), so any last-octet shift stays
reachable at some index. Reproduce instead the address mt76 derives on
its own when the second slot is empty: LA bit set and bit 7 of the
first octet flipped. Neither allocator scheme can produce it (the
default one varies bits 2-6 of octet 0, MBSSID varies octet 5), and it
matches neither the base nor the base+1 ethernet address. This also
gives the whole family one 5 GHz addressing convention, since boards
with an empty second slot already get exactly this address from the
driver. The 5 GHz BSSID of the affected boards changes accordingly.

Tested on a KN-3811: phy1 comes up as the base with the LA bit and
bit 7 flipped, no address overlaps on the device, and APs, mesh and
clients re-associate fine.

Signed-off-by: Aleksei Sviridkin <f@lex.la>
Link: https://github.com/openwrt/openwrt/pull/24623
Signed-off-by: Jonas Jelonek <jonas@jonasjelonek.de>
This commit is contained in:
Aleksei Sviridkin authored and Jonas Jelonek committed 2026-09-14 09:10:34 +02:00
1 parent 404e54d55b
commit cc96ed1e6d
1 file changed
+10 -1
@@ -199,8 +199,17 @@ case "$board" in
keenetic,kn-3811|\
keenetic,kn-3911|\
netcraze,nap-630)
# Originally phy1 was the phy0 mac with only the LA bit set, which
# is also the address the VIF allocator hands the second 2.4 GHz
# interface, and shifting the last octet instead overlaps the
# MBSSID scheme at some index. The eeprom second-MAC slot (0xa) is
# no alternative either: the DTS already consumes it as the
# ethernet/label mac. Reproduce the address mt76 would derive on
# its own (LA bit set, bit 7 flipped), out of reach of both
# allocator schemes.
addr=$(mtd_get_mac_binary rf-eeprom 0x4)
[ "$PHYNBR" = "1" ] && \
macaddr_setbit_la "$(mtd_get_mac_binary rf-eeprom 0x4)" > /sys${DEVPATH}/macaddress
printf "%02x:%s" $(( (0x${addr%%:*} | 0x2) ^ 0x80 )) "${addr#*:}" > /sys${DEVPATH}/macaddress
;;
mercusys,mr80x-v3|\
mercusys,mr85x)