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