Two Wi-Fi getters return plausible-looking values that are not real. Same class as the ping() stub in #46: the caller cannot tell the value is fabricated.
1. wifi.radio.mac_address_ap returns uninitialized stack memory
ports/zephyr-cp/common-hal/wifi/Radio.c:
mp_obj_t common_hal_wifi_radio_get_mac_address_ap(wifi_radio_obj_t *self) {
uint8_t mac[MAC_ADDRESS_LENGTH];
// esp_wifi_get_mac(ESP_IF_WIFI_AP, mac);
return mp_obj_new_bytes(mac, MAC_ADDRESS_LENGTH);
}mac is never written. This hands Python six bytes of whatever was on the stack, as a MAC address. It will differ between calls and between builds.
This is the same defect that was already fixed for the station getter, common_hal_wifi_radio_get_mac_address(), which used to return an uninitialized buffer and now reads the real link address. The AP variant was not fixed with it.
Minimum fix is to raise NotImplementedError rather than return garbage, since AP mode is not implemented on this port at all. Reading the AP interface's address properly would be better if AP mode is ever implemented.
2. wifi.radio.tx_power always reports 0.0 dBm
mp_float_t common_hal_wifi_radio_get_tx_power(wifi_radio_obj_t *self) {
int8_t tx_power = 0;
// esp_wifi_get_max_tx_power(&tx_power);
return tx_power / 4.0f;
}Returns a hardcoded 0. set_tx_power() is an empty body, so a user can set a value, read it back, and get 0.0 with no error at any point.
0 dBm is a physically plausible reading, which is what makes it worse than an exception.
Why file these together
Both follow the pattern this port has repeatedly been bitten by: a stub that returns a value in the correct type and a plausible range, instead of failing. ping() returning 0 was read as a successful round trip (#46); getaddrinfo() collapsing every error into one code hid a dead resolver thread for far longer than it should have (#49).
An honest NotImplementedError costs a user one line of handling. A fabricated value costs an afternoon.
Found by a systematic audit of all 43 common_hal_wifi_radio_* functions on siwx917/integration-rebase.
Two Wi-Fi getters return plausible-looking values that are not real. Same class as the
ping()stub in #46: the caller cannot tell the value is fabricated.1.
wifi.radio.mac_address_apreturns uninitialized stack memoryports/zephyr-cp/common-hal/wifi/Radio.c:macis never written. This hands Python six bytes of whatever was on the stack, as a MAC address. It will differ between calls and between builds.This is the same defect that was already fixed for the station getter,
common_hal_wifi_radio_get_mac_address(), which used to return an uninitialized buffer and now reads the real link address. The AP variant was not fixed with it.Minimum fix is to raise
NotImplementedErrorrather than return garbage, since AP mode is not implemented on this port at all. Reading the AP interface's address properly would be better if AP mode is ever implemented.2.
wifi.radio.tx_poweralways reports 0.0 dBmReturns a hardcoded 0.
set_tx_power()is an empty body, so a user can set a value, read it back, and get 0.0 with no error at any point.0 dBm is a physically plausible reading, which is what makes it worse than an exception.
Why file these together
Both follow the pattern this port has repeatedly been bitten by: a stub that returns a value in the correct type and a plausible range, instead of failing.
ping()returning 0 was read as a successful round trip (#46);getaddrinfo()collapsing every error into one code hid a dead resolver thread for far longer than it should have (#49).An honest
NotImplementedErrorcosts a user one line of handling. A fabricated value costs an afternoon.Found by a systematic audit of all 43
common_hal_wifi_radio_*functions onsiwx917/integration-rebase.