Agent

• 

  • Key Files and Their Purpose:

    1. dm_easy_mesh_agent.cpp:

       • Implements the data model for the EasyMesh agent
       • Handles processing of various commands like device initialization, station list management, channel selection, and configuration renewal
       • Translates between OneWifi (appears to be a proprietary system) and EasyMesh formats
       • Contains methods for analyzing different types of network events and messages

    2. em_agent.cpp:

       • Main implementation of the agent functionality
       • Contains event handlers for different types of messages (channel preferences, device initialization, etc.)
       • Manages the connections and configuration between devices
       • Includes DPP (Device Provisioning Protocol) onboarding capabilities
       • Contains the main() function that initializes and starts the agent

    3. em_cmd_agent.cpp:

       • Implements command handling for the agent
       • Contains socket-based communication methods to receive commands and send responses
       • Manages command execution and result handling

    4. em_simulator.cpp

       :
       • Provides simulation capabilities for testing
       • Primarily focused on simulating scan results
       • Creates mock network neighbors and scan data

  • Critical Areas for RDK-B Port

    • Data Model TR-181 Paths

      • // em_agent.cpp (line ~528) if (desc->bus_set_fn(&m_bus_hdl, "Device.WiFi.AccessPoint.1.RawFrame.Mgmt.Action.Tx", &raw_act_frame) == 0) // em_agent.cpp (line ~398) if (desc->bus_event_subs_fn(&m_bus_hdl, "Device.WiFi.CollectStats.AccessPoint.1.AssociatedDeviceStats", ...)) // em_agent.cpp (line ~393) if (desc->bus_event_subs_fn(&m_bus_hdl, WIFI_WEBCONFIG_GET_ASSOC, ...)) // dm_easy_mesh_agent.cpp (line ~901) if (desc->bus_set_fn(bus_hdl, "Device.WiFi.EM.ChannelScanRequest", &l_bus_data)== 0)

      • Explanation: These TR-181 data model paths need verification with RDK-B's implementation. While RDK-B uses TR-181, there might be differences in specific paths, parameter formats, or extensions. Verify each path exists and functions as expected in RDK-B's data model hierarchy. Also note the hardcoded index "1" in "AccessPoint.1" which might need to be dynamic based on the device configuration.

    • Bus Communication System

      • // em_agent.cpp (line ~366) bus_init(&m_bus_hdl); // em_agent.cpp (line ~371) if (desc->bus_open_fn(&m_bus_hdl, service_name) != 0) { printf("%s:%d bus open failed\n",__func__, __LINE__); return; } // em_agent.cpp (line ~389) if (desc->bus_event_subs_fn(&m_bus_hdl, WIFI_WEBCONFIG_DOC_DATA_NORTH, (void *)&em_agent_t::onewifi_cb, NULL, 0) != 0)

      • Explanation: RDK-B uses CCSP (Common Component and Service Platform) for component communication. The entire bus initialization, open, and subscription mechanism will need to be replaced with CCSP client libraries. You'll need to register your component with the CCSP bus, use CCSP's component registration, and adapt the callback mechanism to work with CCSP's event system.

    • OneWifi Integration

      • 
        

        // dm_easy_mesh_agent.cpp (line ~174) void dm_easy_mesh_agent_t::translate_onewifi_dml_data (char *str) // dm_easy_mesh_agent.cpp (line ~313) translate_onewifi_stats_data((char *)evt->u.raw_buff); // dm_easy_mesh_agent.cpp (line ~970) int dm_easy_mesh_agent_t::refresh_onewifi_subdoc(wifi_bus_desc_t *desc, bus_handle_t *bus_hdl, const char* logname, webconfig_subdoc_type_t type, m2ctrl_radioconfig *m2_cfg, em_policy_cfg_params_t *policy_config)

      • Explanation: OneWifi appears to be Comcast-specific and may not exist in RDK-B. This translation layer between OneWifi and EasyMesh data models will likely need complete replacement or adaptation to work with RDK-B's WiFi management system. You'll need to identify RDK-B's equivalent functionality for WiFi configuration management and adapt these translation functions accordingly.

    • WiFi HAL/Frame Construction

      • 
        

        // dm_easy_mesh_agent.cpp (line ~784-810) ieeeframe->u.action.category = WLAN_ACTION_WNM; ieeeframe->u.action.u.bss_tm_req.action = WLAN_ACTION_HT; ieeeframe->u.action.u.bss_tm_req.req_mode = *(uint8_t *)&req_mode; memcpy(&ieeeframe->u.action.u.bss_tm_req.disassoc_timer, &steer_req->btm_dissoc_timer, sizeof(steer_req->btm_dissoc_timer));

      • Explanation: This direct WiFi management frame construction bypasses hardware abstraction. RDK-B has its own WiFi HAL that should be used instead. All direct frame manipulation should go through RDK-B's WiFi HAL to ensure proper hardware compatibility and abstraction. This will require significant changes to how frames are created and sent on the network.

    • Configuration Storage

      • 
        

        // em_agent.cpp (line ~24) #define EM_CFG_FILE "/etc/EasymeshCfg.json" // em_agent.cpp (line ~378) while ((bus_error_val = desc->bus_data_get_fn(&m_bus_hdl, WIFI_WEBCONFIG_INIT_DML_DATA, &data)) != bus_error_success) // em_agent.cpp (line ~677) bool em_agent_t::try_create_default_em_cfg(std::string interface)

      • Explanation: RDK-B has specific locations and mechanisms for persistent storage of configuration data. The hardcoded path to "/etc/EasymeshCfg.json" will need to change to follow RDK-B conventions, which might use nvram or specific filesystem locations. The configuration creation and loading mechanisms will need adaptation to align with RDK-B's configuration management approach.

    • Service Management

      • 
        

        // em_agent.cpp (line ~370) char service_name[] = "EasyMesh_service"; // em_agent.cpp (line ~763) int main(int argc, const char *argv[])

      • Explanation: RDK-B components follow specific patterns for service registration and lifecycle management. The current standalone initialization in main() will need to be adapted to integrate with RDK-B's service management. This includes proper service registration, initialization sequencing, and potentially integration with systemd or another service manager used in RDK-B.

    • WebConfig System

      • 
        

        // dm_easy_mesh_agent.cpp (line ~177-189) webconfig_t config; webconfig_external_easymesh_t ext; webconfig_subdoc_type_t type; webconfig_proto_easymesh_init(&ext, this, NULL, NULL, get_num_radios, set_num_radios, get_num_op_class, set_num_op_class, get_num_bss, set_num_bss, get_device_info, get_network_info, get_radio_info, get_ieee_1905_security_info, get_bss_info, get_op_class_info, get_first_sta_info, get_next_sta_info, get_sta_info, put_sta_info, get_bss_info_with_mac, update_scan_results); config.initializer = webconfig_initializer_onewifi; config.apply_data = webconfig_dummy_apply;

      • Explanation: WebConfig in RDK-B has specific implementations that differ from this custom version. The entire WebConfig initialization and processing will need to align with RDK-B's approach. This may require significant changes to how configuration is processed, validated, and applied. RDK-B's WebConfig system typically follows a standardized approach for TR-181 data model configuration.

    • Logging System

      • 
        

        // Throughout code, examples: // em_agent.cpp (line ~371) printf("%s:%d bus open failed\n",__func__, __LINE__); // dm_easy_mesh_agent.cpp (line ~188) printf( "[%s]:%d Init WiFi Web Config fail\n",__func__,__LINE__);

      • Explanation: RDK-B uses a standardized logging system with RDK_LOG macros for consistent log formatting, filtering, and collection. All printf statements should be replaced with RDK-B's logging system to ensure proper integration with log management and monitoring tools. This also enables better troubleshooting in production environments through log level control.

    • Socket/IPC Mechanisms

      • 
        

        // em_agent.cpp (line ~24) #define SOCKET_PATH "/tmp/ieee1905_tunnel" // em_cmd_agent.cpp (line ~134) snprintf(m_sock_path, sizeof(m_sock_path), "%s_%s", EM_PATH_PREFIX, EM_AGENT_PATH);

      • Explanation: While both platforms use Unix domain sockets, RDK-B might have specific conventions for socket paths and permissions. The hardcoded socket paths should be adapted to follow RDK-B conventions. Additionally, inter-process communication in RDK-B often uses CCSP or other standardized mechanisms that might be preferred over direct socket communication for component interaction.

    • Direct Hardware Access

      • 
        

        // Implied in function from em_agent.cpp (line ~681) if (dm_easy_mesh_t::mac_address_from_name(interface.c_str(), if_mac) < 0){ printf("%s:%d: Failed to get MAC address for interface: %s\n", __func__, __LINE__, interface.c_str()); return false; }

      • Explanation: This function likely uses direct system calls or ioctl operations to access hardware information. In RDK-B, all hardware access should go through appropriate abstraction layers. Functions that directly access hardware information, such as getting MAC addresses from interfaces, should be replaced with calls to RDK-B's hardware abstraction layers or system APIs to ensure proper hardware independence.