RDKB-66065: RFC MLO Enable

[bmilcz-comcast]

Reason for change: Send notification to telemetry whenever MLO is completely disabled on device.
Test Procedure: Enable/disable MLO, check if appropriate messages are being sent.
Risks: Low
Priority: P1

[Copilot]

Pull request overview

This PR adds a mechanism to notify telemetry (via bus-set TR-181 report parameters) whenever the device’s effective MLO/RFC enable state changes, with retry handling to tolerate transient bus failures.

Changes:

• Track last-known MLO RFC enable state and notification retry/pending status in wifi_ctrl_t.
• Compute whether MLO is effectively enabled by scanning VAP MLD configuration and schedule bus updates (with retries) at boot and after relevant webconfig updates.
• Introduce TR-181 parameter name macros for the two telemetry/report paths being updated.

Reviewed changes

Copilot reviewed 3 out of 3 changed files in this pull request and generated 3 comments.

File	Description
source/core/wifi_ctrl.h	Adds fields to track last MLO RFC state and notification retry/pending bookkeeping.
source/core/wifi_ctrl.c	Implements MLO RFC state evaluation and bus notification scheduling/retry logic; triggers on boot and after MLD group updates.
include/wifi_base.h	Adds TR-181 parameter string macros used for telemetry notifications.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[Copilot]

Pull request overview

Copilot reviewed 4 out of 4 changed files in this pull request and generated 1 comment.

Suppressed comments (1)

source/core/wifi_ctrl.c:3393

• update_rfc_mlo_enable() treats any VAP with mld_id < MLD_UNIT_COUNT as “MLO enabled”, but elsewhere (e.g., update_mld_groups) MLO can be disabled by setting mld_enable = false while leaving mld_id in-range. This can cause false positives (reporting MLO enabled when it’s actually disabled). Gate on mld_enable (and typically skip disabled VAPs) and ignore UNDEFINED_MLD_ID.

            if (isVapSTAMesh(vap->vap_index)) {
                continue;
            }

            if (vap->u.bss_info.mld_info.common_info.mld_id < MLD_UNIT_COUNT) {
                mlo_rfc_enable = true;
                break;

[Copilot]

Pull request overview

Copilot reviewed 4 out of 4 changed files in this pull request and generated no new comments.

Suppressed comments (3)

source/core/wifi_ctrl.c:48

• set_bus_bool_param() is only used within this translation unit, but it’s declared/defined with external linkage. That increases the chance of duplicate-symbol collisions across the codebase. Consider making it static (and updating both the forward declaration and the definition) or moving the definition above its first use to avoid the prototype entirely.

int set_bus_bool_param(bus_handle_t *handle, const char *paramNames, bool data_value);

source/core/wifi_ctrl.c:3384

• vap cannot be NULL here because it’s the address of an element in vap_array. This check is dead code and can mask real out-of-bounds issues by implying NULL is possible.

            wifi_vap_info_t *vap = &wifi_mgr->radio_config[i].vaps.vap_map.vap_array[j];
            if (vap == NULL) {
                continue;
            }

source/core/wifi_ctrl.c:3361

• The doc comment has a grammatical error (“IF there was a RFC status differs…”). Clarifying this improves readability for future maintainers.

 * Update the MLO RFC enable status based on the current VAP configurations.
 * This function checks all radios and their VAPs to determine if any VAP has a
 * valid MLD ID and updates the corresponding MLO RFC enable status IF there was
 * a RFC status differs from previously recorded.

[Copilot]

Pull request overview

Copilot reviewed 4 out of 4 changed files in this pull request and generated no new comments.

Suppressed comments (1)

source/core/wifi_ctrl.c:3390

• update_rfc_mlo_enable() treats any mld_id < MLD_UNIT_COUNT as “MLO enabled”. Elsewhere the codebase consistently gates MLD-related behavior on mld_enable and mld_id != UNDEFINED_MLD_ID (e.g., source/webconfig/wifi_ovsdb_translator.c:2845 and :3072). Aligning this check avoids incorrectly reporting MLO enabled if mld_id is ever left at a default/inconsistent value while mld_enable is false.

            if (vap->u.bss_info.mld_info.common_info.mld_id < MLD_UNIT_COUNT) {
                mlo_rfc_enable = true;
                break;
            }

[Copilot]

Pull request overview

Copilot reviewed 4 out of 4 changed files in this pull request and generated no new comments.

Suppressed comments (1)

source/core/wifi_ctrl.c:3485

• update_rfc_mlo_enable() determines the RFC state by reading vap->u.bss_info... for every VAP. This is incorrect for STA-mode VAPs (union member differs) and it also ignores mld_enable/UNDEFINED_MLD_ID, which can cause false positives. Use get_mld_from_vap_info() and validate mld_enable + mld_id before marking MLO enabled.

            if (isVapSTAMesh(vap->vap_index)) {
                continue;
            }

            if (vap->u.bss_info.mld_info.common_info.mld_id < MLD_UNIT_COUNT) {

[github-actions]

clang-format suggests the formatting changes below. Use Commit suggestion to apply them.

[github-actions]

Suggested change

	#define WIFI_NETWORKDEVICESSTATUS_MLORFCENABLE "Device.DeviceInfo.X_RDKCENTRAL-COM_Report.NetworkDevicesStatus.MloRfcEnable"
	#define WIFI_INTERFACEDEVICESWIFI_MLORFCENABLE "Device.DeviceInfo.X_RDKCENTRAL-COM_Report.InterfaceDevicesWifi.MloRfcEnable"
	#define WIFI_NETWORKDEVICESSTATUS_MLORFCENABLE \
	"Device.DeviceInfo.X_RDKCENTRAL-COM_Report.NetworkDevicesStatus.MloRfcEnable"
	#define WIFI_INTERFACEDEVICESWIFI_MLORFCENABLE \
	"Device.DeviceInfo.X_RDKCENTRAL-COM_Report.InterfaceDevicesWifi.MloRfcEnable"

[github-actions]

Suggested change

	__LINE__, param_name, wifi_mgr->ctrl.mlo_rfc_status.last_mlo_rfc_enable ? "true" : "false");
	__LINE__, param_name,
	wifi_mgr->ctrl.mlo_rfc_status.last_mlo_rfc_enable ? "true" : "false");

[github-actions]

Suggested change

	&wifi_mgr->ctrl.mlo_rfc_status.last_mlo_rfc_notify_task_id, set_mlo_rfc_task, NULL, 1000, 1,
	FALSE) != RETURN_OK) {
	&wifi_mgr->ctrl.mlo_rfc_status.last_mlo_rfc_notify_task_id, set_mlo_rfc_task, NULL,
	1000, 1, FALSE) != RETURN_OK) {

[github-actions]

Suggested change

	if ((init || state_changed || (wifi_mgr->ctrl.mlo_rfc_status.last_mlo_rfc_enable_notify_status != true))) {
	if ((init || state_changed ||
	(wifi_mgr->ctrl.mlo_rfc_status.last_mlo_rfc_enable_notify_status != true))) {

[github-actions]

Suggested change

	&wifi_mgr->ctrl.mlo_rfc_status.last_mlo_rfc_notify_task_id, set_mlo_rfc_task, NULL, 1000, 1,
	FALSE) != RETURN_OK) {
	&wifi_mgr->ctrl.mlo_rfc_status.last_mlo_rfc_notify_task_id, set_mlo_rfc_task, NULL,
	1000, 1, FALSE) != RETURN_OK) {

[github-actions]

🔎 clang-tidy (advisory)

🔎 clang-tidy advisory — 8 findings

source/core/wifi_ctrl.c:1892:9: warning: function 'strcmp' is called without explicitly comparing result [bugprone-suspicious-string-compare]
source/core/wifi_ctrl.c:3947:21: warning: comparison length is too long and might lead to a buffer overflow [bugprone-not-null-terminated-result]
source/core/wifi_ctrl.c:531:17: warning: function 'strcmp' is called without explicitly comparing result [bugprone-suspicious-string-compare]
source/core/wifi_ctrl_webconfig.c:1092:9: warning: comparing object representation of type 'wifi_global_param_t' which does not have a unique object representation; consider comparing the members of the object manually [bugprone-suspicious-memory-comparison]
source/core/wifi_ctrl_webconfig.c:982:21: warning: comparing object representation of type 'wifi_vap_security_t' which does not have a unique object representation; consider comparing the members of the object manually [bugprone-suspicious-memory-comparison]
source/core/wifi_ctrl_webconfig.c:982:21: warning: function 'memcmp' is called without explicitly comparing result [bugprone-suspicious-string-compare]
source/core/wifi_ctrl_webconfig.c:988:21: warning: comparing object representation of type 'wifi_vap_security_t' which does not have a unique object representation; consider comparing the members of the object manually [bugprone-suspicious-memory-comparison]
source/core/wifi_ctrl_webconfig.c:988:21: warning: function 'memcmp' is called without explicitly comparing result [bugprone-suspicious-string-compare]

[github-actions]

🔨 Build summary

Commit 130be27 · Build Check #4755

Banana Pi R4 - MLO — build success

⚠️ OneWifi warnings: 0

Raspberry Pi — build success

⚠️ OneWifi warnings: 0

[Copilot]

Pull request overview

Copilot reviewed 4 out of 4 changed files in this pull request and generated 1 comment.

[bmilcz-comcast]

As currently - we ignore STAs and we do this only for APs (isVapSTAMesg filter above)
Second conditional is intentional for mld_id only - if set, that means this VAP is meant to be in MLO and we signal this. mld_enable in this scenario would signal a config problem that should be fixed.
So suggestion is invalid, though we may include STAs in this update in future.

[Copilot]

Pull request overview

Copilot reviewed 4 out of 4 changed files in this pull request and generated 1 comment.

[bmilcz-comcast]

no longer an issue

[Copilot]

Pull request overview

Copilot reviewed 4 out of 4 changed files in this pull request and generated no new comments.

Suppressed comments (3)

source/core/wifi_ctrl.c:3450

• If set_bus_bool_param() keeps failing for either telemetry parameter, set_mlo_rfc_task() will reschedule itself every second indefinitely. This can create persistent scheduler churn/log spam and never clears the pending flag until the bus starts succeeding. There is a MLO_RFC_MAX_RETRY_COUNT constant defined but it is not used—consider enforcing a bounded retry count (and clearing pending after the cap) or removing the unused constant if unneeded.

    if (scheduler_add_timer_task(wifi_mgr->ctrl.sched, FALSE,
            &mlo_rfc_status->last_mlo_rfc_notify_task_id, set_mlo_rfc_task, mlo_rfc_status, 1000, 1,
            FALSE) != RETURN_OK) {
        wifi_util_error_print(WIFI_CTRL, "%s:%d: Failed to reschedule timer task\n", __FUNCTION__,
            __LINE__);
        mlo_rfc_status->last_mlo_rfc_enable_notify_status_pending = false;
    }

source/core/wifi_ctrl.c:3487

• update_mlo_rfc_enable() treats MLO as enabled solely based on mld_id < MLD_UNIT_COUNT. In this codebase mld_enable can be forced to false while leaving mld_id within bounds (e.g., the MLD-group seeding path clears mld_enable without changing mld_id), which can cause false “enabled” reporting and prevent the intended “MLO completely disabled” telemetry notification. Gate this on mld_enable as well.

            }

            if (vap->u.bss_info.mld_info.common_info.mld_id < MLD_UNIT_COUNT) {
                mlo_rfc_enable = true;

source/core/wifi_ctrl.c:3417

• In set_mlo_rfc_task(), if get_wifimgr_obj() returns NULL the function returns without clearing last_mlo_rfc_enable_notify_status_pending. That can leave the system stuck in a “pending” state (future calls will try to cancel/reschedule using a stale task id). Clear the pending flag on this early-exit path.

This issue also appears on line 3444 of the same file.

    wifi_mgr_t *wifi_mgr = get_wifimgr_obj();
    if (wifi_mgr == NULL) {
        wifi_util_error_print(WIFI_CTRL, "%s:%d: Failed to get wifi_mgr object\n", __FUNCTION__,
            __LINE__);
        return TIMER_TASK_COMPLETE;
    }

[Copilot]

Pull request overview

Copilot reviewed 4 out of 4 changed files in this pull request and generated no new comments.

Suppressed comments (1)

source/core/wifi_ctrl.c:3488

• update_mlo_rfc_enable() treats MLO as enabled whenever mld_id < MLD_UNIT_COUNT, but elsewhere in the codebase MLO participation is gated by mld_enable and UNDEFINED_MLD_ID (e.g., wifi_ovsdb_translator.c:2845). After update_mld_groups() runs, VAPs can have a valid mld_id while mld_enable remains false (group not formed), which would make this function incorrectly report MLO enabled and suppress the “completely disabled” telemetry.

            if (vap->u.bss_info.mld_info.common_info.mld_id < MLD_UNIT_COUNT) {
                mlo_rfc_enable = true;
                break;
            }

[Copilot]

Pull request overview

Copilot reviewed 4 out of 4 changed files in this pull request and generated no new comments.

Suppressed comments (4)

source/core/wifi_ctrl.c:49

• To enforce a bounded retry policy for MLO RFC notifications, the status struct needs to track how many attempts have been made for the current notify cycle.

    int last_mlo_rfc_notify_task_id;

source/core/wifi_ctrl.c:3448

• If bus updates keep failing, this code will currently reschedule forever. Use the retry counter to stop after a bounded number of attempts and clear the pending flag to avoid an endless timer-task loop and log spam.

    if (scheduler_add_timer_task(wifi_mgr->ctrl.sched, FALSE,
            &mlo_rfc_status->last_mlo_rfc_notify_task_id, set_mlo_rfc_task, mlo_rfc_status, 1000, 1,
            FALSE) != RETURN_OK) {
        wifi_util_error_print(WIFI_CTRL, "%s:%d: Failed to reschedule timer task\n", __FUNCTION__,
            __LINE__);
        mlo_rfc_status->last_mlo_rfc_enable_notify_status_pending = false;
    }

source/core/wifi_ctrl.c:3512

• Retry state should be reset when starting a new notify cycle (boot/init or when the RFC state changes), otherwise a previous failure streak can incorrectly trigger the max-retry cutoff for a later update.

        memset(&mlo_rfc_status.param_notify_status, 0, sizeof(mlo_rfc_status.param_notify_status));
        mlo_rfc_status.last_mlo_rfc_enable_notify_status_pending = true;

source/core/wifi_ctrl.c:44

• The retry loop for MLO RFC notification reschedules indefinitely if bus updates keep failing (e.g., invalid param name or bus not ready), which can leave a permanent timer task and continuous error logging. Add an explicit max retry limit so the system can stop retrying and avoid runaway scheduler/log behavior.

This issue also appears in the following locations of the same file:

• line 49
• line 3442
• line 3511

#define MLO_RFC_NOTIFY_PARAM_COUNT 2