Problem refreshing keys

[Jerry]

On Tue, 12 Jun 2018 16:42:25 -0400, Phil Pennock stated:

>On 2018-06-12 at 10:05 -0400, Jerry wrote:
>> Starting C:\Program Files (x86)\GnuPG\bin\gpg.exe --display-charset utf-8
>> --refresh-keys... gpg: refreshing 387 keys from
>> hkps://hkps.pool.sks-keyservers.net gpg: keyserver refresh failed: Server
>> indicated a failure
>> 
>> This is happening on a Windows 10 PRO / amd64 machine. This has been
>> occurring for several days now. Is there something wrong with the server?  
>
>Seems likely, but there's not enough information there to track it down.
>
>hkps.pool.sks-keyservers.net is a collection of servers, run by
>different people, with management software tracking their status and
>updating DNS as needed.
>
>I've no idea how to use Kleopatra to ask for more debugging details to
>get the IP, sorry.
>
>You can see some of what's going on with:
>
>  gpg-connect-agent --dirmngr 'KEYSERVER --hosttable' /bye
>
>(if Windows doesn't like that quoting, then press enter after --dirmngr
>and then enter each of the next strings as a command at the prompt)
>
>Eg, I see:
>
>% gpg-connect-agent --dirmngr 'KEYSERVER --hosttable' /bye
>S # hosttable (idx, ipv6, ipv4, dead, name, time):
>S #   0       hkps.pool.sks-keyservers.net
>S #   .       hkps.pool.sks-keyservers.net
>S #   .   --> 4 9* 3 2 1 8 7 6 5
>S #   1   4   216.66.15.2
>S #   2   4   193.224.163.43 (hufu.ki.iif.hu)
>S #   3   4   193.164.133.100 (mail.b4ckbone.de)
>S #   4   4   176.9.147.41 (mail.ntzwrk.org)
>S #   5   4   92.43.111.21 (oteiza.siccegge.de)
>S #   6   4   68.187.0.77 (stlhs.archreactor.org)
>S #   7   4   51.15.53.138 (ams.sks.heypete.com)
>S #   8   4   37.191.226.104 (host-37-191-226-104.lynet.no)
>S #   9   4   18.191.65.131
>(ec2-18-191-65-131.us-east-2.compute.amazonaws.com) OK
>
>So the "." lines are because the previous item is a pool, so they
>provide more information, and AFAICT the "-->" line is "the order we'll
>try them in, with the currently active server marked with "*"; this
>shows me that the second item is active.  This makes sense, since the
>first retrieval took a long time, but the second was very quick: the
>first keyserver failed to give something sane back, so dirmngr fell over
>to the next item, which responded, and dirmngr has remembered that one
>as "good" so it will use it again in future.
>
>Given the failure you see, the "blind stabbing in the dark" approach
>would be to use:
>
>  KEYSERVER --dead IP.ADD.RE.SS
>
>to mark the one with a "*" as "bad" and see what happens.  If that fixes
>it, then you know that the IP address which was "responding" and so
>selected was actually failing.  You can drop a note to
>sks-devel at nongnu.org with details if you manage to extract that much
>information from the tooling.
>
>-Phil, whose keyserver is in the pool and, coincidentally, is #9 above,
>       the one which worked and was selected.

This is what I am getting:

gpg-connect-agent --dirmngr 'KEYSERVER --hosttable' /bye
gpg-connect-agent: Note: '--hosttable'' is not considered an option
ERR 167772435 Unknown IPC command <Dirmngr>
ERR 167772435 Unknown IPC command <Dirmngr>

-- 
Jerry