Added a file - but it's not accessible on gateway

I’ve added a file (QmUr3Tp47hyVXnLDSoqpwL4WWLTu2NLZD2GoXimVW2Vr4Z) then attempted to access it at http://ipfs.io/ipfs/QmUr3Tp47hyVXnLDSoqpwL4WWLTu2NLZD2GoXimVW2Vr4Z
This doesn’t seem to work: download is stuck at 1MB (out of 87MB), and I don’t see significant outgoing traffic from my node (RateOut: 8.6 kB/s)

What am I missing?

Thanks in advance,
J

Does the solution from this thread work for you too?

I don’t control the NAT device. I will try this on a different machine and report

Why is this needed, though? The node is connected to hundreds of peers.

I know right. See my tests: Proposal: Peer Hint URI scheme

So, I searched first where your file is available.

$ ipfs dht findprovs QmUr3Tp47hyVXnLDSoqpwL4WWLTu2NLZD2GoXimVW2Vr4Z
QmNqNHyA7oPegAaDQDpXGKGs9CmBjWQDTeUW6mzTXecMc5
QmVqt5oddjjweUdepGoNWR1gBkRjo8zWe6ysVWxUDNZv3p
QmV4j6GkC62ZabcGbubWVer5Ed63YztZMTbbUbwDKfcmiS

Then I checked if those are acessible:

$ ipfs dht findpeer QmNqNHyA7oPegAaDQDpXGKGs9CmBjWQDTeUW6mzTXecMc5
/ip4/127.0.0.1/tcp/4001
/ip6/::1/tcp/4001
/ip4/146.185.57.50/tcp/64417
$ ipfs dht findpeer QmVqt5oddjjweUdepGoNWR1gBkRjo8zWe6ysVWxUDNZv3p
/ip6/2604:1380:2000:f700::3/tcp/4001
/ip6/::1/tcp/4001
/ip4/209.94.90.1/tcp/4001
/ip4/147.75.83.187/tcp/4001
/ip4/127.0.0.1/tcp/4001
/ip6/2602:fea2:2::1/tcp/4001
$ ipfs dht findpeer QmV4j6GkC62ZabcGbubWVer5Ed63YztZMTbbUbwDKfcmiS
/ip4/209.94.90.1/tcp/4001
/ip6/2602:fea2:2::1/tcp/4001
/ip6/2604:1380:2000:f700::1/tcp/4001
/ip6/::1/tcp/4001
/ip4/147.75.83.53/tcp/4001
/ip4/127.0.0.1/tcp/4001

The later first gave me a super long input, but then when requerying it gave me that.

When I do telnet [ip] [port], I can’t open the first one. Nor the second IPv4 one (I don’t have IPv6), nor the 3rd one.

Thanks.

NATs are the standard, not the exception.
I’d expect a decentralized protocol such as IPFS to be optimized for this use-case - e.g. NAT traversal, relays (which could cache blocks while at it), etc.

1 Like

Yeah. I feel you.

Apparently it’s possible with some relay hopping or whatever to have 2 nodes on NAT sending files to each other.

But if just 1 machine is behind NAT then it should work. It worked for me.

Can you tell me your peer ID? I’ll try to ping you via IPFS.

QmNqNHyA7oPegAaDQDpXGKGs9CmBjWQDTeUW6mzTXecMc5

$ ipfs ping QmNqNHyA7oPegAaDQDpXGKGs9CmBjWQDTeUW6mzTXecMc5
Looking up peer QmNqNHyA7oPegAaDQDpXGKGs9CmBjWQDTeUW6mzTXecMc5
Peer lookup error: routing: not found
$ ipfs ping QmNqNHyA7oPegAaDQDpXGKGs9CmBjWQDTeUW6mzTXecMc5
Looking up peer QmNqNHyA7oPegAaDQDpXGKGs9CmBjWQDTeUW6mzTXecMc5
PING QmNqNHyA7oPegAaDQDpXGKGs9CmBjWQDTeUW6mzTXecMc5.
Ping error: dial attempt failed: <peer.ID QmEF1jcH> --> <peer.ID QmXecMc5> dial attempt failed: context deadline exceeded
$ ipfs ping QmNqNHyA7oPegAaDQDpXGKGs9CmBjWQDTeUW6mzTXecMc5
Looking up peer QmNqNHyA7oPegAaDQDpXGKGs9CmBjWQDTeUW6mzTXecMc5
PING QmNqNHyA7oPegAaDQDpXGKGs9CmBjWQDTeUW6mzTXecMc5.
Ping error: dial backoff

This machine is behind NAT, but with reachable ports.

Try pinging me with ipfs ping QmaRmsQ2BfJFqRkqgE9MEPTgp4vJvwh5FTWPxf1iEF1jcH

$ ipfs ping QmaRmsQ2BfJFqRkqgE9MEPTgp4vJvwh5FTWPxf1iEF1jcH
Looking up peer QmaRmsQ2BfJFqRkqgE9MEPTgp4vJvwh5FTWPxf1iEF1jcH
PING QmaRmsQ2BfJFqRkqgE9MEPTgp4vJvwh5FTWPxf1iEF1jcH.
Pong received: time=79.98 ms
Pong received: time=82.88 ms
Pong received: time=76.76 ms

Bizzare. Now I can ping you.

ipfs ping QmNqNHyA7oPegAaDQDpXGKGs9CmBjWQDTeUW6mzTXecMc5
PING QmNqNHyA7oPegAaDQDpXGKGs9CmBjWQDTeUW6mzTXecMc5.
Pong received: time=78.99 ms
Pong received: time=74.47 ms
Pong received: time=78.41 ms
Pong received: time=106.34 ms
Pong received: time=229.66 ms
Pong received: time=86.38 ms
Pong received: time=78.82 ms
Pong received: time=84.99 ms
Pong received: time=163.52 ms
Pong received: time=107.31 ms
Average latency: 108.89ms

From what I get from this experiment: now that you pinged me, IPFS found a way to route and now we can ping each other.

that could be the case, but note that I’ve also connected to a relay node (QmaCpDMGvV2BGHeYERUEnRQAwe3N8SzbUtfsmvsqQLuvuJ)
Although as far as I can tell, you’d need to explicitly request to connect to my peer.

E.g.
ipfs swarm connect /ipfs/QmaCpDMGvV2BGHeYERUEnRQAwe3N8SzbUtfsmvsqQLuvuJ/p2p-circuit/ipfs/QmNqNHyA7oPegAaDQDpXGKGs9CmBjWQDTeUW6mzTXecMc5

also: I’ve added a 100MB random file - QmZcnJRBtgG12EgfAx7UCwcjAHCRdCfxWscMSNiTeiVMbP
If you care to test some more

Well I did now ipfs get your file (*r4z). Again the bizzare way of downloading. Where 1 MB goes fast then stalls, then 1 MB goes fast again, then stalls.
I’m at 7.00 MB as writing this.

It’s like IPFS not having the heuristic capability, that if chunk 1 is at this node, then so should be chunk 2. It should do this if the peer-list having the file is small.

possible duplicate?

I don’t think it is exactly a duplicate, but it is related.

This problem here is that he is behind NAT and he can’t open ports.

I don’t have enough knowledge butI think it might also be related to some changes in the infrastructure of ipfs.io

With a direct connection to any IPFS node it works fine, so NAT is not to include.

@john1deer can you try to directly connect to the Siderus Gateway and see if it works fine?

curl https://meta.siderus.io/ipfs/connect.sh | bash

Then you try:

https://siderus.io/ipfs/QmZcnJRBtgG12EgfAx7UCwcjAHCRdCfxWscMSNiTeiVMbP

Downloaded 13.5MB, then failed

Why opening ports even needed?

IPFS is supposed to support NAT traversal techniques such as STUN/ICE that should allow it to establish a connection between most NAT configurations.

I agree. I’m still downloading your *r4Z file. I’m at 22 MB.