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-de...@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 _______________________________________________ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users