redpesk OS

With Salma, we tried to solve both SAFT's issues:

• during the wifi-binding initialisation phase, we had the same error than SAFT: ERROR: can't wait system unit afm-service-wifiap-binding--main.service for uid 1001: Resource temporarily unavailable [/builddir/build/BUILD/afb-app-manager-12.0.3/src/binding/afm-urun.c:303,afm_urun_once] The error is due that the binding has not finished its configuration phase while another service tries to use the same ressource. Fortunaly, changing the afm-util to afb-binder solves the issue but this is not a real solution. We're thinking to add something like a flag to indicate the initialisation phase is finished.
• Emmanuel from SAFT had an issue with the stability of the wifi when the NM command is removed. We didn't succeed to reproduce the bug even with some differents devices which use the binding during a use of one and half hour (with a phone which was connected to the WIFI access point). We can try longer but it seems that the issue concerns the SAFT's configuration...

We used the latest SolidSense Edge Gateway available at download.redpesk.bzh:
https://download.redpesk.bzh/redpesk-lts/arz-1.1/images/smack/minimal/aarch64/solidrun-edge-gateways/

[root@2a-aa-f4-2e-6e-0e ~]# uname -a
Linux 2a-aa-f4-2e-6e-0e 5.4.47-19.solidrun.edge.gateways.bsp.rparz_1.aarch64 #1 SMP PREEMPT Thu Feb 16 15:03:54 CET 2023 aarch64 aarch64 aarch64 GNU/Linux

One solution which could work has been discussed with José:

• Add the "TimeoutStartSec=infinity" in the file /usr/local/lib/systemd/system/afm-service-wifiap-binding--main.service

Because the wifi binding is blocked at start-up by the availability of resources managed by the NetworkManager. As a result, the service fails to start when the start-up delay expires.

• Adding directive "TimeoutStartSec=infinity" in service section of file /usr/local/lib/systemd/system/afm-service-wifiap-binding--main.service doesn't change the behaviour.
• Increasing binding startup delay from 15 to 45 seconds doesn't change the result either.

The framework includes a hard tempo of around 10 seconds. This explains why afm-util returned an error when the service was started.

This issue has been resolved. A RPM will be send to SAFT after a validation process. Salma changed the way the wifi access point starts. Indeed, we start the wifi access point once the binding has finished its initialisation phase.

Valentin Geffroy wrote in #note-8:

The framework includes a hard tempo of around 10 seconds. This explains why afm-util returned an error when the service was started.

This issue has been resolved. A RPM will be send to SAFT after a validation process. Salma changed the way the wifi access point starts. Indeed, we start the wifi access point once the binding has finished its initialisation phase.

Update: last thing to close the task was the latency issue. SAFT warned us about the bug, there is another internal task to solve it.