2024-09-20 10:02:15 💔 Verification failed for block 0xb5c360683f586a36df4f45444ddef9ca579ea34dc2ab27ddbd0d4b462748d0f5 received from (12D3KooWBUofnBCndckssxLfMgygqioJTGWdfjkmjb8bDtjezWFE): "Header 0xb5c360683f586a36df4f45444ddef9ca579ea34dc2ab27ddbd0d4b462748d0f5 rejected: too far in the future"
Donc il a dû se passer quelque chose dans ces eaux là. 12/09/2024 20:03:18 pour ton dernier bloc 3048656 12/09/2024 20:03:12 pour le précédent par cgeek 3048655
Intéressant, sur ta capture on voit que tu as calculé les blocs 3145130 et 3145134. Mais ce sont tous les deux des blocs que j’ai calculé sur la chaîne principale (regarde sur un autre nœud miroir listé sur https://duniter-portal.axiom-team.fr/). Tu calcules des blocs sur ton fork, mais la chaîne principale ne les accepte pas. Par contre les autres blocs correspondent bien, et même leur hash. Donc le chaînage doit être cassé, et ce qui est affiché sur ton polkadotjs doit juste être les blocs reçus par ton nœud dont certains écrasés par les blocs calculés par ton nœud.
Et donc on doit avoir un bug des offenses à creuser, parce que je me serais attendu à ce que tu sois blacklisté des forgerons. Peut-être aussi qu’on aurait dû accompagner le “note stalled” de Finalisation bloquée #2 d’un nouveau set de forgerons.
Après réflexion, le problème de mon nœud semble être un “problème d’heure”, comme découvert dans ce poste de finalisation bloquée :
Mon nœud reçoit des blocs qui ne sont pas dans la fourchette de temps de GrandPa+Babe:
2024-09-24 12:50:43 Report 12D3KooWBfuEahrFypghc8niTseEq6ZVYkyXTUjTTcX6kkbFVgYB: -536870912 to -2147483648. Reason: Block verification failed. Banned, disconnecting.
2024-09-24 12:50:44 💔 Verification failed for block 0x1f5dcc6c034b97436b18ceed32b0b317b85e02d65bca3d8b364ca64387ea9a6b received from (12D3KooWBUofnBCndckssxLfMgygqioJTGWdfjkmjb8bDtjezWFE): "Header 0x1f5dcc6c034b97436b18ceed32b0b317b85e02d65bca3d8b364ca64387ea9a6b rejected: too far in the future"
du coup, mon nœud banni les autres nœuds et se retrouve de fait connecté à peu de pairs, j’ai pu observer de 0 à 2 pairs connectés contre entre 10 et 20 pour les autres nœuds.
Mon nœud fini par accepter les blocs plus tard, car ils entrent finalement dans la fourchette de blocs acceptables. C’est ma compréhension actuelle, une théorie.
Il faut que je regarde depuis quand j’ai ces erreurs en quantité dans mes logs. Je ne trouve pas où sont stockés les logs.
Il faut aussi que je résolve le problème avec le temps dans le conteneur.
Ce serait intéressant d’essayer de forcer le peering entre ton nœud et un autre du réseau en utilisant system.addReservedPeer(peer) (méthode de l’API RPC unsafe). Tu peux essayer avec un ou plusieurs de mes nœuds :
Je pourrais faire la même chose dans l’autre sens, mais je ne trouve pas comment remonter de ton peerId 12D3KooWGr8Qm3Rp3hMBPguJmnQgCy2rFCpr4DQ5iyT8yra1jNcx à ton IP. Ça devrait être possible en lisant la dht des pairs, mais la méthode system.peers() n’affiche que les peer id et pas les adresses.
Est-ce que tu peux me donner ton adresse p2p ? Si tu n’as pas mis de dns, c’est simplement /ip4/<ip>/tcp/<port>/p2p/<peerid>. J’imagine que le port est 30333 et que tu l’as bien ouvert, et j’ai le peerid, mais je ne vois pas comment trouver l’adresse simplement (alors qu’elle devrait tout simplement être dans les fiches de pair de mon nœud).
Donc ce n’était pas le cas avant ? Ça veut dire que les tentatives de connexions vers ton nœud ne pouvaient pas passer et que seules les connexions sortantes pouvaient fonctionner ?
--out-peers <COUNT>
Number of outgoing connections we're trying to maintain
[default: 8]
--in-peers <COUNT>
Maximum number of inbound full nodes peers
[default: 32]
Avec ces réglages par défaut, ton nœud essayait de maintenir 8 connexions, mais n’en recevait aucune.
[edit] désolé pour l’edit de ton message, je pensais être en train d’éditer le mien
J’utilise ipfs pour tester les connexions, c’est l’outil le plus simple que j’avais à portée de main, ça donne :
J’ai redirigé le port sur ma box. Je tente d’ouvrir le port sur le pare-feu de ma machine, mais firewalld n’est pas simple à prendre en main J’ai installé kubo pour avoir la commande ipfs et pouvoir tester comme toi, mais la connexion ne s’établit même pas avec l’adresse IP locale. Faut que je continue de creuser.
Maintenant, plus d’erreurs dans les logs, mon nœud est connecté à six pairs. La durée de propagation des blocs est d’une durée acceptable !
Faut être (synchronisé) à l’heure avec l’utilisation de Babe+GrandPa, sinon ça ne fonctionne pas !
Du coup, pas vraiment besoin d’avoir le port 30333 ouvert ? Comme avec Duniter v1 et ws2p.
Après avoir fermé les ports, j’arrive à m’y connecter via les adresses IP locale, IPv4, IPv6 et nom de domaine !
Dans la doc duniter ? Il faudrait que je l’ajoute parce que j’imagine qu’il vaut mieux ne pas avoir trop d’asymétrie au niveau des connexions p2p.
J’aimerais comprendre plus précisément quelles sont les conditions pour que ça fonctionne bien et d’où viennent les problèmes de peering, ça sera utile pour décider des conditions à remplir pour devenir forgeron.
Dans duniter v1 on recommandait de faire un reverse proxy sur le 443 avec des chemins comme /bma et /ws2p.
À noter qu’on peut également le faire sur duniter v2 qui gère aussi le websocket sur le 30333. Mais dans ce cas, il faut que DUNITER_PUBLIC_ADDR soit quelque chose comme /dns/example.org/tcp/443/ws/p2p. C’est du p2p sur websocket. Mais autant établir directement la connexion en tcp, il n’y a que les contextes avec de fortes restrictions où on a envie de passer par du websocket (proxy, navigateur…).
Ne pas fournir de endpoint p2p c’est ne pas participer à la décentralisation du réseau. Si un seul nœud expose un endpoint p2p, les autres nœuds ne pourront pas établir de connexions entre eux.
Peux tu préciser ? Si tu essayes depuis le même réseau local ça ne me choque pas, mais je ne vois pas comment tu peux ouvrir une connexion depuis l’extérieur sans écouter les connexions extérieures.
Il faut un nœud à l’heure, synchronisé à NTP ou équivalent. La machine hôte doit l’être, car le conteneur a la même heure que la machine hôte.
WS2P fonctionne très bien dans mon cas sans proxy, ni ouverture manuelle de port, surement avec UPnP qui s’occupe de l’ouverture de port ou via un autre mécanisme.
Je ne vois pas trop quoi préciser.
Ces trois adresses ne fonctionnent pas pour toi ? J’ai testé en local, faudrait que je teste depuis l’extérieur.
En tout cas dans Firefox, là où les autres nœuds donnent “connexion réinitialisée”, j’ai un timeout.
Le scan SYN est bloqué :
$ sudo nmap -Pn -sS 188.23.44.109 -p 30333
Starting Nmap 7.93 ( https://nmap.org ) at 2024-10-09 16:36 CEST
Nmap scan report for 188-23-44-109.adsl.highway.telekom.at (188.23.44.109)
Host is up.
PORT STATE SERVICE
30333/tcp filtered unknown
Nmap done: 1 IP address (1 host up) scanned in 2.14 seconds
J’ai 
