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 
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 
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 
en fait, j’avais
"maxPublic": null,
je l’ai passé à 10 et c’est beaucoup mieux 
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
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
1 Like
d’accord, je le note 
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…
Je suis larguée
Je viens de remettre en service un noeud G1-test avec cette version. Je calcule bien des blocs mais je n’apparait pas dans les membres, seulement en hors ligne et seulement après le calcul d’un bloc.
Que dois-je faire pour régler le problème?
Très bien ! Ça fera un excellent exercice de coding que de corriger ces points
2 Likes
J’ai ça chez moi, est-ce que c’est bien configuré ?
schmitta@odroid:~$ duniter ws2p show-conf
{
“uuid”: “0ee9099e”,
“privateAccess”: true,
“publicAccess”: true,
“upnp”: false,
“host”: “192.168.0.152”,
“port”: 10090,
“remoteport”: 10090,
“remotehost”: “78.242.14.140”
}
Et est-ce que tu as un moyen en ligne de commande pour voir si j’ai des incoming ?
Non je n’ai pas développé cela. Tu peux t’en tenir au test du Simple WebSocket Client. Je le fais pour toi :
Ton nœud est parfaitement paramétré. Après, tu peux quand même greper dans tes logs les « incoming connection » pour si tu as des nœuds qui se connectent. Mais je n’ai pas de logs sur les déconnexions INCOMING.