ro.boot.wificountrycode was set in two places: androidboot.wificountrycode=US
on the kernel cmdline (mkimg.sh extlinux heredoc) and ro.boot.wificountrycode=00
in vendor.prop. Because ro.* properties are set-once and init processes the
cmdline first, the cmdline always won and the vendor.prop value silently lost
(init logs 'Read-only property was already set' every boot). Worse, the
vendor.prop value was 00 (world regulatory domain), a landmine that would
activate if the cmdline param were ever dropped.
Remove the cmdline param and set vendor.prop to US so the country code lives
in exactly one place, delivered via vendor.img instead of a hand-maintained
boot heredoc. Note this only feeds the Android framework (WifiCountryCode);
the kernel side additionally needs regulatory.db to actually apply it (fixed
separately by embedding it via CONFIG_EXTRA_FIRMWARE in the kernel).
The ro.boot.wificountrycode property is a ro.boot.* namespace property
that can ONLY be populated from the kernel cmdline (androidboot.xxx).
Setting it in vendor.prop had no effect — the value stayed '00'.
This caused the WiFi regulatory domain to default to 'country 00'
(world), which forced passive scanning on all 5GHz channels and
capped TX power at 3 dBm. On a DFS channel this meant 60s CAC
delays, failed scans, and crippled TX power causing SAE handshake
failures.
This is the actual fix — adding the boot parameter that the WiFi
framework reads to set the regulatory domain via nl80211.
Users in other regulatory domains should edit this line.