Bug #48
closed
Wifiap needs some workarounds to work
100%
Description
Two workarounds are needed in emojy-service in order for wifiap-binding to start and work perfectly.
- A delay of 15 seconds (
sleep 15). - A NetworkManager command telling it to not manage wlan0 (
nmcli dev set wlan0 managed off).
When the delay is removed, wifiap-binding can't start and this error gets logged in the system journal:
afm-system-daemon[406]: ERROR: can't wait system unit afm-service-wifiap-binding--main.service for uid 1001: Resource temporarily unavailable [/builddir/build/BUILD/afb-app-manager-10.0.1/src/afm-urun.c:301]
When the NM command is removed wifiap-binding starts but the wifi AP is unstable and connection losses occur periodically.
Updated by
Updated by Valentin Geffroy 10 months ago
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 theafm-utiltoafb-bindersolves 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
Updated by Valentin Geffroy 10 months ago
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.
Updated by Emmanuel Jubera [SAFT] 10 months ago
- 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.
Updated by Valentin Geffroy 9 months ago
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.
Updated by Sebastien Douheret [IoT.bzh] 8 months ago
- Assignee changed from Salma RAISS to Valentin Geffroy
Updated by Valentin Geffroy 7 months ago
- Status changed from In Progress to Resolved
Updated by Valentin Geffroy 7 months ago
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.