DCC digest, Vol 1 #1007 - 1 msg

Vernon Schryver vjs@calcite.rhyolite.com
Tue Apr 22 06:39:53 UTC 2008

> From: William Taylor <williamt@napanet.net>

> I am having the same sort of problem. dcc just stops working all of a 
> sudden. Can't figure out why
> r 21 21:18:26 lds dccifd[9887]: continue not asking DCC 3 seconds after 
> failure

What is it that stops working, the shell script updatedcc or the
daemon dccifd's access to the public DCC servers?

> I manually upgrade to the latest version and that didn't help. I did a 
> tcpdump from my local machine and from one of the public mirrors I have 
> access to and I see traffic getting there and back. Just things aren't 
> working.
> Any ideas?

There are two common causes for not getting DCC results:

  1. a firewall that blocks responses sent by the servers from their
      UPD port 627 to the DCC client (e.g. dccifd).

  2. triggering the DoS defenses of the public DCC servers by sending
      too many requests, most often because of the use of the 3+ year
      old version of the client code redistributed by Linux repackagers.

You can check to see whether your DCC client code can hear the public
servers with `cdcc info`.  If they can't, there will be complaints about
"not answering" for all of the dozen servers that your client is trying
to use.

Judging from counts on three of the servers, a client at
is sending a few requests and NOPs typical of small tests. is also currently (April 22, 06:30 UTC) making a few tests.

A client at has sent somewhat more than 2000 requests and
perhaps 1000 NOPs.  It is using version #8 of the DCC client-server
protocol, which implies that it is not use ancient version.  Its last
request was at 02:08:40, and since then has probably sent only NOPs.
My guess is that a firewall of some sort has been blocking responses
from UDP port 6277 from at least and to
dccifd at from about 02:10 UTC.

Vernon Schryver    vjs@rhyolite.com

More information about the DCC mailing list

Contact vjs@rhyolite.com by mail or use the form.