Versions Compared

Old Version 1

changes.mady.by.user Kanupriya Pandey

Saved on

compared with

New Version Current

changes.mady.by.user Kanupriya Pandey

Saved on

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

OneWifi Internal Architecture

Component Architecture

The internal functional entities of the OneWifi process are as shown in the above diagram. OneWifi software architecture is essentially a multi-threaded software architecture, the three main threads are 

  • Core thread: this thread is the fundamental engine of the process that is responsible for all configuration of WiFi parameters, command/control/status response and WiFi state indications. The core thread is also responsible for steering related activities.
  • DML thread: this thread handles the TR-181 set/get handlers. 
  • Apps thread: this thread is responsible for supporting all WiFi related application/features such as harvester, motion sensing, blaster, single client measurements etc.

The software architecture of working of each thread is detailed below.


OneWiFi Thread Management, Inter Thread Communication and Data Handling

The diagram below depicts thread management and inter thread communication and data transfer in OneWifi. Threads essentially wait for condition and timeouts. If data needs to be processed, the data is posted into queue and the thread is signaled. The thread retrieves the data from the queue and processes the data.


Core Functional Blocks/Subsystem

The core thread waits for events or messages, if there are events or messages in the FIFO queue, the thread retrieves the events or messages one after another and takes appropriate action. Three kinds of messages or events can be enqueued in the Core thread queue

  1. South bound messages received from WebConfig Agent or Ovsdb Managervia RBUS callback.
  2. South bound messages received from DML thread because of TR-181 set handler invocation
  3. North bound asynchronous Wi-Fi events from HAL or driver isuch as
    1. Client associations/disassociations
    2. VAP or interface Up/Down
    3. Registered 802.11mgmt frame reception
    4. Band Steering events

All south bound messages are decoded, parsed and validated by core thread. In case, the messages are successfully validated, the core thread uses Wi-Fi HAL function to configure Wi-Fi driver or baseband accordingly. if successful, core thread is also resonsible for updating the persistent database so that in case of reboot or power failure, the Wi-Fi subsystem of the CPE device maintain previous operating configuration. Core thread also handles Wi-Fi or Factory reset commands that may be triggered by messages enqueued by DML thread or during initialization sequence.

All north bound events are translated to state update in ovddb state tables using WebConfig encoded messages sent by core to ovsdb manager.


Core Thread Software Architecture

Some of the components described are as follows:

  • Config Tracker - serves as an internal database for all Radio and VAP attributes. To be consumed by OneWifi internals, eg. stats policies, steering policies, configuration applicator, etc. Intended to be acting as a south bound interface and called by adapters to integrate them into specific systems, eg. rbus+webconfig.
  • State Tracker - serves as a layer to shield OneWifi business logic modules from HAL API which is intended to not be fully object oriented.and to simplify its implementation, eg. event buffer overrun recovery handling, event order sanitization (sometimes implementations source events from multiple streams and their processing ordering is undefined).
  • Configuration Applicator - uses inputs: Config Tracker and other mutators (coming from, eg. Stats or Steering policies) to generate configuration command(s) and submit them only if the assembled configuration command is out-of-sync with what State Tracker is reporting. Configuration Applicator is triggered for recompute by either Config Tracker, State Tracker or any of the registered mutators.
  • Steering/Stats/Other policies - multiple entities implementing specific actions. Mostly interact with State Tracker, Configuration Applicator (as mutators), HAL wrapper (to perform world-visible actions) or between each other modules (Steering modules using some Stats).
  • Rbus-webconfig adapter - adaptation logic which feeds Config Tracker based on Webconfig blobs. Essentially a translator to abstract Webconfig away from core logic. Foo thread / foo adapter - approach recommended on integrating other existing, or thread-heavy tasks. The OneWifi core is a single thread expecting no other threads interacting directly with its data structures or control flows, so adapters and their dispatch handlers are expected to be the entry/exit points between threads to simplify locking.
  • HAL wrapper - virtually a HAL API that allows multiple backing implementations: Wifi HAL, Target API or other in the future. Intended to be mostly stateless and simple "pass through" - allowing out-of-order event delivery, etc. This allows simpler implementation for vendors. The task of sanitizing is handed to State Tracker for actual business logic consumers. The HAL wrapper API is highly aggregated (big blob call for configuration, singular calls for adequate actions like WPS PBC) with hints on which attributes are out-of-sync allowing implementations to optimize if desired. The wrapper is also capable of supporting multiple backing implementations at the same time (without requiring business logic implementation to be aware of any of that) to accommodate mixed vendor chips (on non-Wifi-Hal platforms) such as Broadcom + Quantenna.

All components are intended to schedule most of the actual work through separate dispatch handlers per object entities. This allows easy batching (to debounce and reduce ping-pong), time occupancy (to provide insight into possible stalls, or aid scheduling), forces idempotency (avoids some ab/ba logic issues, provides failure recovery procedures without additional explicit logic) and makes sure memory resource allocation is bound.


Apps Functional Blocks/Subsystem



Operational Modes

OneWifi can operate in two modes, router and extender. 

Router Mode

In router mode, the stack broadcasts front haul virtual access points that client devices may connect with. Total of seven such virtual access points are created on each radio and provide different kinds of services. 

Extender Mode

TBD


Flow Diagram/Pseudo Code

Core Thread Pseudo Code

PlantUML Macro
formatPNG
aligncenter
@startuml
skinparam defaultTextAlignment center
!pragma useVerticalIf on
start
:core_thread_start_function;
:rbus_register\n(rbus_message_cb)|
:read_wifi_ps_db|
:wifi_hal_init|
:wifi_hal_events_register\n(wifi_hal_cb)|
repeat :for_each_radio
:wifi_hal_setRadioOperatingParams|
:wifi_hal_createVAP|
repeat while()
repeat :event_queue_wait;
split
    :rbus_event\n(web_config_message)<
    :decode_message|
    if (msg eq webconfig_msg) then (yes)
        if (validate_msg() eq SUCCESS) then (yes)
            :rbus_send_to_webconfig(ACK)>
        else (no)
            :rbus_send_to_webconfig(NACK)>
            stop
        endif
        if (wifi_hal_func() eq SUCCESS\n(HAL Wrapper)) then (yes)
            :write_wifi_ps_db|
            :rbus_send_to_webconfig(SUCCESS)>
        else (no)
            :rbus_send_to_webconfig(FAILURE)>
        endif
    elseif (msg eq ovdsbmgr_msg) then (yes)
        if (validate_msg() eq SUCCESS) then (yes)
            :rbus_send_to_ovsdbmgr(ACK)>
        else (no)
            :rbus_send_to_ovsdbmgr(NACK)>
            stop
        endif
        if (wifi_hal_func() eq SUCCESS\n(HAL Wrapper)) then (yes)
            :write_wifi_ps_db|
            :rbus_send_to_ovsdbmgr(SUCCESS)>
        else (no)
            :rbus_send_to_ovsdbmgr(FAILURE)>
        endif
    endif
split again
    :dml_event\n(web_config_message)<
    :decode_message|
    if (validate_msg() eq SUCCESS) then (yes)
        if (wifi_hal_func() eq SUCCESS) then (yes)
            :write_wifi_ps_db|
        endif
    endif
split again
    :hal_event\n(hal_cb_event)<
    if (event eq assoc_event) then (yes)
        :create_ovsdb_state_blob)|
        :rbus_send_to_ovsdbmgr(json_blob)>
    elseif (event eq disassoc_event) then (yes)
        :create_ovsdb_state_blob)|
        :rbus_send_to_ovsdbmgr(json_blob)>
    elseif (event eq vap_up_event) then (yes)
        :create_ovsdb_state_blob)|
        :rbus_send_to_ovsdbmgr(json_blob)>
    elseif (event eq vap_down_event) then (yes)
        :create_ovsdb_state_blob)|
        :rbus_send_to_ovsdbmgr(json_blob)>
    elseif (event eq bsal_event) then (yes)
        if (bsal_event eq bsal_event_probe_req) then (yes)
            :handle_bm_probe|
        elseif (bsal_event eq bsal_event_client_connect) then (yes)
            :handle_bm_client_connect|
        elseif (bsal_event eq bsal_event_client_disconnect) then (yes)
            :handle_bm_client_disconnect|
        elseif (bsal_event eq bsal_event_rssi_xing) then (yes)
            :handle_bm_rssi_xing|
        endif
    endif
split again
    :timeout<
    :stats_collection|
end split
repeat while()
:core_thread_end;
stop

start
:rbus_message_cb;
:create_rbus_event|
:event_queue_push(rbus_event)>
stop

start
:wifi_hal_cb;
:create_hal_event|
:event_queue_push(hal_event)>
stop

@enduml


Message Sequence Diagrams

Initialization

PlantUML Macro
formatPNG
aligncenter
@startuml
hide footbox
skinparam SequenceMessageAlign center
participant AGENT as "Core Thread"
participant HAL as "WiFi HAL Wrapper"
participant HOSTAP as "hostap"
participant DRIVER as "WiFi Driver"
participant LINUX as "Linux System"

group ctrl-plane
AGENT -> HAL: wifi_init
group Interfaces Enumeration
HAL -> LINUX: nl_80211cmd(NL80211_CMD_GET_WIPHY, NLM_F_DUMP, wiphy_dump_handler)
LINUX -> HAL: wiphy_dump_handler(NL80211_ATTR_WIPHY = 0, NL80211_ATTR_WIPHY_NAME, NL80211_ATTR_SUPPORTED_COMMANDS)
LINUX -> HAL: wiphy_dump_handler(NL80211_ATTR_WIPHY = 1, NL80211_ATTR_WIPHY_NAME, NL80211_ATTR_SUPPORTED_COMMANDS)
LINUX -> HAL: wiphy_dump_handler(NL80211_ATTR_WIPHY = 2, NL80211_ATTR_WIPHY_NAME, NL80211_ATTR_SUPPORTED_COMMANDS)
end
group for each Interface
HAL -> LINUX: HAL -> LINUX: nl_80211cmd(NL80211_CMD_GET_WIPHY, NL80211_ATTR_WIPHY = i, wiphy_get_info_handler)
LINUX -> HAL: wiphy_get_info_handler(NL80211_ATTR_CIPHER_SUITES, NL80211_ATTR_WIPHY_BANDS)
group for each band in NL80211_ATTR_WIPHY_BANDS
HAL -> HAL: phy_info_frequencies
HAL -> HAL: phy_info_ht_capa
HAL -> HAL: phy_info_vht_capa
HAL -> HAL: phy_info_rates
end group
end
HAL -> HOSTAP: eloop_init
HAL -> HOSTAP: eap_server_register_methods
HAL --> AGENT: Success
AGENT -> HAL: wifi_getHalCapability
HAL <-> DRIVER: get phy device capabilities
HAL --> AGENT: Success
group for each Radio
AGENT -> HAL: wifi_setRadioOperatingParameters(index, radio_param)
HAL <-> DRIVER: set radio parameters
HAL -> HOSTAP: update_hostap_config_params (update struct hostapd_config for this radio)
HAL --> AGENT: Success
AGENT -> HAL: wifi_createVAP(radio, vap_map)
group for each VAP
HAL --> LINUX: create interface
group vap_mode_ap
HAL -> LINUX: nl80211_cmd(NL80211_CMD_SET_INTERFACE, NL80211_IFTYPE_AP)
HAL -> HOSTAP: update_hostap_data (update struct hostapd_data for this interface)
HAL -> HOSTAP: update_hostap_bss (update struct hostapd_bss_config for this interface)
HAL -> HOSTAP: update_hostap_iface (update struct hostapd_iface for this interface)
HAL -> HOSTAP: setup_driver(wpa_drv_ops)
HAL -> HOSTAP: drv_init
HAL -> HOSTAP: hostapd_setup_bss(hostapd_data)
HOSTAP -> HAL: flush
HAL -> DRIVER: wifi_drv_flush
HOSTAP -> HAL: sta_deauth
HAL -> DRIVER: wifi_drv_sta_deauth
HOSTAP -> HAL: set_key
HAL -> DRIVER: wifi_drv_set_key
HOSTAP -> HAL: set_ap
HAL -> DRIVER: wifi_drv_set_ap
HOSTAP -> HAL: set_operstate
HAL -> DRIVER: nl80211_register_mgmt_frames(NL80211_CMD_FRAME, process_mgmt_frame)
HAL -> LINUX: bridge_rx(raw socket listen)
end
group vap_mode_sta
HAL -> LINUX: nl80211_cmd(NL80211_CMD_SET_INTERFACE, NL80211_IFTYPE_STA)
HAL -> LINUX: nl80211_start_scan(NL80211_CMD_TRIGGER_SCAN)
HAL -> LINUX: interface_rx(raw socket listen)
end
end
HAL --> AGENT: Success
end
AGENT -> HAL: wifi_run
HAL -> HOSTAP: eloop_run
HOSTAP -> HOSTAP: eloop
end

@enduml

Client Authentication

PlantUML Macro
formatPNG
@startuml
hide footbox
skinparam SequenceMessageAlign center
participant HAL as "WiFi HAL Wrapper"
participant HOSTAP as "hostap"
participant DRIVER as "WiFi Driver"
participant LINUX as "Linux System"
participant STA as "Client Device"

group client authentication (WPA2 and WPA3 handshakes)
group mlme
STA -> DRIVER: Auth Frame
DRIVER -> HAL: process_mgmt_frame(NL80211_ATTR_FRAME, frame = auth)
HAL -> HOSTAP: wpa_supplicant_event(EVENT_RX_MGMT, event.frame = frame)
HOSTAP -> HAL: send_mlme(auth)
HAL -> DRIVER: wifi_drv_send_mlme(auth)
DRIVER -> STA: Auth Frame
STA -> DRIVER: Assoc Req Frame
DRIVER -> HAL: process_mgmt_frame(NL80211_ATTR_FRAME, frame = assoc req)
HAL -> HOSTAP: wpa_supplicant_event(EVENT_RX_MGMT, event.frame = assoc req)
HOSTAP -> HAL: send_mlme(assoc resp)
HAL -> DRIVER: wifi_drv_send_mlme(assoc resp)
DRIVER -> STA: Assoc Resp Frame
DRIVER -> HAL: nl80211_event(NL80211_CMD_FRAME_TX_STATUS)
HAL -> HOSTAP: wpa_supplicant_event(EVENT_TX_STATUS)
end
group non-mlme
STA -> DRIVER: Auth Frame
DRIVER -> STA: Auth Frame
STA -> DRIVER: Assoc Req Frame
DRIVER -> STA: Assoc Resp Frame
DRIVER -> HAL: nl80211_event(NL80211_CMD_NEW_STATION)
HAL -> HOSTAP: wpa_supplicant_event(EVENT_TX_ASSOC)
end
note over HOSTAP
    start 802.1x authentication
end note
HOSTAP -> HAL: hapd_send_eapol(EAPOL 1/4)
HAL -> DRIVER: bridge_tx(EAPOL 1/4)
DRIVER -> STA: EAPOL 1/4
STA -> DRIVER: EAPOL 2/4
DRIVER -> HAL: bridge_rx (EAPOL 2/4)
HAL -> HOSTAP: wpa_supplicant_event(EVENT_EAPOL_RX, event.frame = eapol)
HOSTAP -> HAL: hapd_send_eapol(EAPOL 3/4)
HAL -> DRIVER: bridge_tx(EAPOL 3/4)
DRIVER -> STA: EAPOL 3/4
STA -> DRIVER: EAPOL 4/4
DRIVER -> HAL: bridge_rx (EAPOL 4/4)
HAL -> HOSTAP: wpa_supplicant_event(EVENT_EAPOL_RX, event.frame = eapol)
HOSTAP -> HAL: set_key
HAL -> DRIVER: wifi_drv_set_key
HOSTAP -> HAL: set_sta_flags
HAL -> DRIVER: wifi_drv_set_sta_flags
end

@enduml


Debugging:

Differences Between Ccsp and One WiFi

Apply Settings:

Info

Ccsp :

dmcli eRT setv Device.WiFi.Radio.2.X_CISCO_COM_ApplySetting bool true
dmcli eRT setv Device.WiFi.Radio.1.X_CISCO_COM_ApplySetting bool true


OneWiFi:


Any dmcli commands specific to SSID and AccessPoint execute the Below Access Point Related apply settings

dmcli eRT setv Device.WiFi.ApplyAccessPointSettings bool true


Any dmcli executions specific to Radio level use the below Radio apply settings command 

dmcli eRT setv Device.WiFi.ApplyRadioSettings bool true


Below are the list of logs present in /rdklogs/logs for Debugging OneWiFi Issues

For Additional indepth  Debugging one should enable below commands

Info

touch /nvram/wifiMgrDbg

touch /nvram/wifiDbDbg

touch /nvram/wifiWebConfigDbg

touch /nvram/wifiHalDbg

touch /nvram/wifiCtrlDbg

touch /nvram/wifiMonDbg

touch /nvram/wifiDMCLI

touch /nvram/wifiLib

touch /nvram/wifiLibhostapDbg

Check for the respective logs in tmp

Info

tail -f wifiCtrl &

tail -f wifiHal &

tail -f wifiMgr &

tail -f wifiDMCLI &

tail -f wifiDb &

tail -f wifiWebConfig &

tail -f wifilibhostap &