In Duniter 0.40.3, every time I come back to the home page from another one, I get this message:
“Your configuration has changed and your node is no more reachable from the network. You should reconfigure it to have a functional node.”
even if I have changed nothing at all. Is it a bug? Should I reconfigure?
I’ve changed the way Duniter tests wether it is reachable from the Internet or not.
But this new solution falls under the hairpinning problem, again.
I read on the Yunohost site that ipv6 was the best solution for this frustrating problem. I put ipv6 on on my Freebox and tried to configure Duniter accordingly, but I don’t know exactly what to do on the network page. The automatic configuration puts nothing into the remote ipv6 field. I tried some manual configurations, but hairpinning is still there. Is ipv6 working for you?
Real IPv6 should bypass hairpinning problem only encountered with poor IPv4.
I’m not an expert about IPv6, but behind a NATed box, it doesn’t change anything to use IPv4 or IPv6. The problem is the NAT.
Of course, disabling the NAT requires to use IPv6 if you want your computers to have an access to the Internet. Am I right?
Is my IPv6 unreal? However it passes every tests I tried on Internet.
I am not sure about following statements:
With real IPv6, a computer is reachable with IPv6 from everywhere even from the local network without NAT issues.
Fake IPv6, which could be a tunnel IPv6 inside an IPv4, still encounter NAT’s issues as hairpinning.
Free ISP provide real IPv6, but I don’t know about other ISP.
Your computers client and server needs to handle IPv6 to create a connection with IPv6.
I can see that your node doesn’t declare IPv6 on his endpoint:
curl 81.57.152.178:33428/network/peering
(……)
"endpoints": [
"BASIC_MERKLED_API 81.57.152.178 33428"
(……)
I have one node which handle IPv6, his endpoints looks like:
"BASIC_MERKLED_API desktop.moul.re 78.227.107.45 2a01:e34:ee36:b2d0:e79:cd45:ed65:147 24723",
First, you should fix that.
Then check your client and your server handle and have an IPv6.
If this computers are under Unix, you could check it with:
curl http://ip6.yunohost.org
ARM boards could have issues with IPv6 as my other node.
Done. I see the new IPv6 addrress in Duniter.
Done. It gets back my new address. I suppose it’s what is expected.
But…
So…
Nice 
We could say that automatic configuration is shit with IPv6 
Why don’t you use manual configuration for now?
Yes, it’s what I did. But it doesn’t solve the hairpinning problem, or what else forbids me to see my own node.
There shouldn’t be any hairpinning problem with Freebox and IPv6.
Your client computer which use, Sakia I presume, may not handle IPv6.
I think there must be an issue on Sakia about how IPv6 is handled.
It should try IPv6 first and if there is no IPv6, switch to IPv4.
The problem you encounter seems to be that there is an IPv4, Sakia try this IPv4 and as it’s not reachable, sakia consider the node down.
Code:
I tried to only put IPv6 on my node. I removed IPv4 and domain name (which leads to IPv4), and Sakia and Sikaj can’t handle the connection. That’s not clients fault, even curl can’t handle it.
cc @Inso
OK for Sakia. But Duniter can’t see my node too. It’s why it asks me to reconfigure it.
You can also observe the hairpinning in your browser:
http://[2a01:e35:1399:8b20:250d:cbe8:62f:3ea1]:33428/node/summary
If your browser can reach this address, then the workaround is to completely remove any IPv4 reference in the remote configuration. I’ve just done it on my node (well, you can let local IPv4, it’s not important):
Do not put any DNS nor IPv4 to avoid hairpinning
You can see in Sakia that only IPv6 is used for remote contact
With our manipulations, I understand how IPv6 is really important for Duniter, since it allows to completely bypass NAT & UPnP mechanisms of our boxes. We have a direct contact to the machine.
Also, it requires to put the same value for IPv6 in both local and remote sections. So I should simplify the UI to either:
- use IPv4 (which has local + remote + UPnP + local port + remote port sections)
- use IPv6 (which has only IPv6 + port =
- or even use both of them
I will try to make this change in next version 0.50.0: https://github.com/duniter/duniter/issues/686
Nice, I could also see your node.
Nice catch, without IP6 on local field it wasn’t working.[quote=“cgeek, post:15, topic:1392”]
)Nice implementation.
For now, we must use both protocols, as there almost less than 10% of nodes handling IP6.
This is source of fork as many node can’t communicate with it. It’s better to handle both.
Yes of course, I do not plan to stop using IPv4. I mean: a user can choose to only be available on the network through IPv6 (like my node is doing from today), or just IPv4, or both.
It’s already the case as of today, but a bit tricky to do. It is not clear for the users 
I will also try to handle only IP6 today to see if the node fork using this network protocol.
Yes, well done. Now I can see me! I had just to rerun Sakia. Thanks for your help.
Thank you as well, we will make the configuration much easier + definitely fix the hairpinning problem for future users thanks to your tests!
J’ai le même problème, j’essaie de créer un nœud mais toujours ce message d’erreur et je ne comprends rien aux explication données. Qqn à t’il une solution simple…??
