Absence de reconnexion WiFi automatique

Matériel Jeedom - Hardware La Box JEEDOM ATLAS
1

Bonjour à tous,

J’ai une Jeedom Atlas (actuellement en 4.53) mais depuis des années (depuis l’achat) j’ai le même problème : Dans certains cas de perte du WiFi il n’y a pas de reconnexion.

Ce n’est pas toujours le cas, donc je suppose qu’il y un état WiFi plus qu’un autre qui cause cela : Par exemple le réseau absent, ou le mot de passe non accepté qui cause cela.

Je voulais refaire le point sur ce sujet, car en l’absence de connexion en console difficile de voir ce qui se passe réellement; un reboot et ça repart.

Mes questions : Quel est le gestionnaire du WiFi ? Où regarder les fichiers de config, les paramètres de retry, etc.

Merci d’avance,

2

Bonjour
Déjà, en production, si tu peux passer par Ethernet, c’est quand même plus sûr.
Après, on ne fait pas toujours ce qu’on veut avec la topologie locale…

Que des bonnes questions que je me suis posée sans savoir répondre.
J’avais des déco aléatoires sur mon wifi de secours et pas moyen de réactiver

Du coup, j’ai dégagé le plugin Atlas et je me suis développé mon propre client et/ou hotspot wifi.
J’ai les mêmes problèmes (ou à peu près) mais j’ai les commandes pour reconnecter avec un scénario qui détecte les déconnexions.

Aurelien est sur le coup pour refondre le @plugin-Atlas.

Sur son conseil, tu peux essayer de désactiver la gestion de l’énergie (chez moi, cela n’a pas marcher mais qui sait…) :
sudo iwconfig wlan0 power off

Mon hotspot/client wifi :

3

J’ai regardé un peu et suis tombé sur

J’imagine que même avec le retry à 0, cela ne marche pas mieux?

connection.autoconnect:                 yes
connection.autoconnect-priority:        0
connection.autoconnect-retries:         0
4

J’ai un peu fouillé à nouveau et je ne comprends pas car tout semble bon :

iwconfig wlan0
wlan0 IEEE 802.11 ESSID:« HomeBox »
Mode:Managed Frequency:5.24 GHz Access Point: 00:00:00:00:00:00
Bit Rate=180 Mb/s Tx-Power=31 dBm
Retry short limit:7 RTS thr:off Fragment thr:off
Encryption key:off
Power Management:off
Link Quality=40/70 Signal level=-70 dBm
Rx invalid nwid:0 Rx invalid crypt:0 Rx invalid frag:0
Tx excessive retries:181 Invalid misc:0 Missed beacon:0

nmcli connection
NAME UUID TYPE DEVICE
HomeBox 248be1ba-eef6-4a5a-a723-c659zbd4e1c9 wifi wlan0
tun0 aeae09ec-361c-4ac2-af75-8890aa1b0b45 tun tun0
ethernet-eth0 43bdd6ad-59ec-4a39-951a-e7afea11e23e ethernet –
ethernet-eth0-1 1528e91e-bf7b-4565-93d9-cb669ceb1565 ethernet –

nmcli connection show HomeBox | grep autoconnect
connection.autoconnect: yes
connection.autoconnect-priority: 0
connection.autoconnect-retries: 0 (forever)
connection.autoconnect-slaves: -1 (default)

nmcli connection show HomeBox | grep powersave

802-11-wireless.powersave:              0 (default)

Dans « /etc/NetworkManager/conf.d » j’ai le fichier « 20-override-wifi-powersave-disable.conf » avec ce contenu :
[connection]
wifi.powersave = 2

Donc tout semble bien en ordre. J’ai regardé un autre paramètre de NetworkManager → “auth-retries” mais cela semble spécifique au authentification 802.1X donc pas au WPA2/3

Une chose curieuse (pour moi) ce sont les 2 connexions ethernet :

  • ethernet-eth0
  • ethernet-eth0-1

Dans le journal de NetworkManager (journalctl -u NetworkManager) : il n’y a a pas grand chose car il commence au reboot, et comme je reboot la Jeedom Atlas … Néanmois j’ai ceci

ifupdown: interfaces file /etc/network/interfaces.d/* doesn’t exist

Error: failed to open /run/network/ifstate

Je vais voir si je peux mettre un câble réseau mais la box est très mal placée … (mauvais choix) et récupérer le journal avant le reboot

5

Bonjour,

Il faudrait fournir une copie de la page santé Jeedom pour savoir de quoi on parle exactement.

Le système officiel Atlas a grandement changé depuis septembre 2025, dans un premier temps il est donc important de savoir si c’est bien le nouveau qui est utilisé. Comme le plugin Atlas n’a pas encore été revu en conséquence il n’est pas certain que le nouveau système soit une solution en soit, par contre ça permet d’analyser la situation plus précisemment.

6

Bonjour Aurélien,

Voici la copie de la page santé mais je ne suis pas certain que ça apporte grand chose ;

Désolé pour la première capture qui n’'était effectivement pas la bonne

image
image1090×1228 116 KB

Personnellement après avoir creusé : je pencherais sur un problème de 4-way handshake (car au démarrage/redémarrage du Wi-Fi) le point d’accès n’est pas forcément très stable.

7

Ce n’est pas la page santé, je parle bien de celle accessible via Analyse > Santé.

J’ai pourtant bien expliqué quelle information on cherchait à vérifier et pourquoi.

9

Désolé, j’ai corrigé mais je ne vois toujours pas.

J’ai regardé du côté du plugin Atlas car je ne savais pas ce qu’il faisait au juste. J’ai activé les logs (DEBUG) et j’ai été surpris de voir toutes les 5 min le log suivant “Activation du Hotspot.” alors que je n’ai pas du tout l’option Hotspot.

J’ai donc regardé un peu le code il y a des choses qui me suprennent : Il y a bien cron5() qui doit lancer indirectement activeHotSpot() et la première ligne de cette fonction est bien celle qui ajoute la ligne de log “Activation du Hotspot”

public static function activeHotSpot() {
    log::add(__CLASS__, 'debug', __('Activation du Hotspot.', __FILE__));
 ....

La fonction après fait bien une vérification si l’option est HotSpot est activée (mais plus tard).

if ($atlas->getConfiguration(‹ hotspotEnabled ›) == true)

Donc le log trace juste l’entrée dans cette fonction et pas réellement l’activation du HotSpot (peut être à reformuler pour plus de clarté). Si le HotSpot est actif il y a une autre ligne de log plus explicite

log::add(CLASS, ‹ debug ›, __(‹ Hotspot activé. ›, FILE));

Si l’option HotSpot n’est pas activé alors on a ces 5 lignes

else {
      log::add(__CLASS__, 'debug', 'logxxxxx');
      shell_exec('sudo systemctl daemon-reload');
      shell_exec('sudo ifconfig wlan0 up');
      $pid = shell_exec("sudo bash " . $linkForHotspot . " -l");
      $log = shell_exec("sudo bash " . $linkForHotspot . " --stop " . $pid . " > /dev/null 2>&1");
}

Là je comprends bien que ça demande via ifconfig de faire up sur wlan0 ; mais pourquoi ne pas relancer plutôt nmcli (‘sudo nmcli con up SSID’) ?

Et pourquoi faire appel au script “lnxrouter” si on a pas de HotSport activé.

10

Pourquoi me poser des questions sur le code du plugin Atlas dont je ne suis pas à l’origine d’autant plus qu’il a été précisé qu’il est prévu de le réécrire intégralement ?

Tu es sur une ancienne image système qui a été mise à jour manuellement de surcroit. Donc en l’état strictement aucun debug n’est possible.

Un peu de lecture pour commencer : Nouvelles images système officielles – Jeedom – Le Blog

Sachant que de nouvelles images système devraient être disponibles demain ou après-demain au plus tard. A nouveau je ne dis pas que ça va corriger quoi que ce soit juste on ne cherche pas un truc possiblement lié à l’ancien système.

1 « J'aime »
11

Les questionnements sur le plugin étaient pour tous :wink:

Sur la mise à jour du système Debian/Liunux ; J’avoue que cette partie est toujours problématique (car je ne maîtrise pas suffisamment).

A lire la doc je comprends qu’il n’y pas d’update possible; mais qu’il faut passer par une restauration système (automatique) ? La “Restauration automatique” va récupérer (télécharger) la dernière image système puis après installation lancera une restauration à partir de la sauvegarde disponible localement dans l’emplacement backup ? Pour moi l’ambiguïté est sur “restauration” (qui n’indique pas de quoi / de qui / comment).

La dernière image système est téléchargée sur le support de stockage interne.
La restauration du système est effectuée au prochain démarrage.

Enfin ma grosse “angoisse” (et je le dis sérieusement) : c’est l’appairage des devices Zigbee (plugin Z2M). A ce jour j’en ai 67 :wink: Par le passé j’ai eut une très mauvaise expérience (c’était une clef Zigbee externe avec une Jeedom sur un raspberry) et j’ai du refaire l’inclusions de tous les équipements.

Aujourd’hui en utilisant une Jeedom Atlas, est ce que la restauration conserve les associations avec le contrôleur Zigbee intégré ?

Vraiment grand merci d’avance si tu peux m’apporter ces compléments de réponse, ou quelqu’un d’autre :wink:

12

Salut
Pour le plugin-atlas, je me suis à peu près posé les même questions que Piloo.
Avec comme conclusion que plusieurs outils de linux se battaient pour contrôler wlan0.
J’ai aussi deux connexion eth0 (ethernet-eth0 et ethernet-eth0-1). Comme c’est mon accès principal, je n’ai jamais touché.
Je veux juste un hotspot lors du démarrage de Jeedom pour garantir un accès quoi qu’il arrive coté LAN, puis un fail over wifi si mon LAN filaire tombe (switchs).

Pour mon atlas, je n’ai jamais touché au système et suis avec celui livré à l’origine.

image
image1897×533 72.4 KB

Linux JeedomAtlas 5.15.93-rockchip64 #23.02.2 SMP PREEMPT Fri Feb 17 23:48:36 UTC 2023 aarch64 GNU/Linux [11.8]

Coté Zigbee, j’arrive tranquilou à 100 composants. De ce que j’ai compris, tout est sauvegardé dans la sauvegarde jeedom, en particulier le répertoire du plugin /z2m/data dans les trois fichiers :

configuration.yaml
database.db
coordinator_backup.json
1 « J'aime »
13

Bonjour,

Sous Debian la gestion des interfaces réseaux peut se faire par au moins 3 services réseaux différents :
networking (ifupdown), NetworkManager (nmcli), systemd-networkd (networkctl).
Il est recommandé de n’avoir qu’un service réseau actif à la fois,
même s’il est possible moyennant une configuration correcte de gérer par exemple une interface filaire par un service et une interface non filaire par un autre service.
Si plusieurs services sont actifs à la fois, une mauvaise configuration de ces services peut générer des conflits sur une interface réseau et avoir un comportement instable.
Sous Debian 12 je conseillerai d’utiliser uniquement le service NetworkManager (et configurer les interfaces réseaux avec nmcli).

akenad :slight_smile:

14

Merci pour ces retours, notamment sur la sauvegarde de la configuration Zigbee/z2m !

Sinon pour revenir à mon sujet, je me suis finalement résolu à acheter un très long câble Ethernet et j’ai pu me connecter après une déconnection WiFi (le WiFi a redémarré car j’ai changé qqch dans les paramètres) et finalement le problème ne semble pas être sur le handshake WPA comme je pensais mais sur le DHCP tout bêtement … !

Ce qui fait que NetworkManager ne fait pas de retry ! Je ne sais pas si c’est gérable côté config NetworkManager ou plugin Atlas mais je vais regarder ça.

Jun 28 14:34:32 Jeedom NetworkManager[602]: [1782650072.5317] dhcp4 (wlan0): state changed unknown → bound, address=192.168.7.25
Jun 28 21:45:30 Jeedom NetworkManager[602]: [1782675930.6497] device (wlan0): supplicant interface state: completed → disconnected
Jun 28 21:45:30 Jeedom NetworkManager[602]: [1782675930.6500] device (p2p-dev-wlan0): supplicant management interface state: completed → disconnected
Jun 28 21:45:30 Jeedom NetworkManager[602]: [1782675930.7543] device (wlan0): supplicant interface state: disconnected → scanning
Jun 28 21:45:30 Jeedom NetworkManager[602]: [1782675930.7546] device (p2p-dev-wlan0): supplicant management interface state: disconnected → scanning
Jun 28 21:45:41 Jeedom NetworkManager[602]: [1782675941.3927] device (wlan0): supplicant interface state: scanning → associating
Jun 28 21:45:41 Jeedom NetworkManager[602]: [1782675941.3929] device (p2p-dev-wlan0): supplicant management interface state: scanning → associating
Jun 28 21:45:41 Jeedom NetworkManager[602]: [1782675941.9621] device (wlan0): supplicant interface state: associating → completed
Jun 28 21:45:41 Jeedom NetworkManager[602]: [1782675941.9622] device (p2p-dev-wlan0): supplicant management interface state: associating → completed
Jun 28 21:45:41 Jeedom NetworkManager[602]: [1782675941.9623] device (wlan0): DHCPv4 lease renewal requested
Jun 28 21:45:41 Jeedom NetworkManager[602]: [1782675941.9794] dhcp4 (wlan0): canceled DHCP transaction
Jun 28 21:45:41 Jeedom NetworkManager[602]: [1782675941.9795] dhcp4 (wlan0): state changed bound → terminated
Jun 28 21:45:41 Jeedom NetworkManager[602]: [1782675941.9812] dhcp4 (wlan0): activation: beginning transaction (timeout in 45 seconds)
Jun 28 21:46:27 Jeedom NetworkManager[602]: [1782675987.3012] dhcp4 (wlan0): request timed out
Jun 28 21:46:27 Jeedom NetworkManager[602]: [1782675987.3015] dhcp4 (wlan0): state changed unknown → timeout
Jun 28 21:46:27 Jeedom NetworkManager[602]: [1782675987.3018] device (wlan0): DHCPv4: trying to acquire a new lease within 90 seconds
Jun 28 21:47:57 Jeedom NetworkManager[602]: [1782676077.3014] device (wlan0): DHCPv4: grace period expired
Jun 28 21:48:08 Jeedom NetworkManager[602]: [1782676088.6514] device (tun0): state change: activated → unmanaged (reason ‹ unmanaged ›, sys-iface-state: ‹ removed ›)
Jun 28 22:33:07 Jeedom NetworkManager[602]: [1782678787.1466] device (eth0): carrier: link connected

15

De ce que j’ai compris les solutions pour ce type de problème sont de jouer sur les 2 paramètres suivant dans le profil de connexion NetworkManager

ipv4.may-fail no
Avec ipv4.may-fail no, si IPv4 échoue, la connexion est désactivée plutôt que simplement marquée en échec logique

ipv4.dhcp-timeout infinity
NetworkManager ne s’arrêtera pas de demander/renouveler une adresse IP tant qu’il n’y arrive pas.

Ca me semble cohérent, des contradicteurs ?

16

Bonjour
Sur mon Atlas, j’ai

ipv4.may-fail         : yes
ipv4.dhcp-timeout : 0 (default)

que je n’ai jamais touché volontairement.

17

Suite à la suppression du plugin Atlas et mes bidouilles avec mon wifi, j’ai ces deux sevices réseaux qui tournent.

networkd-dispatcher.service loaded active running Dispatcher daemon for systemd-networkd
NetworkManager.service      loaded active running Network Manager

Cool, c’est le premier que j’ai regardé et celui que je comprends le moins mal. :slightly_smiling_face:

Je passe en debian 12 dès que Jeedom donne le feux vert.

18

tu as mon feu vert à partir du premier septembre.

akenad :slight_smile:

19

Je vais testé sur ma machine de test (VM Synology).

20

Actuellement systemd-networkd est le service réseau installé par défaut avec l’image Jeedom Atlas.
Actuellement le plugin Atlas installe le paquet network-manager comme dépendance (apt install network-manager, incluant le service NetworkManager et la commande nmcli)
si le plugin Atlas est supprimé NetworkManager et nmcli ne sont pas supprimé.

akenad :slight_smile:

21

Vous n’aurez aucun feut vert supplémentaire

Il a déjà été répété à plusieurs reprises que:

  • deb12 est supporté
  • les images sont officiellement mises à disposition

que voulez-vous de plus? jeedom ne vous dira jamais: « installez debian 12, on a vérifié, tout ira bien pour vous »… tout dépend de vos plugins

2 « J'aime »