(Answer) (Category) distributed.net Faq-O-Matic : (Category) the Client software : (Answer) Why do I keep getting network errors, or problems resolving hosts?
The most common reason is because you are located behind a firewall and the client can't get directly out to the internet. There are work arounds as described in the next section. Intermittent network errors can also occur due to poor conditions on your LAN, poor phone lines, or heavy traffic on the internet itself. There have been some problems with earlier versions of the client being overly sensitive to response times. These problems have been mostly resolved.
If you are getting "Unable to resolve..." messages from the Linux client, you may be having a compatibility problem with the "glibc" library. Prior to build v2.8008-459, distributed.net provided separate client binaries with "glibc20" and glibc21" in their file names. You had to choose the correct version in order for name resolution to work.

Starting with build v2.8008-459 of the client, there is now a single unified Linux binary (for each processor architecture type), instead of separate ones for each architecture and library combination. The name resolution incompatibilities have been worked around by using "clever" dynamic symbol loading techniques, but this didn't work very well (problems ranged from segfaults to hanging threads to simply not-working).

So, from v2.8011-463 on, the client does not even bother trying to work around the insanity introduced by glibc, and instead pipes/parses the output of 'host'. If you find that your Linux client is still reporting an error during connection attempts, it's probably because you do not have the bind tools installed on your computer. Look for a "bind-tools" binary package in whichever packaging format is appropriate for your particular flavor of linux.

More recently, starting in v2.9008-490 the Linux client is now statically compiled with ucLibc (instead of glibc) and no longer has any dependencies on the "host" utility. The only requirement is that your /etc/resolv.conf be properly configured with valid nameservers.

I noticed that (at least on Unix) a running client does not take any notice if you change DNS servers. Look out for spurious UDP packets to the old nameserver (netstat -tn), and a failure to flush buffers once the old nameserver has packed up and gone home. Restarting the client will fix this. This applies to any application that uses the ISC resolver, which only loads /etc/resolv.conf (into static storage) once.
To simply set the address manually, also solves the problem. By using nslookup or ping, I found the IP address of the name it failed to resolve. Then it was just to start the client with:

$ dnetc -a

If they change the ip address, or that server goes down, the client will fail. So I have the client running in a detached screen. And I check the output from time to time.

[Ed: This solution is not recommended.]

You can also setup dist.net to run offline, and setup a cron job to grab the IP of the keyserver and update the cache hourly. You may have to adjust the grep/sed expressions depending on your local flavor.

# script to start, stop, restart, or update cache for the dist.net client
# is dist.net client on?
distnetON=$(ps --no-headers -o %c -C dnetc)

function start() {
  # run dist.net client offline
  /usr/local/dist.net/dnetc -quiet -runoffline
  echo "Started distributed.net client"

function stop() {
  /usr/local/dist.net/dnetc -quiet -shutdown
  echo "Stopped distributed.net client"
  sleep 2

function update() {
  # ping the keyserver, grab the ip from the output, and update the caches
  /usr/local/dist.net/dnetc -quiet -update -a $(ping -n -c 1 us.v29.distributed.net | grep \( | sed -e 's/^PI.\+\.net (//g' -e 's/) fro.\+$//g')

if [ -x /usr/local/dist.net/dnetc ]; then
  case "$1" in
    # make sure that there are no clients running
    if [ "$distnetON" = "dnetc" ]; then stop; fi
    # now start it up
    if [ "$distnetON" = "dnetc" ]; then stop; fi
    if [ -e /var/smoothwall/red/active ]; then update; fi
    echo "Syntax: $0 [start|restart|update|stop]"
    exit 1
exit 0
# cron.hourly script to update the dist.net clients key server IP address

# if dist.net client not running, then start it
if [ "$(ps --no-headers -o %c -C dnetc)" != "dnetc" ]; then
        #/usr/local/dist.net/dist.net start;
        echo "not running"

# check if red interface is connected
if [ -e /var/smoothwall/red/active ]; then
        # update in/out caches
        /usr/local/dist.net/dist.net update

        # write to smoothwall log
        logger -t smoothwall "dist.net: cache updated"
exit 0

Just put the dist.net file in the directory where your dist.net client is, and adjust the paths, and it should work.

This document is: http://faq.distributed.net/?file=43
[Search] [Appearance] [Show Expert Edit Commands]
This is a Faq-O-Matic 2.721.test.

© Copyright distributed.net 1997-2013 - All rights reserved