mothishree/onewifi

Purpose and process entry

OneWifi is the RDK-B WiFi-management component for gateways and extenders. It manages radios, VAPs, clients, security, mesh, telemetry, and optimization while translating management-plane requests into WiFi HAL operations. The service-support process entry and lifecycle are in:

• source/dml/wifi_ssp/ssp_main.c

• source/dml/wifi_ssp/ssp_loop.c

• scripts/onewifi.service

Central orchestration and event control

wifi_mgr owns global WiFi state, discovered capabilities, and subsystem handles. wifi_ctrl is the asynchronous control boundary: it accepts queued configuration, HAL, timer, and application events, then executes hardware-facing apply flows. This separates request handlers from potentially slow or stateful radio/VAP operations.

• source/core/wifi_mgr.c

• source/core/wifi_ctrl.c

• source/core/wifi_ctrl_queue_handlers.c

Configuration ingress: TR-181 and WebConfig

Northbound management has two primary paths. TR-181/DML exposes Device.WiFi.* through RBus/CCSP callbacks. Cloud WebConfig accepts JSON subdocuments, decodes and validates them, and translates bulk updates into the internal model. Both converge on manager/database/control flows rather than calling hardware directly.

• source/dml/tr_181/ml/cosa_wifi_dml.c

• source/webconfig/wifi_decoder.c

• source/core/wifi_ctrl_webconfig.c

Schemas and persistent interface contracts are rooted in:

• config/TR181-WiFi-USGv2.XML

• config/subdoc_schemas_1_4/

• config/rdkb-wifi.ovsschema

State, persistence, and consistency boundary

The database layer owns WiFi configuration/state persistence and database APIs; OVSDB support includes cache, table, update, and synchronous client primitives. Configuration writes are persisted before or alongside control events, while runtime/HAL outcomes update operational state. PSM is an external RDK-B persistence dependency.

• source/db/wifi_db.c

• source/db/wifi_db_apis.c

• lib/ovsdb/ovsdb_cache.c

Southbound WiFi and VAP services

The core converts normalized state into WiFi HAL actions and handles HAL-originated events. VAP service implementations encapsulate service-specific behavior for private, public, and mesh VAPs, keeping those policies out of generic control processing. Platform adapters isolate RDK-B, Linux, OpenWrt, DBus, and bus-specific differences.

• source/core/wifi_data_plane.c

• source/core/services/vap_svc.c

• source/services/wifi_services_mgr.c

Material runtime dependencies are the WiFi HAL, hostapd/wpa_supplicant and Linux networking beneath it; RBus/CCSP provide inter-component control.

Modular applications, measurement, and telemetry

An application manager loads enabled feature modules and routes relevant events. Major modules include EasyMesh, station management, CAC/DFS, CSI/motion sensing, Blaster measurement, analytics, harvester, and client/link-quality steering. Statistics collection is a distinct periodic path that produces measurements and supports telemetry serialization/reporting.

• source/apps/wifi_apps_mgr.c

• source/apps/em/wifi_em.c

• source/stats/wifi_monitor.c

Telemetry/data-pipeline integration is represented by:

• lib/datapipeline/dppline.c

• config/WifiSingleClient.avsc

Primary runtime flow

Startup initializes platform/bus support, manager state, database, HAL-facing control, and enabled apps. At runtime: TR-181/RBus or WebConfig JSON → validation/translation → manager and DB update → queued control event → HAL/VAP apply → state/cache update and notifications. The reverse path is hardware event → control queue → state/database update → applications, DML/RBus, and telemetry consumers. Build targets support Linux and OpenWrt variants, with optional mesh, WiFi 7/MLO, and feature applications.

• build/linux/makefile.common

• build/openwrt/Makefile_package

• configure.ac