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

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.

Probably we need to open a GitHub issue to investigate more!

Hi! I’m on the go-ipfs team and work on the data transfer subsystem Bitswap (though fairly recently). I’d be happy to provide some assistance on the slowness vis a vis downloading. I’d love to get some specifics about your setup and then maybe we can go ahead and file a Github issue if there if it’s a bug in the code.

Just curious are you guys both running IPFS 0.4.18 (the most recent released version)? Are either of you building from source? (i.e. master on the IPFS github repo)?

I tried replicating on my machine but right now I have the same connection issues as you started off with and can’t diagnose the slowness as a result. (i.e. @john1deer I can’t ping your machine - I can ping the relay you gave but it won’t let me swarm connect to your peer).

2 Likes

I did some tests here: Proposal: Peer Hint URI scheme

I’m happy to help though. :slight_smile:

I have 0.4.18 yes. Not building from source.

0.4.18 (not source)

Restarted daemon just now (with everything turned on):
$ ipfs daemon
Initializing daemon…
go-ipfs version: 0.4.18-
Repo version: 7
System version: amd64/darwin
Golang version: go1.11.1
Swarm listening on /ip4/127.0.0.1/tcp/4001
Swarm listening on /ip4/127.0.0.1/udp/4001/quic
Swarm listening on /ip4/192.168.201.217/tcp/4001
Swarm listening on /ip4/192.168.201.217/udp/4001/quic
Swarm listening on /ip6/::1/tcp/4001
Swarm listening on /p2p-circuit
Swarm announcing /ip4/127.0.0.1/tcp/4001
Swarm announcing /ip4/127.0.0.1/udp/4001/quic
Swarm announcing /ip6/::1/tcp/4001
API server listening on /ip4/127.0.0.1/tcp/5001
Gateway (readonly) server listening on /ip4/127.0.0.1/tcp/8080
Daemon is ready

Sorry for slow reply. I’d be include to wait for 0.4.19 to get published. BS has undergone extensive changes that should mitigate this kind of issue.

I’m assuming BS = BitSwap?

The issue here seems to be NAT traversal, although this could be fixed by adding a block “relay” functionality to BitSwap (if I have a route to a block on a peer’s wantlist - I can fetch it for the peer).