### System details

Intel i7-4770HQ, Intel Iris Pro (Crystal Well), MacBookPro11,4 (Mid-2015 15"), BCM43602 `[14e4:43ba]`, Omarchy 4.0.4-1, kernel 7.2.5-3-omarchy, firmware `7.35.177.61`, no CLM blob

### What's wrong?

This follows #13164. With `feature_disable=0` (the #13164 workaround) and `WIRELESS_REGDOM="DE"`, the card has VHT and joins the 5 GHz BSSID at 802.11ac. **Within 8–64 s the 5 GHz link drops**, and the laptop settles on the 2.4 GHz BSSID at 802.11n. VHT stays advertised (`iw list | grep -c VHT` = 6) the whole time. The card loses the link, not the capability.

**Cause:** the AP's Country IE is pushed into the firmware while the link is up.

- The 5 GHz BSSID of this dual-band mesh beacons **Country `UA`** (ch 60, DFS, VHT80/160). The 2.4 GHz BSSID beacons `US`.
- On association cfg80211 accepts the hint: `REGDOM-CHANGE init=COUNTRY_IE alpha2=UA`.
- `brcmf_cfg80211_reg_notifier()` has no check on `req->initiator`. It writes every hint, `NL80211_REGDOM_SET_BY_COUNTRY_IE` included, to the firmware `country` iovar. BCM43602 is in `brmcf_use_iso3166_ccode_fallback()`, so `UA` reaches the firmware unchanged.
- This firmware misbehaves with `UA`. When `UA` is the user regdomain at driver load, VHT disappears completely. When `UA` is set on a live link, the link goes down: `DISCONNECTED reason=0 locally_generated=1`, which is `BRCMF_E_LINK`. Reconnecting then often fails with `ASSOC-REJECT status_code=16`.
- brcmfmac never sets `REGULATORY_COUNTRY_IE_IGNORE`, so `__reg_process_hint_country_ie()` never returns `REG_REQ_IGNORE` for it.

**Boot log (monotonic seconds):**

| t | Event |
|---|---|
| 19.8 | join 5 GHz → `REGDOM-CHANGE init=COUNTRY_IE alpha2=UA` |
| 27.7 | `DISCONNECTED reason=0 locally_generated=1` → regdom WORLD → DE |
| 30.8 | `ASSOC-REJECT status_code=16` |
| 33.9 | rejoin 5 GHz → Country IE `UA` again |
| 50.6 | dropped again, `reason=0` |
| 53.4 | join 2.4 GHz (Country `US`) → stays there |

The 5 GHz BSSID dropped 4 out of 4 times. Pinning NetworkManager to `802-11-wireless.band a` alone doesn't fix it. The link still drops after about 64 s, and the firmware then fails to rejoin for about 100 s (9× `ASSOC-REJECT status_code=16`).

### Steps to reproduce

1. BCM43602 Mac with the #13164 workaround (`options brcmfmac feature_disable=0`) and a user regdomain that works on this firmware (`DE` or `US`).
2. Connect to a 5 GHz AP whose beacon Country IE is one this firmware mishandles (`UA` here).
3. `journalctl -b | grep -E 'wpa_supplicant.*(DISCONNECTED|REGDOM)'` shows `REGDOM-CHANGE init=COUNTRY_IE alpha2=UA`, followed by `DISCONNECTED reason=0 locally_generated=1` within about a minute.

### Verified workaround

A small out-of-tree DKMS module sets `wiphy->regulatory_flags |= REGULATORY_COUNTRY_IE_IGNORE` on `NETDEV_REGISTER` for wiphys bound to `brcmfmac`, without patching brcmfmac. A `softdep brcmfmac pre: brcmfmac_country_ie_ignore` makes sure it is loaded before the driver.

<details><summary>Module source (GPL-2.0)</summary>

```c
#include <linux/module.h>
#include <linux/netdevice.h>
#include <linux/rtnetlink.h>
#include <net/cfg80211.h>

static bool is_brcmfmac_wiphy(struct wiphy *wiphy)
{
	struct device *dev = wiphy_dev(wiphy);

	return dev && dev->driver && !strcmp(dev->driver->name, "brcmfmac");
}

static int ccie_netdev_event(struct notifier_block *nb, unsigned long event,
			     void *ptr)
{
	struct net_device *ndev = netdev_notifier_info_to_dev(ptr);
	struct wireless_dev *wdev = ndev->ieee80211_ptr;

	if (event != NETDEV_REGISTER || !wdev || !wdev->wiphy ||
	    !is_brcmfmac_wiphy(wdev->wiphy))
		return NOTIFY_DONE;

	if (!(wdev->wiphy->regulatory_flags & REGULATORY_COUNTRY_IE_IGNORE)) {
		wdev->wiphy->regulatory_flags |= REGULATORY_COUNTRY_IE_IGNORE;
		pr_info("ignoring AP Country IE on %s (%s)\n",
			wiphy_name(wdev->wiphy), ndev->name);
	}
	return NOTIFY_DONE;
}

static struct notifier_block ccie_notifier = {
	.notifier_call = ccie_netdev_event,
};

/* Registering replays NETDEV_REGISTER for interfaces that already exist. */
static int __init ccie_init(void)
{
	return register_netdevice_notifier(&ccie_notifier);
}

static void __exit ccie_exit(void)
{
	struct net_device *ndev;

	unregister_netdevice_notifier(&ccie_notifier);

	rtnl_lock();
	for_each_netdev(&init_net, ndev) {
		struct wireless_dev *wdev = ndev->ieee80211_ptr;

		if (wdev && wdev->wiphy && is_brcmfmac_wiphy(wdev->wiphy))
			wdev->wiphy->regulatory_flags &=
				~REGULATORY_COUNTRY_IE_IGNORE;
	}
	rtnl_unlock();
}

module_init(ccie_init);
module_exit(ccie_exit);

MODULE_DESCRIPTION("Ignore AP Country IE regulatory hints on brcmfmac");
MODULE_LICENSE("GPL");
```
</details>

**Result:** with the module loaded, the kernel log shows `ignoring AP Country IE on phy1 (wlp3s0)`. I polled once a second for 300 s: the link stayed on the 5 GHz BSSID at 5300 MHz the whole time, VHT=6, with no `REGDOM-CHANGE` or `DISCONNECTED` events. Signal was −49 dBm, tx/rx 450 Mbit/s. Before the fix, no 5 GHz session lasted longer than 64 s.

**Side effect:** the regdomain no longer follows the AP. It stays at the value in `/etc/conf.d/wireless-regdom`, which makes a correct user regdomain more important.

**Still open:** after the fix the link came up at 40 MHz, although the AP advertises 80/160 MHz. That session's firmware had been through several country changes before the module loaded. I haven't yet re-checked the width after a clean boot.

### Related: the installer's timezone-derived regdomain

`install/hardware/set-wireless-regdom.sh` derives `WIRELESS_REGDOM` from the timezone (`Europe/Kyiv` → `UA`). On this firmware, `UA` as the user regdomain at driver load removes VHT entirely: I checked with a reload sweep, where `UA` gave VHT=0 twice, and `US`/`DE` gave VHT=6. With the world domain `00`, VHT is present but 5 GHz joins are rejected with `status_code=16`. So a BCM43602 Mac installed with a Ukrainian timezone gets no 802.11ac, even with the #13164 workaround in place.

### Expected / possible directions

- Omarchy already ships Apple Broadcom quirks (`fix-brcmfmac-supplicant.sh`). For BCM43602 it could also ship the Country IE mitigation. Alternatively, it could document that the firmware mishandles some country codes, and warn when the timezone-derived regdomain is one of them.
- The real fix belongs upstream: brcmfmac should ignore `NL80211_REGDOM_SET_BY_COUNTRY_IE` hints, or set `REGULATORY_COUNTRY_IE_IGNORE`, at least on chips in the ISO3166 fallback list, where it passes codes straight to old firmware. I plan to report it to linux-wireless.

Related: #13164, #9019, #7672