# \`ipfs dht get \<key\>\` stucks without returning any result

**URL:** <https://discuss.ipfs.tech/t/ipfs-dht-get-key-stucks-without-returning-any-result/4733>\
**Category:** Kubo\
**Tags:** go-ipfs\
**Created:** [January 24, 2019, 2:53am UTC](https://discuss.ipfs.tech/t/ipfs-dht-get-key-stucks-without-returning-any-result/4733 "2019-01-24T02:53:06Z")\
**Posts on this page:** 10\
**Page:** 1

<div class="post-metadata">

**Author:** ![LastExile16](https://sea2.discourse-cdn.com/flex020/user_avatar/discuss.ipfs.tech/lastexile16/32/1353_2.png) [@LastExile16](https://discuss.ipfs.tech/u/LastExile16)\
**Post date:** [January 24, 2019, 2:53am UTC](https://discuss.ipfs.tech/t/ipfs-dht-get-key-stucks-without-returning-any-result/4733/1 "2019-01-24T02:53:06Z")

</div>

I tried to use the `ipfs dht get <key>` command to see what exactly does it do, but it just stucks without returning any value!  
I used verbose mode to see what’s going on, I got a lot of repeated messages that I can’t understand and I couldn’t find explanations in the documentation, Like `adding peer to query: <peer.ID SgKdrb>` with a very short peerId! and `dialing peer: <peer.ID duMrvC>` and an error messages like `error: dial attempt failed: <peer.ID cGnsFX> --> <peer.ID a15XHc> dial attempt failed: context deadline exceeded`  
What the `ipfs dht get <key>` command supposed to return? from the documentation it says _it outputs best value for the given key_ but what does it mean by that? the value is supposed to be the \_NodeId\_s who are providing the content or the value of the content?  
Can you explain the meaning of the verbose output of the command, please?

```
$ ipfs dht get -v QmcZojhwragQr5qhTeFAmELik623Z21e3jBTpJXoQ9si1T
11:43:09.333: adding peer to query: <peer.ID SgKdrb>
11:43:09.333: adding peer to query: <peer.ID P5RWqK>
11:43:09.333: adding peer to query: <peer.ID dM5Syi>
11:43:09.333: * querying <peer.ID SgKdrb>
11:43:09.333: * querying <peer.ID dM5Syi>
11:43:09.333: * querying <peer.ID P5RWqK>
11:43:09.625: * <peer.ID SgKdrb> says use <peer.ID dDe6Su> <peer.ID NxuDte> <peer.ID VFZPvH> <peer.ID X4Dedg> <peer.ID eGnwnW> <peer.ID eMFNuR> <peer.ID TwvAzE> <peer.ID VGfj36> <peer.ID a15XHc> <peer.ID WuBNG2> 
11:43:09.625: adding peer to query: <peer.ID dDe6Su>
11:43:09.625: adding peer to query: <peer.ID NxuDte>
11:43:09.626: adding peer to query: <peer.ID VFZPvH>
11:43:09.626: adding peer to query: <peer.ID X4Dedg>
11:43:09.626: adding peer to query: <peer.ID eGnwnW>
11:43:09.626: adding peer to query: <peer.ID eMFNuR>
11:43:09.626: adding peer to query: <peer.ID TwvAzE>
11:43:09.626: adding peer to query: <peer.ID VGfj36>
11:43:09.627: adding peer to query: <peer.ID a15XHc>
11:43:09.627: adding peer to query: <peer.ID WuBNG2>
11:43:09.627: dialing peer: <peer.ID dDe6Su>
11:43:09.627: * querying <peer.ID NxuDte>
11:43:09.635: * <peer.ID dM5Syi> says use <peer.ID WevMU2> <peer.ID WsvzSc> <peer.ID SYXZz6> <peer.ID fMb1VC> <peer.ID TBqBXo> <peer.ID YuVqJz> <peer.ID duMoWQ> <peer.ID br7MTX> <peer.ID Yx1cGs> <peer.ID QvULpP> <peer.ID TUg5e2> <peer.ID WM2Cn3> <peer.ID eR9sJ2> <peer.ID YwSbZc> <peer.ID XJ6kNh> <peer.ID TdxazX> 
11:43:09.635: adding peer to query: <peer.ID WevMU2>
11:43:09.635: adding peer to query: <peer.ID WsvzSc>
11:43:09.636: adding peer to query: <peer.ID SYXZz6>
11:43:09.636: adding peer to query: <peer.ID fMb1VC>
11:43:09.636: adding peer to query: <peer.ID TBqBXo>
11:43:09.636: adding peer to query: <peer.ID YuVqJz>
11:43:09.636: adding peer to query: <peer.ID duMoWQ>
11:43:09.637: adding peer to query: <peer.ID br7MTX>
11:43:09.637: adding peer to query: <peer.ID Yx1cGs>
11:43:09.637: adding peer to query: <peer.ID QvULpP>
11:43:09.638: adding peer to query: <peer.ID TUg5e2>
11:43:09.639: adding peer to query: <peer.ID WM2Cn3>
11:43:09.639: adding peer to query: <peer.ID eR9sJ2>
11:43:09.639: adding peer to query: <peer.ID YwSbZc>
11:43:09.640: adding peer to query: <peer.ID XJ6kNh>
11:43:09.640: adding peer to query: <peer.ID TdxazX>
.
.
. 
11:43:17.544: dialing peer: <peer.ID duMrvC>
11:43:17.544: dialing peer: <peer.ID cUQy2P>
11:43:17.544: dialing peer: <peer.ID PQ4yES>
11:43:17.544: dialing peer: <peer.ID V9sUhN>
11:43:17.544: dialing peer: <peer.ID ay3qwH>
11:43:17.544: * querying <peer.ID QBpDhT>
11:43:17.555: error: dial attempt failed: <peer.ID cGnsFX> --> <peer.ID eMFNuR> dial attempt failed: context deadline exceeded
11:43:17.555: error: dial attempt failed: <peer.ID cGnsFX> --> <peer.ID eGnwnW> dial attempt failed: context deadline exceeded
11:43:17.555: error: dial attempt failed: <peer.ID cGnsFX> --> <peer.ID UMtS1c> dial attempt failed: context deadline exceeded
11:43:17.555: error: dial attempt failed: <peer.ID cGnsFX> --> <peer.ID VGfj36> dial attempt failed: context deadline exceeded
11:43:17.556: error: dial attempt failed: <peer.ID cGnsFX> --> <peer.ID a15XHc> dial attempt failed: context deadline exceeded
11:43:17.556: error: dial attempt failed: <peer.ID cGnsFX> --> <peer.ID VFZPvH> dial attempt failed: context deadline exceeded
11:43:17.557: error: dial attempt failed: <peer.ID cGnsFX> --> <peer.ID c3skSp> dial attempt failed: context deadline exceeded
11:43:17.557: error: dial attempt failed: <peer.ID cGnsFX> --> <peer.ID aBSuRH> dial attempt failed: context deadline exceeded
11:43:17.558: error: dial attempt failed: <peer.ID cGnsFX> --> <peer.ID UQDKeF> dial attempt failed: context deadline exceeded
11:43:17.558: error: dial attempt failed: <peer.ID cGnsFX> --> <peer.ID XQNDaJ> dial attempt failed: context deadline exceeded
11:43:17.560: error: dial attempt failed: <peer.ID cGnsFX> --> <peer.ID dDe6Su> dial attempt failed: dial tcp4 172.17.0.8:4001: i/o timeout
11:43:17.560: error: dial attempt failed: <peer.ID cGnsFX> --> <peer.ID YG5Sgb> dial attempt failed: context deadline exceeded
11:43:17.561: error: dial attempt failed: <peer.ID cGnsFX> --> <peer.ID XLUBGS> dial attempt failed: context deadline exceeded
11:43:17.568: error: dial attempt failed: <peer.ID cGnsFX> --> <peer.ID V8eS1T> dial attempt failed: context deadline exceeded
11:43:17.569: error: dial attempt failed: <peer.ID cGnsFX> --> <peer.ID Zm3xya> dial attempt failed: context deadline exceeded
11:43:17.623: error: dial attempt failed: <peer.ID cGnsFX> --> <peer.ID aW3RyT> dial attempt failed: context deadline exceeded
11:43:17.711: * <peer.ID QBpDhT> says use <peer.ID SYXZz6> <peer.ID YuVqJz> <peer.ID duMoWQ> <peer.ID SDiUEE> <peer.ID PS3cWu> <peer.ID Yx1cGs> <peer.ID TUg5e2> <peer.ID WhdE2T> <peer.ID WkYprf> <peer.ID X3ocrC> <peer.ID PLa871> <peer.ID cbBRor> <peer.ID WM2Cn3> <peer.ID eFk8h5> <peer.ID bjQTLK> <peer.ID QLESt3> <peer.ID Nypuyu> <peer.ID TdxazX> <peer.ID P5RWqK> 
11:43:17.712: dialing peer: <peer.ID WkPLgX>
11:43:17.712: * querying <peer.ID RWvGqZ>
11:43:17.803: error: dial attempt failed: <peer.ID cGnsFX> --> <peer.ID Zis2Uh> dial attempt failed: context deadline exceeded
11:43:17.808: error: dial attempt failed: <peer.ID cGnsFX> --> <peer.ID aApUGi> dial attempt failed: context deadline exceeded
11:43:17.820: * <peer.ID doLjVi> says use <peer.ID YU4giB> <peer.ID e7bRcN> <peer.ID WXqVdn> <peer.ID XWUiuj> <peer.ID QBpDhT> <peer.ID aXmg2z> <peer.ID RSVm9d> <peer.ID aMJWoE> <peer.ID buzpeR> <peer.ID Xsj5WK> <peer.ID TtggHg> <peer.ID QVricD> <peer.ID dj7cEE> <peer.ID RTq3F6> <peer.ID WW9hcR> <peer.ID XAhAvf> <peer.ID ak3w1x> <peer.ID PWTWnN> <peer.ID fXERYL>
```

---

<div class="post-metadata">

**Author:** ![leerspace](https://avatars.discourse-cdn.com/v4/letter/l/94ad74/32.png) [@leerspace](https://discuss.ipfs.tech/u/leerspace)\
**Post date:** [January 25, 2019, 2:20am UTC](https://discuss.ipfs.tech/t/ipfs-dht-get-key-stucks-without-returning-any-result/4733/2 "2019-01-25T02:20:12Z")

</div>

There are a lot of questions in your post, but I’ll try to get to a few of them.

> [@LastExile16](#):
>
> I tried to use the ipfs dht get \<key\> command to see what exactly does it do, but it just stucks without returning any value!

What key are you trying to get? It’s probably not able to find a value for it in the DHT.

> [@LastExile16](#):
>
> I got a lot of repeated messages that I can’t understand and I couldn’t find explanations in the documentation, Like adding peer to query: \<peer.ID SgKdrb\> with a very short peerId!

These aren’t full peer IDs in the verbose output. They’re just a portion of the peer ID.

> [@LastExile16](#):
>
> What the ipfs dht get \<key\> command supposed to return? from the documentation it says it outputs best value for the given key but what does it mean by that?

An example would be looking up a key of `/ipns/publickey` and getting the `/ipfs/...` path it points to as the return value.

Partial reference:  
[IPFS DHT sharness tests](https://github.com/ipfs/ipfs-sharness-tests/blob/master/t0170-dht.sh)

---

<div class="post-metadata">

**Author:** ![LastExile16](https://sea2.discourse-cdn.com/flex020/user_avatar/discuss.ipfs.tech/lastexile16/32/1353_2.png) [@LastExile16](https://discuss.ipfs.tech/u/LastExile16)\
**Post date:** [January 25, 2019, 2:43am UTC](https://discuss.ipfs.tech/t/ipfs-dht-get-key-stucks-without-returning-any-result/4733/3 "2019-01-25T02:43:50Z")

</div>

> [@leerspace](#):
>
> What key are you trying to get? It’s probably not able to find a value for it in the DHT.

I tried this key QmcZojhwragQr5qhTeFAmELik623Z21e3jBTpJXoQ9si1T which is a key to “Hello, World!” value, I was expecting to get whatever is refering to in the DHT. Is my understanding wrong?

---

<div class="post-metadata">

**Author:** ![sebaseba](https://sea2.discourse-cdn.com/flex020/user_avatar/discuss.ipfs.tech/sebaseba/32/1615_2.png) [@sebaseba](https://discuss.ipfs.tech/u/sebaseba)\
**Post date:** [January 25, 2019, 9:57am UTC](https://discuss.ipfs.tech/t/ipfs-dht-get-key-stucks-without-returning-any-result/4733/4 "2019-01-25T09:57:13Z")

</div>

> [@LastExile16](#):
>
> QmcZojhwragQr5qhTeFAmELik623Z21e3jBTpJXoQ9si1T

This works: [https://ipfs.io/ipfs/QmcZojhwragQr5qhTeFAmELik623Z21e3jBTpJXoQ9si1T](https://ipfs.io/ipfs/QmcZojhwragQr5qhTeFAmELik623Z21e3jBTpJXoQ9si1T)  
Also `ipfs get QmcZojhwragQr5qhTeFAmELik623Z21e3jBTpJXoQ9si1T` works, it downloads the file with `Hello, World!` inside.

`ipfs dht get` returns blank for me as well, not sure what it should give out.

---

<div class="post-metadata">

**Author:** ![LastExile16](https://sea2.discourse-cdn.com/flex020/user_avatar/discuss.ipfs.tech/lastexile16/32/1353_2.png) [@LastExile16](https://discuss.ipfs.tech/u/LastExile16)\
**Post date:** [January 25, 2019, 10:19am UTC](https://discuss.ipfs.tech/t/ipfs-dht-get-key-stucks-without-returning-any-result/4733/5 "2019-01-25T10:19:09Z")

</div>

> [@sebaseba](#):
>
> ipfs dht get returns blank for me as well, not sure what it should give out.

Yes exactly! that is why I’m asking what `ipfs dht get` is supposed to do?

---

<div class="post-metadata">

**Author:** ![leerspace](https://avatars.discourse-cdn.com/v4/letter/l/94ad74/32.png) [@leerspace](https://discuss.ipfs.tech/u/leerspace)\
**Post date:** [January 25, 2019, 1:16pm UTC](https://discuss.ipfs.tech/t/ipfs-dht-get-key-stucks-without-returning-any-result/4733/6 "2019-01-25T13:16:43Z")

</div>

> [@LastExile16](#):
>
> I tried this key QmcZojhwragQr5qhTeFAmELik623Z21e3jBTpJXoQ9si1T which is a key to “Hello, World!” value, I was expecting to get whatever is refering to in the DHT. Is my understanding wrong?

Okay, so you were trying an `/ipfs/` multihash. AFAIK IPFS doesn’t store the value for a given block’s multihash/key in the DHT – like it does for IPNS keys; rather, it stores pointers to peers that have said they can provide that multihash/key. So trying to use a raw DHT command to lookup a multihash’s value is only going to find peers (which is what I think is in your verbose output, _e.g.,_ `<peer.ID doLjVi> says use <peer.ID YU4giB> <peer.ID e7bRcN>...`). I don’t know if it would be expected for a DHT command to then query the peers for the actual value, but that sounds like it might be outside the scope of a vanilla DHT value get operation: `ipfs get`, `ipfs cat`, _etc_.

I am a bit confused though because the abbreviated peer IDs shown in the verbose output don’t seem to be the same ones that show up in `ipfs dht findprovs`.

Doing DHT lookups using `ipfs dht get /ipns/...` seems to be supported, though. If you look at the `ipfs dht put` helptext, we can see that it explicitly states the /ipns keytypes are the only ones that are currently supported; so it might make sense that `ipfs dht get` doesn’t explicitly support any other keytypes at this point, either.

> You may only use keytypes that are supported in your ipfs binary: currently  
> this is only /ipns. Unless you have a relatively deep understanding of the  
> go-ipfs routing internals, you likely want to be using ‘ipfs name publish’ instead  
> of this.

Reference  
[Understanding how the DHT is implemented](https://github.com/ipfs/go-ipfs/issues/1396) (not sure how current it still is)  
[go-ipfs/dht.go](https://github.com/ipfs/go-ipfs/blob/master/core/commands/dht.go)

---

<div class="post-metadata">

**Author:** ![leerspace](https://avatars.discourse-cdn.com/v4/letter/l/94ad74/32.png) [@leerspace](https://discuss.ipfs.tech/u/leerspace)\
**Post date:** [January 25, 2019, 1:51pm UTC](https://discuss.ipfs.tech/t/ipfs-dht-get-key-stucks-without-returning-any-result/4733/7 "2019-01-25T13:51:31Z")

</div>

I think I might be wrong about the `soandso says use someotherpeer...` messages. I think these are just a regular part of any DHT lookup and those peers aren’t the ones that are providers for `/ipfs` multihashes.

The last verbose line of an attempt to do `ipfs dht get /ipfs/QmcZojhwragQr5qhTeFAmELik623Z21e3jBTpJXoQ9si1T -v` results in the line of output below right before it returns. So I don’t think the `dht get` command supports attempts to lookup `/ipfs/` values – which don’t have values that exist in the DHT itself.

```auto
07:47:47.871: error: routing: not found

```

---

<div class="post-metadata">

**Author:** ![LastExile16](https://sea2.discourse-cdn.com/flex020/user_avatar/discuss.ipfs.tech/lastexile16/32/1353_2.png) [@LastExile16](https://discuss.ipfs.tech/u/LastExile16)\
**Post date:** [January 26, 2019, 5:05am UTC](https://discuss.ipfs.tech/t/ipfs-dht-get-key-stucks-without-returning-any-result/4733/8 "2019-01-26T05:05:33Z")

</div>

I have tested it on `ipns` by publishing a _text file_ and got a strange value, what could it be 😕

```auto
$ ipfs add testipfs.txt 
added Qmd9wBC35KuHjiaeGYANJgVpCmWLDj3phPS4PFkonYDM69 testipfs.txt
 11 B / 11 B [=====================================================================================================================================================================================] 100.00%

$ ipfs name publish Qmd9wBC35KuHjiaeGYANJgVpCmWLDj3phPS4PFkonYDM69
Published to QmcGnsFXHPLCEmjUR3H4KoDHV9vFZPiSPiJrpxa7KHtEuS: /ipfs/Qmd9wBC35KuHjiaeGYANJgVpCmWLDj3phPS4PFkonYDM69
$ ipfs dht get /ipns/QmcGnsFXHPLCEmjUR3H4KoDHV9vFZPiSPiJrpxa7KHtEuS

�0��H��?��Y8(�6�4"3�����G�l������!Y��,]P�����M_N:<�F��'t�W��"2019-01-27T04:38:59.268938606Z(:��0�"0h��z�'�)9�V^���٢���kY��cec�����
�{�8�;e"��X��Z��Aež5���g�^JY:��&���K��d��JY\�,�����މ�^k�ʕb�����1Ne
                                                                     d|���F ���Fa`'����,�����z�CŲ}VAXXewwByr�B^���L��R�a]iüס���gۨ���������{�|3�0�\����W24�/I�����Qg�
$ ipfs cat /ipns/QmcGnsFXHPLCEmjUR3H4KoDHV9vFZPiSPiJrpxa7KHtEuS
Hello test

```

---

<div class="post-metadata">

**Author:** ![LastExile16](https://sea2.discourse-cdn.com/flex020/user_avatar/discuss.ipfs.tech/lastexile16/32/1353_2.png) [@LastExile16](https://discuss.ipfs.tech/u/LastExile16)\
**Post date:** [January 26, 2019, 7:23am UTC](https://discuss.ipfs.tech/t/ipfs-dht-get-key-stucks-without-returning-any-result/4733/9 "2019-01-26T07:23:27Z")

</div>

> [@leerspace](#):
>
> I am a bit confused though because the abbreviated peer IDs shown in the verbose output don’t seem to be the same ones that show up in ipfs dht findprovs.

Maybe theese peers are those which route the query (the contacted peers in the query process)

---

<div class="post-metadata">

**Author:** ![leerspace](https://avatars.discourse-cdn.com/v4/letter/l/94ad74/32.png) [@leerspace](https://discuss.ipfs.tech/u/leerspace)\
**Post date:** [January 26, 2019, 1:57pm UTC](https://discuss.ipfs.tech/t/ipfs-dht-get-key-stucks-without-returning-any-result/4733/10 "2019-01-26T13:57:11Z")

</div>

> [@LastExile16](#):
>
> I have tested it on ipns by publishing a text file and got a strange value, what could it be 😕
> 
> ```auto
> $ ipfs add testipfs.txt 
> added Qmd9wBC35KuHjiaeGYANJgVpCmWLDj3phPS4PFkonYDM69 testipfs.txt
> 11 B / 11 B [=====================================================================================================================================================================================] 100.00%
> 
> $ ipfs name publish Qmd9wBC35KuHjiaeGYANJgVpCmWLDj3phPS4PFkonYDM69
> Published to QmcGnsFXHPLCEmjUR3H4KoDHV9vFZPiSPiJrpxa7KHtEuS: /ipfs/Qmd9wBC35KuHjiaeGYANJgVpCmWLDj3phPS4PFkonYDM69
> $ ipfs dht get /ipns/QmcGnsFXHPLCEmjUR3H4KoDHV9vFZPiSPiJrpxa7KHtEuS
> 
> �0��H��?��Y8(�6�4"3�����G�l������!Y��,]P�����M_N:&lt;�F��'t�W��"2019-01-27T04:38:59.268938606Z(:��0�"0h��z�'�)9�V^���٢���kY��cec�����
> �{�8�;e"��X��Z��Aež5���g�^JY:��&���K��d��JY\�,�����މ�^k�ʕb�����1Ne
> d|���F ���Fa`'����,�����z�CŲ}VAXXewwByr�B^���L��R�a]iüס���gۨ���������{�|3�0�\����W24�/I�����Qg�
> 
> ```

When you publish something using IPNS with a private/public keypair, the `/ipfs/` hash that you want it to point to in addition to some metadata (_e.g.,_ sequence number, timestamps, TTL) and a signature. I don’t see the `/ipfs/` path in your output, but maybe it’s some kind of encoding issue – since it’s not really meant to be human-readable.

> [@LastExile16](#):
>
> ```auto
> $ ipfs cat /ipns/QmcGnsFXHPLCEmjUR3H4KoDHV9vFZPiSPiJrpxa7KHtEuS
> Hello test
> 
> ```

`ipfs cat` is basically doing two things in this example. Because it’s an `/ipns/` address, go-ipfs first has to resolve the IPNS address (_e.g.,_ `ipfs name resolve /ipns/...`) to determine the immutable `/ipfs/` path it’s pointing to (basically interpreting what’s returned by `ipfs dht get /ipns/...`. Then it has to get the content that the `/ipfs/` path is pointing to.