help-gnunet
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Help-gnunet] can't seem to start gnunetd properly


From: Christian Grothoff
Subject: Re: [Help-gnunet] can't seem to start gnunetd properly
Date: Thu, 13 Jun 2002 20:44:37 -0500

On Thursday 13 June 2002 08:02 pm, you wrote:
> Hi,
>
> I don't seem to get gnunetd to work (I used the CVS version).
>
> Here is what happens:
>
> # gnunetd -u nobody -c /etc/gnunet.conf
> Configfile specified: /etc/gnunet.conf.
> Loading configuration from /etc/gnunet.conf.
> Database (GDBM): /scratch/GNUNet/data/content/
> CONNECTION: Connection module initialization
> Indexing data/content database... count: 0
> Done.
> CONNECTION: Connection module cron start with 0 hosts:
> Received -1 bytes
> ...
> Received -1 bytes
> Received 552 bytes
> Received 552 bytes
> Received 552 bytes
> Received 552 bytes
> Received 552 bytes
> Received 136 bytes
> Received -1 bytes
> ...
> Received -1 bytes
> Received 416 bytes
> Received 552 bytes
> Received 552 bytes
> Received 552 bytes
> Received 552 bytes
> Received 552 bytes
> Received 552 bytes
> Received 552 bytes
> Received 552 bytes
> Received 552 bytes
> Received 552 bytes
> Received 552 bytes
> Received 552 bytes
> Received 552 bytes
> Received 0 bytes

Until here this looks ok. gnunetd downloads a list of hosts to connect to 
initially. It should attempt to ping (UDP-GNUnet-internal ping, not ICMP) 
each of them. The ones that respond (GNUnet-pong) are added to the local list 
of 'known hosts'. Since I have seen a couple of live hosts at any given time 
for a while now, I would suspect that *if* your ping went out, you would have 
gotten a response.

> CONNECTION: Connection module cron start with 0 hosts:

> and so on for at least 20 minutes. I assume this is not normal behavior.
> (No documentation mentions this.)

No, it should have received a PONG and then connected to those hosts. Check 
your firewall (you can use it to log packets, too!) to see if you have 
outbound traffic to foreign UDP ports - and to see what comes back in. 

> I killed this process to try again, with the same results.
>
> I am using Debian GNU/Linux (2.2), openssl 0.9.4 (I patched symcipher.c
> for this to compile), gcc 2.95.2. My computer is normally behind a
> firewall but I disabled it. I know UDP ports work because talk works.

Well, gnunet only needs UDP port 2086, you can leave all other ports blocked. 

> any help will be appreciated...

My best guess is still that the connection attempts fail due to some 
networking problems. One possibility is, that your ISP firewalls UDP traffic 
(maybe just some, say not DNS for example). In that case, your best bet would 
be to wait until we also support TCP for the transport layer (will take a 
couple of weeks, though :-). If you just want to test your firewall, start 
gnunetd on two hosts locally and copy the ~/.gnunet/data/hosts file from one 
of the hosts over to the other (you may have to wait a while since the 
directory is not scanned frequently for new entries - or just restart the 
gnunetd that you manually told about the other host). If that works in the 
LAN, you know your firewall is not to blame.

Christian



reply via email to

[Prev in Thread] Current Thread [Next in Thread]