At Github, it is obvious how devs discover and contribute solutions to issues. It should be that obvious here too, since Github directs users here when they are compelled to submit an issue.
My guess is, those 2 nodes are on your local network. This means your node is actually not reachable from the internet, which explains why it is so hard to get anything from it.
The most likely reason is that you are behind a NAT router and you did not set up port forwarding:
I tried to look at what might NOT be an “unknown namespace” in that publisher key but every command to which I send /ipns/k2k4r8n098cwalcc7rdntd19nsjyzh6rku1hvgsmkjzvnw582mncc4b4 returns Error: not a valid proquint string. Is that something that isn’t possible?
You were correct about the NAT router. The owner has done all the instructions except the machine reboot at the end, and I was able to download the file, so I guess in his case, the reboot is unnecessary. He may still do it, just in case.
Thanks for your help!
Do you think there is any chance that IPFS might be enhanced to do an inbound peers count upon publishing to encode your wisdom and notify the operator “Only 0.03% of your peers are inbound. Have you set up port forwarding?”
Actually, the daemon already tests what addresses it is reachable through, and only publishes those that work. When doing that, it already knows if it’s accessible from the outside or not, it would just need to let you know. However, if your goal is just to consume content, it doesn’t matter that you are unreachable, but if you want to publish content, it is paramount that you are actually reachable.
After the node PC reboot this morning to fully activate the port forwarding, I have far fewer peers with only two non-local inbound. Also, more difficulty accessing via public gateways the newly published content on the node. I think UPnP alone resulted in more connections. If the peer count doesn’t improve will disable the forwarding after the IPFS publish now in process and see if the better results return. Before rebooting it had as many as 8 inbound out of as many as 1300 peers.
> ping 104.156.24.117
PING 104.156.24.117 (104.156.24.117): 56 data bytes
64 bytes from 104.156.24.117: icmp_seq=0 ttl=50 time=60.107 ms
64 bytes from 104.156.24.117: icmp_seq=1 ttl=50 time=61.751 ms
64 bytes from 104.156.24.117: icmp_seq=2 ttl=50 time=60.979 ms
64 bytes from 104.156.24.117: icmp_seq=3 ttl=50 time=64.602 ms
64 bytes from 104.156.24.117: icmp_seq=4 ttl=50 time=60.487 ms
^C
--- 104.156.24.117 ping statistics ---
5 packets transmitted, 5 packets received, 0.0% packet loss
round-trip min/avg/max/stddev = 60.107/61.585/64.602/1.605 ms
> nc 104.156.24.117 32908
> nc 104.156.24.117 4001
>
An interesting clue is that port 32908 has a “block” rule on it, but port 4001 has a “reject” rule on it. So, your firewall handles them differently, or they go to different places.
That’s as much as I can tell from here, the rest is up to you.
okay, my ufw now allows 4001 and a lot of inbound is now connected. Also, now have about 1300 peers. Much better appearing. Please let me know what your test now shows. Thanks
Success!!! Your node is now reachable from the internet. However, it now needs to do a good “reprovide”, as some of your content isn’t advertised properly:
This will happen automatically within the next 12 hours (unless you have changed the defaults). You can also trigger it manually with the following command: