sks recon getting same keys over and over again

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
2 messages Options
Reply | Threaded
Open this post in threaded view
|

sks recon getting same keys over and over again

Sascha Silbe-6

After having problem with the update to to sks-1.0.10 and ocaml-3.08.3
and Berkeley DB 4.1 some time ago (and not having time to fix it due to
exams), I've rebuilt the database from fresh keydumps [1] yesterday.
During the night, sks recon catched up with most updates, but now it's
stuck in a loop:

2006-08-02 15:13:01.394200500 2006-08-02 15:13:01 Recon partner:
<ADDR_INET 65.75.25.34:11370>
2006-08-02 15:13:02.692308500 2006-08-02 15:13:02 Initiating
reconciliation
2006-08-02 15:13:29.338096500 2006-08-02 15:13:29 <recon as client>
error in callback.: Sys_error("Connection reset by peer")
2006-08-02 15:14:28.235835500 2006-08-02 15:14:28 Beginning recon as
server, client: <ADDR_INET 65.75.25.34:42278>
2006-08-02 15:14:28.235935500 2006-08-02 15:14:28 Joining reconciliation
2006-08-02 15:15:08.122735500 2006-08-02 15:15:08 Reconciliation
complete
2006-08-02 15:15:08.128242500 2006-08-02 15:15:08 651 hashes recovered
from <ADDR_INET 65.75.25.34:11371>
2006-08-02 15:16:17.194411500 2006-08-02 15:16:17 Requesting 100 missing
keys from <ADDR_INET 65.75.25.34:11371>, starting with
00255E90BBC68E7F8E45701361E7FDAD
2006-08-02 15:16:52.083744500 2006-08-02 15:16:52 100 keys received
2006-08-02 15:18:24.578916500 2006-08-02 15:18:24 Requesting 100 missing
keys from <ADDR_INET 65.75.25.34:11371>, starting with
20FBED81CB1E387B4F15E1F839B49494
2006-08-02 15:18:49.841038500 2006-08-02 15:18:49 100 keys received
2006-08-02 15:19:50.092352500 2006-08-02 15:19:50 Requesting 100 missing
keys from <ADDR_INET 65.75.25.34:11371>, starting with
4AE54983186FC2E7A5AA3464BFCAE4A5
2006-08-02 15:20:32.378718500 2006-08-02 15:20:32 100 keys received
2006-08-02 15:21:32.874925500 2006-08-02 15:21:32 Requesting 100 missing
keys from <ADDR_INET 65.75.25.34:11371>, starting with
74ACA1DEF18BC073B5E998578112132B
2006-08-02 15:22:24.066415500 2006-08-02 15:22:24 100 keys received
2006-08-02 15:23:27.589981500 2006-08-02 15:23:27 Requesting 100 missing
keys from <ADDR_INET 65.75.25.34:11371>, starting with
A2BB4E4E76B492915201764A17C2F9FC
2006-08-02 15:24:04.659335500 2006-08-02 15:24:04 100 keys received
2006-08-02 15:25:05.136198500 2006-08-02 15:25:05 Requesting 100 missing
keys from <ADDR_INET 65.75.25.34:11371>, starting with
C72FF52CC4D4A8A003E8545574FB04C1
2006-08-02 15:25:40.350125500 2006-08-02 15:25:40 100 keys received
2006-08-02 15:26:40.698164500 2006-08-02 15:26:40 Requesting 51 missing
keys from <ADDR_INET 65.75.25.34:11371>, starting with
ED5A6C40FC74A609938232088A5190CB
2006-08-02 15:26:56.607750500 2006-08-02 15:26:56 51 keys received
2006-08-02 15:28:31.216305500 2006-08-02 15:28:31 Recon partner:
<ADDR_INET 65.75.25.34:11370>
2006-08-02 15:28:31.392793500 2006-08-02 15:28:31 Initiating
reconciliation
2006-08-02 15:28:50.822484500 2006-08-02 15:28:50 Reconciliation
complete
2006-08-02 15:28:50.828519500 2006-08-02 15:28:50 651 hashes recovered
from <ADDR_INET 65.75.25.34:11371>
2006-08-02 15:29:10.454768500 2006-08-02 15:29:10 Requesting 100 missing
keys from <ADDR_INET 65.75.25.34:11371>, starting with
00255E90BBC68E7F8E45701361E7FDAD
2006-08-02 15:29:42.557770500 2006-08-02 15:29:42 100 keys received
2006-08-02 15:31:07.402594500 2006-08-02 15:31:07 Requesting 100 missing
keys from <ADDR_INET 65.75.25.34:11371>, starting with
20FBED81CB1E387B4F15E1F839B49494
2006-08-02 15:31:34.433444500 2006-08-02 15:31:34 100 keys received
2006-08-02 15:32:34.676020500 2006-08-02 15:32:34 Requesting 100 missing
keys from <ADDR_INET 65.75.25.34:11371>, starting with
4AE54983186FC2E7A5AA3464BFCAE4A5
2006-08-02 15:33:16.638391500 2006-08-02 15:33:16 100 keys received
2006-08-02 15:35:40.899808500 2006-08-02 15:35:40 Requesting 100 missing
keys from <ADDR_INET 65.75.25.34:11371>, starting with
74ACA1DEF18BC073B5E998578112132B
2006-08-02 15:36:32.181148500 2006-08-02 15:36:32 100 keys received
2006-08-02 15:37:32.986678500 2006-08-02 15:37:32 Requesting 100 missing
keys from <ADDR_INET 65.75.25.34:11371>, starting with
A2BB4E4E76B492915201764A17C2F9FC
2006-08-02 15:38:12.052409500 2006-08-02 15:38:12 100 keys received
2006-08-02 15:39:21.953495500 2006-08-02 15:39:21 Requesting 100 missing
keys from <ADDR_INET 65.75.25.34:11371>, starting with
C72FF52CC4D4A8A003E8545574FB04C1
2006-08-02 15:39:56.807133500 2006-08-02 15:39:56 100 keys received
2006-08-02 15:40:58.159388500 2006-08-02 15:40:58 Requesting 51 missing
keys from <ADDR_INET 65.75.25.34:11371>, starting with
ED5A6C40FC74A609938232088A5190CB
2006-08-02 15:41:13.660211500 2006-08-02 15:41:13 51 keys received
2006-08-02 15:43:00.402642500 2006-08-02 15:43:00 Recon partner:
<ADDR_INET 161.53.2.216:11370>
2006-08-02 15:43:00.500259500 2006-08-02 15:43:00 Initiating
reconciliation
2006-08-02 15:43:00.600218500 2006-08-02 15:43:00 <recon as client>
error in callback.: End_of_file
2006-08-02 15:43:43.936525500 2006-08-02 15:43:43 Beginning recon as
server, client: <ADDR_INET 65.75.25.34:45431>
2006-08-02 15:43:43.936618500 2006-08-02 15:43:43 Joining reconciliation
2006-08-02 15:44:24.200235500 2006-08-02 15:44:24 Reconciliation
complete
2006-08-02 15:44:24.206191500 2006-08-02 15:44:24 651 hashes recovered
from <ADDR_INET 65.75.25.34:11371>
2006-08-02 15:44:34.216503500 2006-08-02 15:44:34 Requesting 100 missing
keys from <ADDR_INET 65.75.25.34:11371>, starting with
00255E90BBC68E7F8E45701361E7FDAD
2006-08-02 15:45:51.517544500 2006-08-02 15:45:51 100 keys received
2006-08-02 15:46:23.330692500 2006-08-02 15:46:23 Requesting 100 missing
keys from <ADDR_INET 65.75.25.34:11371>, starting with
20FBED81CB1E387B4F15E1F839B49494
2006-08-02 15:46:48.934391500 2006-08-02 15:46:48 100 keys received
2006-08-02 15:46:53.978406500 2006-08-02 15:46:53 Requesting 100 missing
keys from <ADDR_INET 65.75.25.34:11371>, starting with
4AE54983186FC2E7A5AA3464BFCAE4A5
2006-08-02 15:47:33.522588500 2006-08-02 15:47:33 100 keys received
2006-08-02 15:48:34.032842500 2006-08-02 15:48:34 Requesting 100 missing
keys from <ADDR_INET 65.75.25.34:11371>, starting with
74ACA1DEF18BC073B5E998578112132B
2006-08-02 15:49:26.656783500 2006-08-02 15:49:26 100 keys received
2006-08-02 15:50:27.463921500 2006-08-02 15:50:27 Requesting 100 missing
keys from <ADDR_INET 65.75.25.34:11371>, starting with
A2BB4E4E76B492915201764A17C2F9FC
2006-08-02 15:51:06.653937500 2006-08-02 15:51:06 100 keys received
2006-08-02 15:52:07.130149500 2006-08-02 15:52:07 Requesting 100 missing
keys from <ADDR_INET 65.75.25.34:11371>, starting with
C72FF52CC4D4A8A003E8545574FB04C1
2006-08-02 15:52:42.154263500 2006-08-02 15:52:42 100 keys received
2006-08-02 15:53:42.504437500 2006-08-02 15:53:42 Requesting 51 missing
keys from <ADDR_INET 65.75.25.34:11371>, starting with
ED5A6C40FC74A609938232088A5190CB
2006-08-02 15:53:58.707352500 2006-08-02 15:53:58 51 keys received
[...]
2006-08-02 19:56:23.165194500 2006-08-02 19:56:23 Recon partner:
<ADDR_INET 69.36.240.251:21370>
2006-08-02 19:56:23.400686500 2006-08-02 19:56:23 <recon as client>
error in callback.: Unix error: Connection refused - connect()
2006-08-02 19:57:21.616046500 2006-08-02 19:57:21 Beginning recon as
server, client: <ADDR_INET 65.75.25.34:34651>
2006-08-02 19:57:21.616141500 2006-08-02 19:57:21 Joining reconciliation
2006-08-02 19:58:13.420109500 2006-08-02 19:58:13 Reconciliation
complete
2006-08-02 19:58:13.425731500 2006-08-02 19:58:13 577 hashes recovered
from <ADDR_INET 65.75.25.34:11371>
2006-08-02 19:59:23.341317500 2006-08-02 19:59:23 Requesting 100 missing
keys from <ADDR_INET 65.75.25.34:11371>, starting with
00255E90BBC68E7F8E45701361E7FDAD
2006-08-02 19:59:53.447023500 2006-08-02 19:59:53 100 keys received
2006-08-02 20:01:32.117663500 2006-08-02 20:01:32 Requesting 100 missing
keys from <ADDR_INET 65.75.25.34:11371>, starting with
2584E749698402B51BBE6EBA89A0F246
2006-08-02 20:01:57.921633500 2006-08-02 20:01:57 100 keys received
2006-08-02 20:03:00.523074500 2006-08-02 20:03:00 Requesting 100 missing
keys from <ADDR_INET 65.75.25.34:11371>, starting with
4F421A3E7264B2E197D0827201C477EB
2006-08-02 20:04:00.010948500 2006-08-02 20:04:00 100 keys received
2006-08-02 20:05:00.910922500 2006-08-02 20:05:00 Requesting 100 missing
keys from <ADDR_INET 65.75.25.34:11371>, starting with
836A69E09D85DC1627DC380F8B2532BD
2006-08-02 20:05:40.953836500 2006-08-02 20:05:40 100 keys received
2006-08-02 20:06:46.269507500 2006-08-02 20:06:46 Requesting 100 missing
keys from <ADDR_INET 65.75.25.34:11371>, starting with
B25C479AC0AD35BF6555A8189640E6CB
2006-08-02 20:07:21.390175500 2006-08-02 20:07:21 100 keys received
2006-08-02 20:08:21.791706500 2006-08-02 20:08:21 Requesting 77 missing
keys from <ADDR_INET 65.75.25.34:11371>, starting with
DCDAE5859E8A373F94180D1CECF8D710
2006-08-02 20:08:44.802574500 2006-08-02 20:08:44 77 keys received
2006-08-02 20:10:38.243296500 2006-08-02 20:10:38 Recon partner:
<ADDR_INET 65.75.25.34:11370>
2006-08-02 20:10:38.435075500 2006-08-02 20:10:38 Initiating
reconciliation
2006-08-02 20:11:01.379550500 2006-08-02 20:11:01 Reconciliation
complete
2006-08-02 20:11:01.385640500 2006-08-02 20:11:01 577 hashes recovered
from <ADDR_INET 65.75.25.34:11371>
2006-08-02 20:11:03.014218500 2006-08-02 20:11:03 Requesting 100 missing
keys from <ADDR_INET 65.75.25.34:11371>, starting with
00255E90BBC68E7F8E45701361E7FDAD
2006-08-02 20:11:51.822926500 2006-08-02 20:11:51 100 keys received
2006-08-02 20:13:15.645883500 2006-08-02 20:13:15 Requesting 100 missing
keys from <ADDR_INET 65.75.25.34:11371>, starting with
2584E749698402B51BBE6EBA89A0F246
2006-08-02 20:13:42.614652500 2006-08-02 20:13:42 100 keys received
2006-08-02 20:16:07.352602500 2006-08-02 20:16:07 Requesting 100 missing
keys from <ADDR_INET 65.75.25.34:11371>, starting with
4F421A3E7264B2E197D0827201C477EB
2006-08-02 20:17:06.698659500 2006-08-02 20:17:06 100 keys received
2006-08-02 20:18:07.676130500 2006-08-02 20:18:07 Requesting 100 missing
keys from <ADDR_INET 65.75.25.34:11371>, starting with
836A69E09D85DC1627DC380F8B2532BD
2006-08-02 20:18:46.250124500 2006-08-02 20:18:46 100 keys received
2006-08-02 20:19:47.718270500 2006-08-02 20:19:47 Requesting 100 missing
keys from <ADDR_INET 65.75.25.34:11371>, starting with
B25C479AC0AD35BF6555A8189640E6CB
2006-08-02 20:20:23.345394500 2006-08-02 20:20:23 100 keys received
2006-08-02 20:21:23.732379500 2006-08-02 20:21:23 Requesting 77 missing
keys from <ADDR_INET 65.75.25.34:11371>, starting with
DCDAE5859E8A373F94180D1CECF8D710
2006-08-02 20:21:53.921779500 2006-08-02 20:21:53 77 keys received


The documentation wiki [2] is down due to hardware failure currently, so
I cannot check it for explanations and/or solutions.
I've tried getting the first mentioned key
(00255E90BBC68E7F8E45701361E7FDAD) from both subkeys.pgp.net and the
recon peer (using the last 8/16 characters of it as key ID), but without
success.
If this key does not exist on any server, why does sks think it needs
it? And why does it receive the full 100 keys, if at least one of them
doesn't exist?


[1] ftp://ftp.pramberger.at/services/keyserver/keydump/
[2]
http://documentation.penguin.de//cgi-bin/twiki/view/SKSKeyserver/WebHome

CU Sascha

--
http://sascha.silbe.org/


_______________________________________________
Sks-devel mailing list
[hidden email]
http://lists.nongnu.org/mailman/listinfo/sks-devel

attachment0 (205 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: sks recon getting same keys over and over again

Marco Nenciarini
On Wed, Aug 02, 2006 at 08:52:52PM +0200, Sascha Silbe wrote:

>
> After having problem with the update to to sks-1.0.10 and ocaml-3.08.3
> and Berkeley DB 4.1 some time ago (and not having time to fix it due to
> exams), I've rebuilt the database from fresh keydumps [1] yesterday.
> During the night, sks recon catched up with most updates, but now it's
> stuck in a loop:
>
> [snip]
>
> The documentation wiki [2] is down due to hardware failure currently, so
> I cannot check it for explanations and/or solutions.
> I've tried getting the first mentioned key
> (00255E90BBC68E7F8E45701361E7FDAD) from both subkeys.pgp.net and the
> recon peer (using the last 8/16 characters of it as key ID), but without
> success.
> If this key does not exist on any server, why does sks think it needs
> it? And why does it receive the full 100 keys, if at least one of them
> doesn't exist?
>
>
> [1] ftp://ftp.pramberger.at/services/keyserver/keydump/
> [2] http://documentation.penguin.de//cgi-bin/twiki/view/SKSKeyserver/WebHome
>
This is probably because a PTree corruption. Please try to regenerate
your PTree.

Ciao

--
---------------------------------------------------------------------
|    Marco Nenciarini    | Debian/GNU Linux Developer - Plug Member |
| [hidden email] | http://www.prato.linux.it/~mnencia       |
---------------------------------------------------------------------
Key fingerprint = FED9 69C7 9E67 21F5 7D95  5270 6864 730D F095 E5E4


_______________________________________________
Sks-devel mailing list
[hidden email]
http://lists.nongnu.org/mailman/listinfo/sks-devel

signature.asc (196 bytes) Download Attachment