J’ai un souci avec mes conteneurs duniter v2. Il semble que les communications P2P ne se font pas sur le port 30333 comme auparavant, mais sur un port attribué aléatoirement au démarrage du conteneur. Pas exemple pour mon miroir Gtest c’est actuellement le port 42901.
Ai-je loupé une info sur une variable qui permettrait de forcer le port utilisé ?
J’ai relancé le noeud après avoir configuré cette variable :
DUNITER_LISTEN_ADDR: "/ip4/0.0.0.0/tcp/30333"
Je vois bien que le noeud est lancé avec l’option --listen-addr /ip4/0.0.0.0/tcp/30333. Pourtant dans les logs :
2026-03-23 12:41:09 Running JSON-RPC server: addr=0.0.0.0:9944,[::]:35221
Cette fois c’est donc le port 35221 qui est attribué aléatoirement.
Je ne comprends pas trop. Ça marchait parfaitement il y a quelques mois.
Tu utilises le conteneur ou le paquet Debian ? Pour le paquet Debian, il attribue un port aléatoire si le port est déjà occupé. Tu sembles utiliser le conteneur, c’est étrange que tu aies ce comportement.
J’utilise le conteneur.
Tu veux le port de RPC ou de la libp2p en 30333 (port habituel de 30333) ?
Ci-dessus c’est RPC !
Effectivement, je pense que c’est uniquement pour RPC, et en gros, la 2ème partie [::]:35221 c’est un listening sur port 35221, mais pour IPv6.
C’est étrange qu’il ajoute un mapping IPv6 aléatoire par contre o_O
On est d’accord que les options --public-addr et --listen-addr de duniter concernent le P2P et non le RPC ?
Mon étonnement est qu’avec les images actuelles de duniter le port d’écoute P2P semble aléatoire au lieu d’être 30333. Qui peut me confirmer ça ?
Oui, les 2 sont pour P2P.
Je pense que le --listen-addr sert à déclarer au serveur d’utiliser un port (interne) particulié pour le P2P (permet également de préciser si en WebSocket ou pas).
Lié à cette entrée là, tu dois potentiellement mapper le port (interne) précisé vers le Host si tu veux l’exposer publiquement (dans la section ports:).
Et le --public-addr est je pense uniquement pour le partage des endpoints (et il faut bien y renseigner le port et/ou dns accessible depuis l’extérieur).
Autre chose, si tu utilises les arguments --listen-addr et --public-addr dans les command:; je pense qu’il faut faire attention à retirer les variables d’environment: : DUNITER_LISTEN_ADDR et DUNITER_PUBLIC_ADDR !
Pour ma part, je n’ai pas eu de soucis ou les ports P2P sont aléatories; j’ai même fais un test en ouvrant 2 ports P2P en même temps pour avoir un en TCP brut et un en WebSocket et j’ai fait les tests de connectivités sur les 2 (même si au final, il ne vaut mieux garder qu’une seule déclaration P2P par serveur 
)
@Pini tu peux donner ton noeud pour lequel tu as des soucis ?
=> son DNS, le port que tu expose, et le node “identity” pour recomposer l’ “url” p2p
Exemple pour récupérer le node identity dans les logs de démarrage:
docker compose logs | grep "identity"
duniter-gtest-mirror-bn | 2026-03-21 17:40:42 Local node identity is: 12D3KooWD1mp5M1CsZnVuPWQBHs5PhGZfhSEtm6gh6UvypcVrpjh