Houssem Dafdouf 60fe655337 bwl: agent: fix amxb_usp events not received
Problem:
--------

The agent process is not receiving pwhm events over usp direct socket.

Cause:
------

beerocks_agent connects simultaneously to both ubus and usp direct
socket.
The following initialization sequence exposes several limitations in
libamxb and amxb_usp:

1 - Load and connect to ubus
2 - Load usp backend
3 - Set usp configuration
4 - Connect to usp socket

In step 1:

An internal libamxb configuration is created without a usp section.

In step 2:

- When loading usp backend the previous configuration (which doesn't
include any usp section) is automatically set to amxb_usp. As a
"limitation" in amxb_usp, this will result into a NULL amxb_usp
configuration (ie config_opts = NULL).

- As a consequence no EndPointID (needed later by usp LocalAgent to
created imtp handshake) can be created and later events subscription
will fail internally. The fail is not returned by the subscribe API
which is yet another problem.

In step 3:

- Calling amxb_set_config has no effect because the configuration is
applied only to backends listed in the load_order.

- Since the usp backend was not added to load_order list (internal to
libamxb) in step 2, the USP configuration is never applied. (This
appears to be another limitation in libamxb.)

Solution:
---------

Invert steps 2 and 3.

By setting the usp configuration before loading the backend, the usp
section is present in the internal libamxb configuration. As a result,
when the usp backend is loaded, it receives a non-NULL configuration,
allowing the EndPointID to be created correctly and enabling successful
event subscription.

Fixes: PPW-1208
Signed-off-by: Houssem Dafdouf <houssem.dafdouf_ext@softathome.com>
2025-12-17 11:50:59 +01:00
2025-05-16 11:04:25 +02:00
2020-03-26 09:54:48 +00:00
2025-05-16 11:04:25 +02:00
2020-04-07 14:42:43 +00:00
2023-11-22 21:33:34 +01:00

prplMesh

Build Status

prplMesh is an open-source, carrier-grade and certifiable implementation of the WiFi Alliances Multi-AP specification.

The result will be source-code covering both the agent and the controller part of the Multi-AP specification. However, it is scoped as a reference implementation and will leave ample room for differentiation, for example for proprietary IP algorithms making intelligent decisions for the whole Multi-AP network.

In short, the projects aim is to create a baseline for OEMs and developers to easily integrate Multi-AP into various products and platforms. Initial targets include prplWrt and RDK-B with support for WiFi chipsets from almost any SoC vendor to be used in residential gateways, WiFi extenders from both retail brands and internet service providers.

This project is part of a wider collaboration between Prpl Foundation and Broadband Forum, and is based on a proven full mesh solution contributed by Intel Corp (Controller and Agent running on actual HW).

Architecture documentation can be found in the documentation folder.

The latest build artifacts are always accessible.

Fetch Sources

If you haven't done so already, set up your git configuration:

git config --global user.email your@email.address
git config --global user.name "Your Name"

If you already have a gitlab account:

git clone ssh://git@gitlab.com/prpl-foundation/prplmesh/prplMesh.git

Otherwise

git clone https://gitlab.com/prpl-foundation/prplmesh/prplMesh.git

Build in Docker

See corresponding README

Native Build

As an alternative to the manual steps outlined below, tools/maptools.py can be used to build and install prplMesh with a single command.

Requirements

An up-to-date list of packages you need to build prplMesh on Ubuntu (18.04) is available in the Dockerfile This is used in our automated builds, so is guaranteed to be up to date. As of the time of writing, it includes the following packages:

  • binutils
  • cmake
  • gcc
  • git
  • libjson-c-dev
  • libncurses-dev
  • libnl-3-dev
  • libnl-genl-3-dev
  • libnl-route-3-dev
  • libssl-dev
  • ninja-build
  • pkg-config
  • python
  • python-yaml
  • python3
  • python3-yaml
  • bison
  • curl
  • flex
  • libevent-dev
  • libyajl-dev
  • lua5.1
  • liblua5.1-0-dev
  • build-essential
  • clang-format
  • gcovr
  • bridge-utils
  • ebtables
  • iproute2
  • net-tools
  • psmisc
  • uuid-runtime

Run Build

Use standard CMake to build prplMesh, with a configure-build-install cycle.

To build prplMesh natively in debug mode (for being able to debug with gdb), with all features and tests, and installed in a local directory, run

cmake -DBUILD_TESTS=ON -DCMAKE_BUILD_TYPE=Debug -DCMAKE_INSTALL_PREFIX=../build/install -H. -B../build -G Ninja
ninja -C ../build install

If you prefer, make can be used instead of ninja by removing the -G Ninja part in 1st command and by replacing ninja with make in 2nd one.

Install

For system-level install, the standard DESTDIR approach can be used for installing prplMesh as a package.

DESTDIR=/tmp/prplMesh-install ninja install

Running Instructions

Once built, prplMesh controller, agent and framework can be started using prplmesh_utils.sh:

cd <path/to/install/dir>/scripts
sudo ./prplmesh_utils.sh start

Debugging Instructions

To debug prplMesh controller, agent or cli it is needed to install 'Native Debug' extension for Visual Studio Code. Also prplMesh solution should be compiled with CMAKE_BUILD_TYPE=Debug flag. Debug instruction:

  1. Start prplMesh solution(read Running Instructions)
  2. To remote debug it is needed to start gdbserver
gdbserver :9999 --attach <pid of controller/agent/cli>
  1. Go to debug tab in the VSCode and choose one the option from the dropdown list.
  2. Add breakpoint and click start debugging.

Log files locations

  • framework /tmp/mapf
  • controller /tmp/beerocks/logs/beerocks_controller.log
  • platform manager & backhaul manager /tmp/beerocks/logs/beerocks_backhaul.log
  • agent /tmp/beerocks/logs/beerocks_agent.log
  • agent fronthaul ap manager wlan0 /tmp/beerocks/logs/beerocks_ap_manager_wlan0.log
  • agent fronthaul ap monitor wlan0 /tmp/beerocks/logs/beerocks_monitor_wlan0.log
  • agent fronthaul ap manager wlan2 /tmp/beerocks/logs/beerocks_ap_manager_wlan2.log
  • agent fronthaul ap monitor wlan2 /tmp/beerocks/logs/beerocks_monitor_wlan2.log

Checking status

System is operational if you see FSM: CONNECTED --> OPERATIONAL in the main agent log. In the future there will be a bml cli command to verify operational state.

Displaying the connection map (GUI)

There is a tool to display the connection map on a GUI in tools/beerocks_analyzer. Its README file explains how to use it.

Troubleshooting

If master branch does not work / does not pass tests on your computer make sure that:

  • you loaded ebtables kernel module: sudo modprobe ebtables
  • you updated your docker images with tools/docker/image-build.sh
Description
WFA Multi-AP implementation
Readme 583 MiB
Languages
C++ 91.2%
Python 6.1%
Shell 1.1%
CMake 0.8%
C 0.6%
Other 0.2%