The node with data is not publicly diallable and uses relay addresses
You can tell by doing ipfs id 12D3KooWNQpXcYyqE13dvHGKMaoadfBX9njivM6qQsgHkZgJg7o1 and seeing /p2p-circuit addresses – means you are behind a relay and explains the behavior you observed:
other protocols, like IPFS Bitswap, which is used for data transfer behind a CID, do not work over relayed connections and require direct one.
DCUtR may not work in 100% of network topologies. The fix, is to ensure your “data provider” node is publicly diallable (have public IP and port).
Rule of thumb: “retrieval clients” can be behind NATs and firewalls, but “reliable servers” should have a public address, if possible
If you run a server somewhere in the cloud, kubernetes, vps/rps, etc – ensure firewall allows incoming and outgoing traffic (both UDP and TCP) on port 4001, and that correct public address is announced.
If you have multiple layers of NATs/firewalls you may use Addresses.AppendAnnounce to manually announce the right public IP and port.
If you run a desktop node in a consumer ISP network, you may want to enable uPnP on your router and make sure Kubo config has Swarm.DisableNatPortMap=false), or manually forward/expose port 4001.
You may want to set Swarm.RelayClient.Enabled=false during testing, to ensure only direct connectivity is used on your “server”.
TIP: you can do CID retrieval diagnostic via IPFS Check online tool.
Thank you. I was able to troubleshoot various things that you mentioned. In the end the problem was that I had several VPN software running at the same time and it was causing issues.