Nous en avons encore quelques-uns sur le terrain. La différence tient à qui pilote le DHCP.Avec wpa-conf, ifupdown démarre wpa_supplicant avec votre configuration, puis exécute dhclient sur wlan0 lui-même. wpa_supplicant choisit un réseau parmi les blocs du fichier, ifupdown ne se soucie pas de lequel. C’est simple, et suffisant pour « se connecter à celui des deux qui est à portée ».Avec wpa-roam, wpa_supplicant fonctionne en mode itinérance et appelle wpa_action à chaque connexion et déconnexion, lequel active alors une interface logique. Chaque bloc réseau peut porter un id_str qui désigne l’interface logique à utiliser ; ceux qui n’en ont pas utilisent iface default. Cela sert à avoir des paramètres IP différents selon le réseau. Le piège : wpa_action doit voir la déconnexion pour libérer l’ancien bail. Lorsque le nœud est emporté et que le point d’accès disparaît dans un ordre inattendu, vous restez associé sans bail. C’est votre symptôme sur le terrain.Pour deux réseaux DHCP, utilisez wpa-conf et des priorités :

# /etc/network/interfaces
allow-hotplug wlan0
iface wlan0 inet dhcp
    wpa-conf /etc/wpa_supplicant/wpa_supplicant.conf

# /etc/wpa_supplicant/wpa_supplicant.conf
network={
    ssid="LAB-WIFI"
    psk="..."
    priority=10
}
network={
    ssid="FIELD-AP"
    psk="..."
    priority=5
}

Côté Hermetry, chaque changement de réseau interrompt la session MQTT ; faites donc en sorte que votre client se reconnecte avec un délai progressif (backoff) et se réabonne. Si le nœud dispose d’une alarme hors ligne, réglez son délai d’ouverture (open-after) au-delà du temps de trajet entre le laboratoire et la parcelle, sinon vous en recevrez une à chaque déplacement.

Deux questions différentes, donc deux réponses.Pourquoi SPECK et SIMON sont petits : ce sont tous deux des conceptions ARX (addition, rotation, XOR) sans S-boxes. AES nécessite des tables de correspondance ou une substitution d’octets assez complexe, ce qui coûte de la mémoire flash et de la RAM sur un composant 8 bits et laisse fuiter des informations de temps s’il est implémenté avec des tables. Le tour de SPECK se résume à quelques additions, rotations et XOR sur 16/32/64 bits, si bien qu’une implémentation complète tient en quelques centaines d’octets. Il en existe deux parce qu’ils ont été optimisés pour des cibles différentes : SIMON pour le matériel (très peu de portes), SPECK pour le logiciel sur microcontrôleurs. Ils existent aussi en de nombreuses tailles de bloc et de clé (de 32/64 à 128/256), ce qui est pratique pour de très petits paquets. Pour votre thèse, la controverse autour de la standardisation ISO et l’absence de justification de conception méritent aussi un chapitre.Pourquoi vous ne pouvez pas remplacer TLS par SPECK : un chiffrement par blocs n’est qu’une brique. TLS assure l’échange de clés, l’authentification du serveur et l’intégrité des messages, et la plateforme vérifie votre identifiant à l’intérieur de cette session. Si vous chiffrez une charge utile avec SPECK et l’envoyez, quelqu’un doit tout de même convenir d’une clé avec vous, et le broker ne verrait qu’un bloc opaque. Sur Hermetry, côté appareil, le minimum est TLS 1.2 (1.3 recommandé) avec des suites à confidentialité persistante : AES-GCM ou ChaCha20-Poly1305, sans échange de clés RSA ni CBC. Le MQTT non chiffré sur le port 1883 ne fonctionne que si un administrateur active MQTT en clair pour le profil ; la documentation traite cela comme une exception pour les appareils qui ne peuvent pas utiliser TLS sur un réseau privé ou un VPN. C’est pourquoi votre test sur 1883 a été refusé. Tout est détaillé sur la page de sécurité du transport des appareils.Côté pratique : l’ESP32 dispose d’un matériel AES, TLS coûte un peu de RAM et environ une seconde de négociation par connexion, puis cela ne se remarque pas aux débits des capteurs. L’ATmega est le vrai problème. Soit vous utilisez ChaCha20-Poly1305 (il est aussi ARX et rapide sans matériel dédié), soit vous laissez l’ATmega communiquer avec une passerelle qui conserve la session TLS.