Mon nœud avait l’air coincé (en 1.6.11) alors je l’ai mis à jour, et il est toujours coincé (selon Cesium).
Plus précisément il calcule bien le bon bloc (69352 à l’heure où j’écris), il apprend bien quand il y a de nouveaux blocs, mais il est noté en retard sur https://g1.duniter.fr/#/app/network (au block 69218). C’est d’autant plus surprenant que je vois que le dernier bloc que j’ai calculé est le 69336.
C’est grave, docteur ?
@jytou quand tu sera dispo tu pourra livrer la 1.6.14 le commit de version est déjà fait, tu a juste a faire :
git checkout 1.6
./release/new_prerelease.sh 1.6.14
le changelog :
wizard network est utiliséeLe fait que nous appliquions autant de correctif avant d’officialiser cette version 1.6 est bon signe, cela veut dire que nous devenons plus exigeants suite a la montée en charge du réseau (plus de nœuds) et a la montée de l’intertie (plus de temps avant que tout le monde applique une maj officielle)
@Alan_Schmitt les problèmes que tu soulève ici concernent Cesium pas Duniter !
Je vois bien ton head sur mes nœuds et tu est bien affiché comme en 1.6.13 et synchroniser sur le dernier bloc 
EDIT : Il faut comprendre que les clients Cesium et Sakia ne voient le réseau qu’a travers les nœuds ayant activer BMA, les informations sur les nœuds sans BMA leurs arrivent donc en retard voir pas du tout !
Pour Sakia, c’est “pas du tout” ^^
C’est parti. Je vais d’ailleurs essayer en mettant un peu plus de CPU pour les VM, histoire de voir si ça accélère un peu le schmilblick. (sauf si @cgeek vient hurler ici qu’il ne faut surtout pas faire ça… je suis d’humeur joueuse aujourd’hui)
Pour une future version de sakia tu peut te baser sur les heads fournis par les nœuds membre qui ont BMA, par exemple pour mon noeud membre g1-monit : http://g1-monit.elois.org:10901/network/ws2p/heads
EDIT : En plus tu a la signature de chaque clé a qui appartiens le head donc tu peut même te baser sur les nœuds miroir tu est sur qu’il ne peuvent pas mentir sur le contenu du head sinon la signature serait invalide 
Oui mais ils peuvent mentir par omission (nœuds membres comme non-membres d’ailleurs), et montrer de vieux HEADs faisant croire à une désynchronisation. Ils ne peuvent certes pas faire croire à un fork par contre.
Voila qui est fait pour linux/windows, la release arm est dans le four…
Il suffit de demander tout leur heads a X nœuds (une dizaine par exemple) et en garder pour chaque UUID que le head le plus haut, qui est en principe le plus récent sauf rooling back 
Ça me fait penser pour ws2p v2 il serait bon de rajouter un timestamp local au head pour être sur de savoir quel est head le plus récent d’un noeud donné.
Ça coince pour moi… ne se connecte à aucuns nœuds.
2017-11-14T22:51:06+01:00 - error: Unhandled rejection: Error: Request failed: 500
2017-11-14T22:51:06+01:00 - error: Error: Request failed: 500
at Error (native)
at /opt/duniter/node_modules/nnupnp/lib/nat-upnp/device.js:151:27
at Parser.<anonymous> (/opt/duniter/node_modules/xml2js/lib/xml2js.js:199:18)
at emitOne (events.js:96:13)
at Parser.emit (events.js:188:7)
at Object.saxParser.onclosetag (/opt/duniter/node_modules/xml2js/lib/xml2js.js:183:24)
at emit (/opt/duniter/node_modules/sax/lib/sax.js:624:35)
at emitNode (/opt/duniter/node_modules/sax/lib/sax.js:629:5)
at closeTag (/opt/duniter/node_modules/sax/lib/sax.js:889:7)
at Object.write (/opt/duniter/node_modules/sax/lib/sax.js:1436:13)
at Parser.exports.Parser.Parser.parseString (/opt/duniter/node_modules/xml2js/lib/xml2js.js:211:31)
at Parser.parseString (/opt/duniter/node_modules/xml2js/lib/xml2js.js:6:61)
at Request._callback (/opt/duniter/node_modules/nnupnp/lib/nat-upnp/device.js:149:14)
at Request.self.callback (/opt/duniter/node_modules/nnupnp/node_modules/request/main.js:120:22)
at emitTwo (events.js:106:13)
at Request.emit (events.js:191:7)
at Request.<anonymous> (/opt/duniter/node_modules/nnupnp/node_modules/request/main.js:633:16)
at emitOne (events.js:96:13)
at Request.emit (events.js:188:7)
at IncomingMessage.<anonymous> (/opt/duniter/node_modules/nnupnp/node_modules/request/main.js:595:14)
at emitNone (events.js:91:20)
at IncomingMessage.emit (events.js:185:7)
@nay4 merci pour ce retour. Peut tu me partager ta config que j’essaye de voir ce qui peut coincer ? (fichier conf.json dans ~/.config/duniter/NOM_DE_TON_PROFIL_DE_DONNEES)
Tu utilise l’UpnP ?
cat ./.config/duniter/duniter_default/conf.json
{
"currency": "g1",
"endpoints": [],
"rmEndpoints": [],
"upInterval": 3600000,
"c": 0.0488,
"dt": 86400,
"dtReeval": 15778800,
"ud0": 1000,
"stepMax": 5,
"sigPeriod": 432000,
"sigValidity": 63115200,
"msValidity": 31557600,
"sigQty": 5,
"xpercent": 0.8,
"percentRot": 0.67,
"powDelay": 0,
"avgGenTime": 300,
"dtDiffEval": 12,
"medianTimeBlocks": 24,
"httplogs": false,
"udid2": false,
"timeout": 3000,
"isolate": false,
"forksize": 100,
"switchOnHeadAdvance": 3,
"sync": {},
"msPeriod": 5259600,
"loglevel": "info",
"cpu": 0.6,
"prefix": 2,
"nobma": true,
"upnp": true,
"dos": {
"whitelist": [
"127.0.0.1"
],
"maxcount": 50,
"burst": 20,
"limit": 40,
"maxexpiry": 10,
"checkinterval": 1,
"trustProxy": true,
"includeUserAgent": true,
"errormessage": "Error",
"testmode": false,
"silent": false,
"silentStart": false,
"responseStatus": 429
},
"ws2p": {
"uuid": "913b6721",
"privateAccess": true,
"publicAccess": true,
"upnp": true
},
"sigStock": 100,
"sigWindow": 5259600,
"idtyWindow": 5259600,
"msWindow": 5259600,
"rootoffset": 0,
"remoteport": 15278,
"ipv4": "192.168.1.20",
"ipv6": "2a01:e35:8a19:a290:b0d9:e75c:b0ff:247d",
"port": 15278,
"remoteipv4": "",
"remoteipv6": "",
"udTime0": 1488970800,
"udReevalTime0": 1490094000,
"bmaWithCrawler": false,
"proxiesConf": {
"reachingClearEp": "clear",
"forceTor": false
}C’est quoi la manip pour tout mettre dans une fenêtre déroulante ?
@nay4 merci la config me parait bonne. je n’utilise pas UPnP mais cette erreur tu l’avais peut être déjà dans les log lors des versions précédentes, tu a été voir les log juste parce que ton noeud n’établis aucune connexion c’est ça ?
Il faut savoir que c’est normal et que ça peut arriver, surtout si ton noeud démarre après avoir été éteint ou désynchronisé, des fois ton noeud n’arrive pas a établir de connexion tout simplement parce qu’il n’y a de la place nul part. Demande aux membres calculants que tu connais de t’ajouter dans leur liste de privileged (et fait de même avec eux du coup).
Sinon resync manuellement relance et attend, ton noeud retente de se connecter au réseau toutes les 10 min
Surligne le texte et clique sur l’icône </>
Effectivement, je suis maintenant connecté à un nœud…
Oui il faut comprendre que les connexions WS2P ne sont pas immédiates et que votre noeud Duniter peut rester sans connexion une dizaine de minutes c’est tout à fait normal. Je prévois d’améliorer ce point pour duniter 1.7 parmis bien d’autres changements détaillés ici : https://github.com/duniter/duniter/issues/1203
En fait, en y repensant, si BMA n’est pas activé, Sakia ne pourrait même pas se connecter (le noeud apparaitrait donc en rouge).
Donc si des noeuds apparaissent en retard dans BMA mais pas dans WS2P, c’est que BMA est activé mais qu’un bug l’empêche de diffuser le nouveau block dans la websocket ?
Je ne savais pas. Merci pour la clarification.
J’ai personnellement cette erreur parfois sur mon poste, car il possède deux cartes réseau : 1 wifi et 1 ethernet. Or quand la requête UPnP est envoyée à la box, il se peut que l’ouverture de port ne coïncide pas avec l’IP utilsée (par ex. l’UPnP de Duniter demande l’ouverture d’un port vers une IP<A> différente en utilisant lui-même l’IP<B>).
C’est peut-être totalement autre chose pour toi, mais voilà mon cas