Peering signal -> wrong endpoint

Bonjour bonjour,
Je récolte des “Wrong endpoint” à tire-larigot depuis un moment (à chaque vérification nodulaire), suivi de superbes “error” et je n’arrive pas à comprendre ce qu’il se passe (n’ayant rien touché entre temps). Ça a fait suite à un enchaînement de “Too high difficulty” qui ne m’ont pas semblé particulièrement anormaux (c’était après calcul d’un bloc), mais depuis il n’y a pas eu de nouvelle connexion aux nœuds, et donc plus de participation aux calculs.
Quelqu’un a-t-il une idée qui pourrait m’aiguiller ?
Merci !

(Je me permets de remonter ma question, pour éviter qu’elle ne disparaisse dans les limbes d’internet.^^)

C’est peut-être ton nœud qui a une configuration bizarre, mais ça peut venir aussi d’un autre qui balance sa propre fiche de pair erronée.

Pour le moment c’est un peu difficile de creuser davantage ce types d’erreurs et leur origine, il y aurait des développements à faire pour améliorer cela (consigner l’erreur plus en détails quelque part, par exemple, ou autre solution de votre cru).

J’essaie d’y voir plus clair mais certaines choses me dépassent dans les logs.
Je remarque que les problèmes ont commencé à l’apparition d’un nouveau fichier de logs.
Visiblement ma clé publique ou ma signature numérique a commencé à être rejetée :

> WS2P >>> >>> WS ERROR: REJECTED_PUBKEY_OR_INCORRECT_ASK_SIGNATURE_FROM_REMOTE

Les logs ne correspondent d’ailleurs pas à ceux qui apparaissaient dans les logs en temps réel de l’interface.
Et j’ai également eu ce message d’erreur :

>WS2P OUT => Document detected 2 times: "version":10,"currency":"g1","status":"UP"...

(Je veux bien consigner ce bug sur github mais le fait est que je ne sais même pas dans quel sens prendre le problème !)

Après réinitialisation complète du nœud et quelques bidouilles sur l’interface celui-ci semble fonctionner normalement.
À noter que dans la version précédente, un bloc de plus avait été considéré comme calculé (16 au lieu de 15 après réinitialisation).

Merci cgeek.

Ce message intervient quand ta propre clé est rejetée à la connexion, et inversement si tu acceptes des connexions entrantes (WS2P Public activé).

Le rejet intervient si l’authentification ne passe pas (exemple : un nœud g1-test qui essaierait de se connecter au réseau g1), ou si la clé est rejetée. Ce dernier cas arrive facilement si un nœud avec WS2P Public activé a déjà trop de connexions entrantes. Dans ce cas il refuse la connexion car ta clé n’est pas prioritaire pour lui. Il se peut aussi qu’il considère que tu es déjà connecté (par exemple en cas de coupure brutale du nœud, la connexion websocket ne s’éteint pas normalement), alors attendre quelques minutes permet d’être effacé de la liste des connectés.

Oui et cela, c’est un bug car ton nœud ne devrait jamais se répéter, sinon les autres nœuds considèrent que c’est du spam et peuvent bannir ta connexion pour quelques minutes ou plus. J’ai mis ce message pour alerter que le bug est présent, sans bien savoir où il se situe. Puis de filtrer la répétition pour éviter le bannissement.

Bon bref, il y a plein de sujets d’améliorations :slight_smile:

Tu peux quand même consigner des tickets, même un peu “brouillons” car ça permet de tracer et donc d’éviter de laisser un éventuel bug perdurer ! @Moul m’en fait plein des comme ça, et c’est tant mieux.

1 Like

Voilà c’est fait, tu l’auras cherché.:grin:

1 Like