Bêta-test Duniter 1.6 WS2P

Nouvelle version 1.6.5

Correctifs

  • Liés à WS2P :

    • correction d’un bug majeur qui empêchait de télécharger les blocs manquants lors de la résolution de fork
    • le message « WS2P >> Streamer >> WS2P connection timeout » s’affichait de très nombreuses fois dans les logs
    • Duniter ne fonctionnait pratiquement plus sur les Raspberry PI et autres cartes ARM
      • le CPU était toujours à 100% d’utilisation
      • la preuve de travail calculée traitait presque toujours le même bloc
      • le message « The proof-of-work generation was canceled: Document already under treatment » s’affichait de très nombreuses fois dans les logs
  • Indépendants :

    • il était devenu impossible d’ajouter manuellement la WebUI avec yarn add duniter-ui

cc @elois, @Alan_Schmitt, @stephane, @SimonLefort

Lien de téléchargement : https://github.com/duniter/duniter/releases/tag/v1.6.5

4 Likes

Mise a jour effectuée sur g1-test.elois.org :slight_smile:

1 Like

Je teste ça dès demain matin! :slight_smile:

Merci! Et n’oublie pas de dormir aussi.

Merci pour tous ces efforts !

Je teste (sur ğ1-test), et visiblement j’ai une erreur de clé à un moment :

2017-09-26T08:41:29+02:00 - info: WS2P 79gA7jpXpRPfZ7nDZjRspBrYsyu8rrJTDn3GBri8Haux: new incoming connection from 192.168.0.254:35507!
2017-09-26T08:41:29+02:00 - trace: WS2P >>> sendCONNECT >>> WS2P:CONNECT:g1-test:79gA7jpXpRPfZ7nDZjRspBrYsyu8rrJTDn3GBri8Haux:9795bae6-90a4-43b9-aa1b-efd593ca5703409803d5-ddfb-4365-800b-1e52c2d390cc
2017-09-26T08:41:29+02:00 - trace: WS2P >>> sendCONNECT >>> WS2P:CONNECT:g1-test:79gA7jpXpRPfZ7nDZjRspBrYsyu8rrJTDn3GBri8Haux:9ccf4186-76e5-4be5-973f-5967cb5a963bb6ee25b0-1d8f-4783-b91c-b2e1da034ace
2017-09-26T08:41:29+02:00 - error: WS2P >>> >>> WS ERROR: INCORRECT_PUBKEY_FOR_REMOTE
2017-09-26T08:41:29+02:00 - trace: WS2P >>> registerCONNECT >>> WS2P:CONNECT:g1-test:79gA7jpXpRPfZ7nDZjRspBrYsyu8rrJTDn3GBri8Haux:9ccf4186-76e5-4be5-973f-5967cb5a963bb6ee25b0-1d8f-4783-b91c-b2e1da034ace
2017-09-26T08:41:29+02:00 - trace: WS2P >>> sendACK >>> WS2P:ACK:g1-test:79gA7jpXpRPfZ7nDZjRspBrYsyu8rrJTDn3GBri8Haux:9ccf4186-76e5-4be5-973f-5967cb5a963bb6ee25b0-1d8f-4783-b91c-b2e1da034ace
2017-09-26T08:41:29+02:00 - error: WS2P >>> >>> WS ERROR: INCORRECT_PUBKEY_FOR_REMOTE
2017-09-26T08:41:39+02:00 - info: WS2P: Could not connect to peer -------- using WS2P 78.242.14.140 10090: WS2P connection timeout
2017-09-26T08:41:39+02:00 - debug: WS2P: init: failed connection
2017-09-26T08:41:39+02:00 - warn: WS2P: cannot connect to incoming WebSocket connection: WS2P connection timeout

J’ai l’impression que c’est la connexion à moi-même qui échoue. (L’IP à la fin est mon IP publique.)

Oui le cas est troublant, à surveiller.

Nouvelle version 1.6.6

Correctifs

  • Liés à WS2P :

    • le démarrage réseau de la partie WS2P était bloquant pour les autres services
    • WS2P Public est désormais activé par défaut pour les nœuds disposant d’UPnP
    • sécurité : contrôler la bonne forme des push de données HEADs (état du réseau)

Lien de téléchargement : https://github.com/duniter/duniter/releases/tag/v1.6.6

Il s’agit d’une Release Candidate !

2 Likes

Soit dit en passant, le réseau Ğ1 est déjà bien fourni en nœuds WS2P : au moins 9 nœuds connectés actuellement !

1 Like

Arf je ne vois plus le miens :’(

hum … j’ai du loupé quelque-chose, je n’ai que deux connexions ws2p sur mon nœud mais je vois bien tous les autres :confused:

C’est peux-être le même problème:
https://forum.duniter.org/t/livrables-arm-en-attente-raspberry-pi-3-hs/3249/63

je suis pas sur arm mais j’avais un soucis sur ma conf apparemment

avant

{
“uuid”: “afaa79d8”,
“privateAccess”: true,
“publicAccess”: true,
“upnp”: false,
“host”: “duniter.help-web-low.fr”,
“port”: 7777,
“remoteport”: 7777,
“maxPublic”: null
}

après

{
“uuid”: “afaa79d8”,
“privateAccess”: true,
“publicAccess”: true,
“upnp”: false,
“host”: “151.80.40.148”,
“port”: 7777,
“remoteport”: 7777,
“maxPublic”: null,
“remotehost”: “duniter.help-web-low.fr
}

@vincentux, @stephane, @Pafzedog

Il se passait que mon nœud était l’un des seuls à fournir la connexion WS2P publique, or mon YunoHost a fait des siennes et fermé les ports utilisés pour Duniter, notamment WS2P.

Donc ça fait un gros point central d’échec, et ça a fichu un peu le boxon. Néanmoins, c’est revenu :slight_smile:

Oui mais voilà … l’idée c’est plutôt de faire comme @Pafzedog, et de mettre à disposition son nœud pour du WS2P public. Plus on est nombreux à le faire, plus résilient sera le réseau car décentralisé.

Pour cela : « WebUI > Settings > Network > Enable WS2P access ». Puis sauvegarder et appliquer.

Vous pouvez vérifier que ça fonctionne bien en ayant des entrées « INCOMING » dans votre vue réseau. Vous pouvez également tester votre adresse avec un outil comme Simple WebSocket Client (extension Chrome/Firefox), par exemple avec la mienne :

S’il y a une ligne « CONNECT », c’est que votre configuration fonctionne.

4 Likes

Alors j’ai bien la ligne “CONNECT” avec Simple WebSocket Client mais je n’ai que des OUTCOMING dans la vue WS2P CONNECTIONS :frowning:

en fait, j’avais
"maxPublic": null,

je l’ai passé à 10 et c’est beaucoup mieux :slight_smile:

comment peut-on mettre ce paramètre à ‘non configuré’ ou illimité du coup ?

1 Like

Bitcoin possède 5000 nœuds actifs, si ça peut te donner une idée de valeur haute :slight_smile:

edit : j’ai ajouté le ticket #1124 pour cette histoire de valeur nulle.

Bon vu que la release est candidate j’ai fait le pas, un WS2P public de plus sur le réseau Ğ1, alors ce qui est drôle c’est que sans BMA j’avais zéro connexion WS2P donc j’étais isolé, j’ai activé BMA et boum je me suis pris 10 connexions INCOMING en moins d’une seconde !!

1 Like

Ouai c’est sûrement parce que le document est refusé par la plupart des nœuds <= 1.5, et donc les nœuds WS2P potentiels ne sont pas alertés de ton endpoint disponible.

Mais si tu ajoutes BMA … le document passe comme un colis chez UPS :slight_smile:

1 Like

d’accord, je le note :wink:

Mais je me suis mal exprimé:

En fait je n’ai pas configuré cette valeur au départ en faisant mes commandes duniter config puis j’ai vu au détour d’une capture d’écran que l’on pouvait configurer cela par la WebUI alors j’ai passé rapidement ce réglage à 10 pour finalement l’enlever de la configuration toujours par la WebUI ce qui a eu pour effet de mettre la valeur à “null” et d’empecher toute connexion en INCOMING

Du coup, je pense que le cas pourrait se reproduire chez quelqu’un d’autre sans qu’il ou elle comprenne pourquoi il n’y a pas de connexion entrante.

1 Like

J’ai pas réussit à utiliser cette extension.

J’ai tenté des outils en CLI écrits en Go et Rust, mais sans succès.

Par contre, cet outil en JS wscat fonctionne bien.

Histoire de tester les limites j’ai régler a 8 le nombre max de connexions ws2p publiques alors que j’en avait 10 :

  • Premier constat il faut redémarrer le nœud pour que la limite s’applique (ce serait bien que la web-ui indique qu’il faut le faire, comme a l’install d’un module)
  • Deuxième point, toutes les connexions WS2P m’étais réfusés au redemarrage, il a fallu 10 bonnes minutes avant de réussir ma 1ère connexion WS2P, c’est un comportement normal ?
  • Troisième observation, j’ai bien 8 connexions donc conforme au max mais j’ai deux fois pafzedog, c’est normal ?
  • Quatrième observation, j’avais configuré des clés préférés et privilégiés, et elles ont disparus de ma conf quand j’ai relancé le nœud…