IPNS Not Resolving

I have configured an IPFS daemon on my Raspberry PI and published a picture to:

I used the Webui at port 5001/webui to do this, the popup appeared and said to wait for 20 peers to know about it, and that completed without any obvious errors.

If I enter that and I am on my local network, with the IPFS companion extension loaded and configured to use my local machine it resolves to:

And it shows the picture.

The picture’s CID is “QmfZ2pMiBGjkqADLvi62B2eWngheQoPXNR2xv7hwKK5HVA” and if I use “https://ipfs.io/ipfs/QmfZ2pMiBGjkqADLvi62B2eWngheQoPXNR2xv7hwKK5HVA” I can get the picture.

If I use “PL Diagnose”, with that CID, and my public IP address, it all eventually goes “green” (i.e. it doesn’t show any errors).

I can trigger an “error” at any step by - for example - mistyping the test CID, mistyping one of the multiaddresses etc etc and it gives an expected error result. My point is, that at minimum the tool is able to detect errors and it is probably detecting I have a good configuration.

I can telnet to my public IP at port 4001 and get something back. If I do telnet XXX 4001 I get the response /multistream/1.0.0. That times out after a little which is what I would expect. I think a “real peer” would likely start talking the proper protocol and so forth.

What I don’t know how to do is figure out WHY the ipns name is not resolving properly if I don’t have an IPFS “something” pointed at my internal gateway. i.e. If ipfs companion can “intercept” the URL, it seems to know about it.

But if I fire up Microsoft Edge which has no IPFS companion installed OR I turn the IPFS companion off, my IPNS link doesn’t work even though it appears the content it addresses does exist.

I assume that if someone gave me a valid IPNS link it would work via a public gateway such as ipfs.io/ipns/THE_BIG_LINK_ID as expected.

But I cannot tell why my local one is not working.

I have waited several hours for it to propagate if that’s the issue; doesn’t seem to make a difference. It seems that ipfs.ip/ipns/XXX times out after I’d say 30 seconds (it’s a long time - I don’t get impatient and conclude nothing is happening - it eventually complains there is a gateway timeout).

I do have 4001 exposed to the public Internet (via a manual port forward with the proper port forward AppendAddress clauses). I don’t have any other ports on that machine exposed to the public internet. IF an “outside gateway” needed to get the data it would somehow have to negotiate some sort of way to talk over port 4001, or to negotiate it sending the data some other way.

My understanding is that’s the only port that needs port forwarding; i.e. I don’t need to port forward port 8080 (the gateway) or 5001 (the API endpoint).

My public router supposedly has UPNP enabled (I don’t trust that it does or works - it’s not the best one in the world but it claims that it does).

I wonder if anyone knows what might be up here?

1 Like

Hmm, well, it’s now working but I added the experimental configuration PubSub in the “Ipns” config section:

	"Ipns": {
		"RecordLifetime": "",
		"RepublishPeriod": "",
		"ResolveCacheSize": 128,
		"UsePubsub": true
	},

I wonder why it now works? I could have fluked some sort of time out “thing” but I suspect it’s the Pubsub setting to be honest but now I’m not sure how to test that…for sure.

1 Like

It doesn’t appear that I “fluked out”; I did the following:

  • Generated a new IPNS publishing key with the IPFS companion
  • Stopped the ipfs daemon
  • Disabled “UsePubusb: true” (by deleting it from the config)
  • Restarted the ipfs daemon

Published a file. And it timed out/couldn’t be found.

I then did the same thing as above but DID NOT disable “UsePubsub”, i.e. set it to “true” … and it works.

I verified it works using Curl from a machine that is not on my network at all (a remote SSH host on a completely different IP address somewhere in the cloud).

2 Likes