Archive 07/10/2020.

Perte de node

Laurent263

Bonjour, pour signaler une perte de contact avec un node pendant l’experience du TP 17 sur le site grenoble, la même experience a ensuite fonctionné sur le site de lyon, je mets les infos ci-dessous.

Et une question: est ce qu’il existe un mécanisme dans RIOT qui permet de differencier une panne materielle fin de batterie ou erreur système d’un problème de connection ?

fun65733b622a@grenoble:~$ nc m3-97 20000
help
help
Command Description

dtlsc Start a DTLS client
dtlss Start and stop a DTLS server
reboot Reboot the node
random_init initializes the PRNG
random_get returns 32 bit of pseudo randomness
nib Configure neighbor information base
ifconfig Configure network interfaces
6ctx 6LoWPAN context configuration tool

ifconfig
ifconfig
Iface 0 0x80042f3
*** RIOT kernel panic:
FAILED ASSERTION.

Le Node était ensuite injoignable.

aabadie2

Bonjour,

Vous obtenez une erreur liée à un appel à la fonction assert avec une condition fausse, d’où le FAILED_ASSERTION.

Pour savoir d’où vient le problème dans le code, vous pouvez recompiler le firmware en ajoutant CFLAGS=-DDEBUG_ASSERT_VERBOSE au début de la commande de compilation.
Si le firmware plante à nouveau, le message FAILED_ASSERTION indiquera où s’est produit l’erreur (fichier + ligne).

est ce qu’il existe un mécanisme dans RIOT qui permet de differencier une panne materielle fin de batterie ou erreur système d’un problème de connection ?

Pour la panne de fin de batterie, il n’existe rien dans RIOT pour gérer ça nativement. C’est au développeur de prévoir ce mecanisme avec par exemple un système de vérification récurrent (à chaque réveil) et éventuellement une remontée d’alerte quand le niveau devient critique.
Pour le problème de connexion, c’est l’appel aux APIs réseau qui doit renvoyer un code d’erreur (à vérifier dans la doc) et encore une fois, c’est au développeur de gérer les cas d’erreur de connexions.

Laurent263

merci