Ma borne est une CAP-AC et pas AX, et la AX est plus grande.

Dans les constructions neuves, la norme ne permets pas de laisser un gaine en attente qui pends au plafond. Donc il faut mettre une boite d'encastrement au plafond.
Je ne pense pas que le support fourni s'aligne sur les vis de la boite d'encastrement, d'où le problème.

Le site de Mikrotik ne mentionne pas les dimensions du CAP-ax, si vous en avez un, vous pouvez me donner le diamètre ?

Je n'ai pas encore la version la plus récente du firmware "G03.R09.C04_00" mais la détection dans "Mes équipements connectés" ne fonctionnerait elle pas mieux depuis aujourd'hui ?

Plusieurs fois que je vais dans la page et l'affichage des appareils connectés à la box se fait nettement plus rapidement et j'ai bien la totalité des appareils !

Bizarre que ça refonctionne alors que j'ai fait 0 changement ni installé un nouveau firmware.

(la version que j'ai : G03.R09.C02_02)

@unipo :

Je pense que l'info d'authentification est générée puis envoyée par ubus à odhcp6c. Il semblerait que ton script de régénération ne soit pas appliqué.

uci commit on the cli will not trigger service reloads, you'll have to manually call /sbin/reload_config afterwards.

LuCI uses the ubus uci namespace (ubus call uci commit ...) which will emit change events for any committed /etc/config/xxx file which are then in turn processed by services having a reload trigger installed (grep -r procd_add_reload_trigger /etc/init.d/)

Hyperlien : https://forum.openwrt.org/t/addition-of-new-services-to-openwrt/40479/3

Cette commande vérifie l'état des configurations et déclenche un événement ubus "config.change".

Specifying triggers

While start_service() takes care of setting service instances states and submitting them to the procd (for a potential service restart), it has to be explicitly called to do so. In most cases it should happen on some related change.

That's where service_triggers() comes in handy and allows specifying triggers. Most system important changes result in generating events that service_triggers() can use for triggering various actions. There are multiple procd_add_*_trigger() helpers for that purpose.

Every configurable service has to specify what system changes should result in its reconfiguration. Those events should be defined in the service_triggers() using available helpers. When related procd service event occurs it will result in executing /etc/init.d/<foo> reload.

Example:

service_triggers()
{
        procd_add_reload_trigger "<uci-file-name>" "<second-uci-file>"
        procd_add_reload_interface_trigger <interface>
        procd_add_reload_mount_trigger <path> [<path> ...]
}

Function    Arguments    Event used    Description
procd_add_reload_trigger    list of config files    config.change    Uses /etc/init.d/<foo> reload as the handler
procd_add_reload_interface_trigger    interface name    interface.*    Uses /etc/init.d/<foo> reload as the handler
procd_add_reload_mount_trigger    paths to watch for    mount.add    Uses /etc/init.d/<foo> reload as the handler
procd_add_restart_mount_trigger    paths to watch for    mount.add    Uses /etc/init.d/<foo> restart as the handler

When using uci from command line uci commit doesn't generate config.change event. It requires calling reload_config afterwards.

This does not apply to using uci over rpcd plugin.

Hyperlien : https://openwrt.org/docs/guide-developer/procd-init-scripts#specifying_triggers

Je crois que cela exécute la fonction reload_service() définit dans le service network.

reload_service() {
        local rv=0

        init_switch
        ubus call network reload || rv=1
        return $rv
}

Il me semble que c'est équivalent à service network reload.

#!/bin/sh

main() {
        local service="$1"
        shift

        local boot status

        if [ -f "/etc/init.d/${service}" ]; then
                /etc/init.d/"${service}" "$@"
                exit "$?"
        fi

        if [ -n "$service" ]; then
                echo "Service \"$service\" not found:"
                exit 1
        fi

        echo "Usage: $(basename "$0") <service> [command]"
        for service in /etc/init.d/* ; do
                boot="$($service enabled && echo "enabled" || echo "disabled" )"
                status="$( [ "$(ubus call service list "{ 'verbose': true, 'name': '$(basename "$service")' }" \
                        | jsonfilter -q -e "@['$(basename "$service")'].instances[*].running" | uniq)" = "true" ] \
                        && echo "running" || echo "stopped" )"

                printf "%-30s\\t%10s\\t%10s\\n"  "$service" "$boot" "$status"
        done
}

main "$@"



reload    If the service supports this operation (usually by sending SIGHUP signal) then reload configuration files on the fly without stopping. Otherwise if the service does not implement reload then make a full restart (stop then start).

Hyperlien : https://openwrt.org/docs/guide-user/base-system/managing_services

Cela (procd avec reload_config) appelle la commande ubus call network reload. Les clients DHCP sont gérés par netifd. Je crois qu'udhcpc ne supporte pas de mécanisme inter-processus.
Je ne sais pas comment cela fonctionne. Peut-être que cela redémarre udhcpc ?