not waiting enough time for the gateway to discover (this can take anywhere from 1->10 minutes)
ipfs.io has been having technical difficulties the last few days lately so you can try another gateway
your node isn’t reachable from the internet (nat, firewall, etc…)
your node isn’t online
To better help debugging you’ll probably want to provide the version of IPFS you are using, and if you have altered any of the default configurations what you changed
iirc you need to leave the browser tab open while you’re requesting the content from the gateway, if after ~10minutes you’ll usually get a gateway timeout error
Probably not, but I would upgrade to v0.4.19 anyways
Try using v0.4.19 which was just released. It should have better defaults for dealing with NATs (like you’re probably behind if you’re using a home internet connection).
That’s the command for cmd.exe, but you got the information I was looking for. The fact that your peer isn’t even hitting the default low water mark of 600 peers suggests to me that there are some connectivity issues to your node.
One thing you could try is open port 4001 and forward it to your computer manually, rather than trying to rely on UPnP.
Yeah, that resolves for me. I just retrieved it through my local node’s gateway (no pin, but it’s still cached) and I can also see it through the cloudflare-ipfs.com and ipfs.infura.io gateways.
It seems like the ipfs.io gateway is maybe just having some issues.
My mistake for not noticing the relevant hash in the original post and not trying this earlier.
I’ve tried a bunch of other tests, and it is really an issue in my node with public gateways. I found this similar topic, but i don’t know how to apply the solution: Help accessing files from public gateway
Could you help me out configuring my router to open port correctly?
You’re looking for port forwarding, not port triggering. I don’t know where it is in your interface, but you should forward port 4001 to Internal port 4001 for 192.168.0.105.
Yeah, that looks right (I wasn’t previously familiar with port forwarding being referred to as a “virtual server”).
What are the other tests you’ve done that have confirmed this is an issue specific to your node and not something specific to the ipfs.io gateway? It wouldn’t surprise me if some of the more popular public gateways are overloaded.
The fact that my node could retrieve the file from yours would suggest it’s not something specific to your node.
I did it, man! the modem in bridge mode had to have the same port configs, but pointing to the router address. Thank you for the patience! It isn’t fast, but works.
Also, about the tests:
1- I couldn’t open even in other public gateways as cloudflare or infura.
2- When I asked you to try the file, you probably pinned it, and I could open it in the public gateway, so I asked other to pin another file that I coudn’t open. When he pinned it, I could see it as well.
Know a have a bridge mode modem pointing the ports to the router, and the router poiting to my desktop. I realized that que number of peers increased too. Before it had about 250~400, and now ~740.
Also, I want to ask you: there is a precise command to see who is pinning a file? I saw in a topic that dht findprovs would to it, but with some tests, I realized that is more like a footprint of who interacted with the file.
Thanks for sharing your solution. I totally forgot about the modem/gateway device as a potential source of issues for some home connections.
These are nodes that have said they can provide the content for a given hash, but the list isn’t limited to nodes that are pinning a hash. I don’t think there’s any way for a node that says it’s pinning a hash to actually prove it has the content locally – this is more inline with some of the challenges that filecoin is trying to solve.