Usually, the timeout actually comes from the web server/proxy in front of the gateway, not the gateway itself (but I’m sure the gateway has a timeout too).
I just use the ipfs command on the CLI, which doesn’t timeout, and let it run, possibly for hours, until it locates the data. That’s how I got your blocks.
Actually, it just means you got them from my node, as they must still be in the cache, and my node does a really good job of providing. Which doesn’t solve your problem, but demonstrates that this can work really well, if it’s done right.
A quick question please, does your machine have a public IP attached to it so other nodes find your local IPFS, or it is using your router’s dynamic public IP assigned by ISP?
My situation is a little bit complex, but I’ll give you a simplified, more typical version of it:
my ISP assigns one public IP to my router, which then uses NAT to provide connectivity to the various devices in my home. I have set up port-forwarding on the router to make TCP 4001 and UDP 4001 forward to the same ports on my Mac, which the IPFS daemon uses for communication.
the daemon will announce my public IP along with the TCP and UDP ports, which is what other nodes will use to establish a connection.
on occasion, the IP address changes, but the daemon is able to notice and announce my new address when it happens.
@ylempereur is this neccessary to expose port 4001, since in the EKS/pod/svc we are not exposing it. also the AWS ALB is internal means, no one can reach https://our..internal.ipfs.com/ipfs/.
we access it via VPN.
now I have doubt if we don’t expose (port-forward) the 4001, how our IPFS see all the peers (around 600) and how the pinned a content can be accessed via other public IPFS gateways?
but I see that deamon is having public IP?
I think IPFS one purpose is also to bypass all the restrictions like firewall rules, …
Try to ping the PeerIDs to see if these PeerIDs are reachable
$ ipfs ping 12D3KooWFkPkpLWTKDDbE4Dtdknrhj17KTEsduYp4cnS9aYeUuYF
PING 12D3KooWFkPkpLWTKDDbE4Dtdknrhj17KTEsduYp4cnS9aYeUuYF.
Pong received: time=275.42 ms
Pong received: time=280.18 ms
Pong received: time=273.83 ms
Pong received: time=334.89 ms
Pong received: time=312.37 ms
Pong received: time=271.37 ms
Pong received: time=279.96 ms
Pong received: time=312.39 ms
Pong received: time=277.58 ms
Pong received: time=282.73 ms
Average latency: 290.07ms
----
$ ipfs ping 12D3KooWKuSzGoorvsBB8zdXCYVMEfybYKa7sDgXT3AkofAzX3FV
Looking up peer 12D3KooWKuSzGoorvsBB8zdXCYVMEfybYKa7sDgXT3AkofAzX3FV
Error: peer lookup failed: routing: not found
This means that only one of the two peers is reachable, namely 12D3KooWFkPkpLWTKDDbE4Dtdknrhj17KTEsduYp4cnS9aYeUuYF.
Finally, trying to fetch the blocks from that peer. First find the addresses of the peer:
It looks like the node isn’t publicly reachable (only has private IPs)
All the addresses with the p2p-circuit suffix are relay nodes that can help hole punch a connection to the node to retrieve blocks.
@HamidullahMuslih Can you check if that is your PeerID (ipfs id -f '<id>')?
Recommendations
Enable accelerated DHT client (seems you already did)
is this neccessary to expose port 4001, since in the EKS/pod/svc we are not exposing it.
Yes! Ensure that port 4001 on your IPFS node is reachable from the IPFS node’s public IP (either port forwarding. This is critical for other nodes to be able to retrieve blocks using the Bitswap protocol.
P.S. I just tested your node with it, and it is reachable, but, it’s through a relay, which makes things inefficient. You should open those two ports, things will work better.
The IPFS node hosting/pinning Qma2L7kLniaafUDWRbGhGy22aiHA9qsv6PD8CzZZMipBhj is not publishing/advertising provider records to the DHT
The same IPFS node is directly peering with the ipfs.io gateway so that it asks for the content directly over BitSwap (without having to look up the DHT)