CDCC not working.

Vernon Schryver
Wed May 14 03:49:31 UTC 2003

> From: "Karl Kopp" <>

> > What was the source of the bad map file?  How did you happen to
> > have two of them so that you could replace one with the "first
> > install" version?
> I followed the intructions here:

Those instructions have errors.  Concerning the DCC:

  - it's faster to get the source from
     than try to get past all of other traffic on my puny ISDN link.

  - `tar -z` is nice, but only if your version of tar knows about -z

  - the DCC client code does not use /bin/sh.  The string
    "check failed: no response" is no only unfamiliar to me, I can't
    find it in the source.  Perhaps something in
     amavisd-new uses /bin/sh to invoke dccproc or dccifd.

  - besides allowing outbound packets to distant port 6277 through
     your firewall, you must also allow inbound packets from distant
     UDP ports.  More than one enterprise has done as these instructions
     advise, opened only the one direction, and had problems.

> 1) Compile and install dcc
> 2) Copy to chroot env
> 3) Could not get working, so compiled again 
> over top of normal (non chroot) env
> 4) Still couldn't get working
> 5) Copy first compiled map file from chroot 
> dir to normal dir
> 6) Works fine!

Didn't you adjust your firewall among those steps?

`make install` will not overwrite an existing map file.

Your first message contained a result of `cdcc info`.  
I intended `cdcc info` to be an ASCII representation of the map
file that can be archived, read by people, and so forth.  I saw
nothing bogus or corrupt in your `cdcc info` result.

I wonder if there was a combination of other problems.  For one thing,
the DCC client code expects to find the map file in the "--prefix"
or "DCC home directory."  All of that building, installing, copying,
anc chroot'ing sounds as if it could easily have produced DCC
programs that looked in the wrong places.

Note also that the DCC client code doesn't like map files that are
not private, or mode 0600, because they can contain passwords.  Perhaps
file permissions or ownership changed during the copying were the
nature of the corruption.

Vernon Schryver

More information about the DCC mailing list

Contact by mail or use the form.