Re: [Help-gnunet] Major problems on RH7.2

[Christian Grothoff]

On Sunday 07 April 2002 08:56 am, you wrote:
> I couldn't get gnunet0.3.3 to operate successfully on RH7.2.
> There seems to be atleast a couple of problems.
>
> - Setting ACTIVEMIGRATION to YES causes gnunetd to loop
> forever in common/lookup.c/findLeastImportant(). I did
> a bit of debugging and it seems to be related to gnunetd
> creating empty files on startup, and then on
>
> j = read(LOOKUP_handle_, &entry, sizeof(ContentIndex));
>
> either a zero is returned or "on demand encoding or free"
> happens and thus LOOKUP_lips_count_ is never increased from
> zero. Or atleast it looks like that with a quick glance.

You're right. Here's my CVS log that should fix the problem:

(date: 2002/04/07 19:09:19;  author: christian;  state: Exp;  lines: +2 -1)
  | src/include/lookup.h:1.20, doc/papers/economy/main.tex:1.28,
  | src/common/lookup.c:1.64, AUTHORS:1.8
  `----------------------------------------

"I. Wronsky" <address@hidden> reports:

>>>>>>>>>>>>>>
I couldn't get gnunet0.3.3 to operate successfully on RH7.2.
There seems to be atleast a couple of problems.

- Setting ACTIVEMIGRATION to YES causes gnunetd to loop
forever in common/lookup.c/findLeastImportant(). I did
a bit of debugging and it seems to be related to gnunetd
creating empty files on startup, and then on

j = read(LOOKUP_handle_, &entry, sizeof(ContentIndex));

either a zero is returned or "on demand encoding or free"
happens and thus LOOKUP_lips_count_ is never increased from
zero. Or atleast it looks like that with a quick glance.
<<<<<<<<<<<<<

The reason is that we were comparing an unsigned (!) int against
>= 0, whereas a != -1 would have done the trick. Also, if
no content (or very little) is stored on the local node,
the search may take forever (or what seems like it). We now only
embark on the search if we know that there is a certain
quantum of content on the drive.

This fixes this problem for me.
--------------------------------------------------------------

> - After kludging my way around the last one, I noticed that
> the session keys are rarely ever accepted, as the
> key length is usually something quite different from the
> defined 128/8. I didn't even begin to look at this one,
> as it might be anything starting from incompatible ssl libs.
>
>
> SKEY: Accepting sessionkey from host
> 1DFB08D70FE20550FF04A9130E39D5A2AAE09AAA.
> SKEY rejected from host 1DFB08D70FE20550FF04A9130E39D5A2AAE09AAA (address
> 128.211.  1. 61: 2086): key.len = 17457

Could it be that you *ever* deleted your hostkey and generated a
second key? It looks to me very much like the obvious issue that
you may have two public keys known to GNUnet for the same
host and port. Did you see the message 'generating session key'
more than once? Or did you start GNUnet under two different user
accounts? If yes, than this is not a bug but a security feature (if 
two people claim that a machine is reachable with two different public keys,
the best we can do is try out both and see which one can respond (if
any). The CRC check will fail when the host decrypts the second request
because a different public key is used (a GNUnet message for another
node that is presumed to have the same IP:Port if you want to see it that 
way). 

Hostkeys will eventually expire and be purged from GNUnet, though this can 
take a while, especially since we're currently using fairly long lived keys 
because there are not so many hosts anyway. 

> Or has someone got gnunetd working with RH7.2 without tweaking
> the code? Redhat is, after all, one of the most popular linux distroes
> and if gnunets usability depends on many hosts participating, its
> mandatory that the system can be easily, straightforwardly and
> reliably used on the most popular distributions.

We are, in fact, developing under RH 7.1/7.2 and SuSE (ok, and somebody under 
*BSD). Also, an OpenSSL incompatibility that occurs *sometimes* while 
communicating with the *same* host is very unlikely...

> Otherwise,
> unfortunately, it has good chances of fading into obscurity: too
> much publicity before a stable and usable ref. implementation
> is available can be harmful.

You're right, and except announcing it on fm, we're not doing any PR work 
just for this reason. While we need a small userbase in order to find the 
rough edges and common problems, we'd look really bad if we suddenly have 
100.000 users... That's also why the site says it's a beta version. 

> See e.g. freenet, which has seen
> no end of bad press and deserting hosts, mainly because the
> system hasn't been able to deliver what it promises due to
> several implementation bugs and problems which just do not
> seem to go away.

We started GNUnet after taking a deep look into Freenet. They seem to be 
suffering from more than just a couple of bugs. Their system has serious 
design problems and very ugly code. 

> I hope gnunet will not end up in the same limbo. ;)

I absolutly agree with your concerns. If you have any further problems, 
please report & we'll do our best to fix them. :-)

Christian