Github -> Issues -> Here -> Search -> Gateway -> ipfs.io -> dweb.link

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.

On Telegram, my friend @ppmsilver and I discovered that the link at ipfs.io for “(PublishingShells.zip)[https://ipfs.io/ipns/k2k4r8n098cwalcc7rdntd19nsjyzh6rku1hvgsmkjzvnw582mncc4b4/Shells/publishingShells.zip]” which he says comes from a node that currently has between 200 and 1300 peers, but neither of us sees any progress trying to download it. It should also be available at https://k2k4r8n098cwalcc7rdntd19nsjyzh6rku1hvgsmkjzvnw582mncc4b4.ipns.dweb.link/Shells/publishingShells.zip but there’s no progress there either. Our solution currently is for the publisher to send the file directly to whoever wants it. Please let me know if there is more info we can provide.

I finally was able to download your file using my node, but it took a really long time (about an hour):

> ipfs dag stat /ipns/k2k4r8n098cwalcc7rdntd19nsjyzh6rku1hvgsmkjzvnw582mncc4b4/Shells/publishingShells.zip
Size: 46505, NumBlocks: 1

I’m wondering if your node is actually reachable from the internet. Try this:

> ipfs swarm peers --direction | grep inbound | wc -l              
     463

If you get 0, that’s a bad sign.

I would also try putting your peerID and CID (result of ipfs name resolve /ipns/k2....) into http://ipfs-check.on.fleek.co/.

The publishing node reports only two inbound peers.

Is there a recommended way to increase the number of inbound peers?

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:

The result of the command you provided is:

Error: invalid path "/Shells/publishingShells.zip": unknown namespace "Shells"

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?

Give me your node ID, I can sniff it from here and determine once and for all if you are reachable.

I assume you mean the publishing node. I sent them the info. We will see how it goes!

Correct, the node where the content initially resides. If you know the node ID (peer ID) for it, I can check if it’s reachable.

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.

Something isn’t right either way, you should have hundreds. What is the peer ID, so that I can assess if it’s actually reachable.

12D3KooWHWen2dsu4QWJE7srfSFduVPKTnGQ8jbx5MtG7iQc7YWD

OK, your node is absolutely not reachable at the moment. I first tried to use “id”:

> ipfs id 12D3KooWHWen2dsu4QWJE7srfSFduVPKTnGQ8jbx5MtG7iQc7YWD
Error: failed to dial 12D3KooWHWen2dsu4QWJE7srfSFduVPKTnGQ8jbx5MtG7iQc7YWD:
  * [/ip4/104.156.24.117/udp/32908/quic] timeout: no recent network activity
  * [/ip4/104.156.24.117/tcp/32908] dial tcp4 0.0.0.0:4001->104.156.24.117:32908: i/o timeout

Then I tried to connect manually:

> ipfs swarm connect /ip4/104.156.24.117/tcp/32908/p2p/12D3KooWHWen2dsu4QWJE7srfSFduVPKTnGQ8jbx5MtG7iQc7YWD
Error: connect 12D3KooWHWen2dsu4QWJE7srfSFduVPKTnGQ8jbx5MtG7iQc7YWD failure: failed to dial 12D3KooWHWen2dsu4QWJE7srfSFduVPKTnGQ8jbx5MtG7iQc7YWD:
  * [/ip4/104.156.24.117/udp/32908/quic] timeout: no recent network activity
  * [/ip4/104.156.24.117/tcp/32908] dial tcp4 0.0.0.0:4001->104.156.24.117:32908: i/o timeout
> ipfs swarm connect /ip4/104.156.24.117/udp/32908/quic/p2p/12D3KooWHWen2dsu4QWJE7srfSFduVPKTnGQ8jbx5MtG7iQc7YWD
Error: connect 12D3KooWHWen2dsu4QWJE7srfSFduVPKTnGQ8jbx5MtG7iQc7YWD failure: failed to dial 12D3KooWHWen2dsu4QWJE7srfSFduVPKTnGQ8jbx5MtG7iQc7YWD:
  * [/ip4/104.156.24.117/tcp/32908] dial tcp4 0.0.0.0:4001->104.156.24.117:32908: i/o timeout

Then I tried the fleek tester:

Nothing can reach you. So, your port forwarding isn’t set up properly, or your node isn’t announcing the right port.

You have some digging to do :slight_smile:

OK, will look it over later. Thanks

I tried a few more things, for the heck of it:

> 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:

ipfs bitswap reprovide

Hmmm, your node just disappeared! Did you change something again?