DCC version 1.3.104/2.3.104 released

Vernon Schryver vjs@calcite.rhyolite.com
Wed May 27 20:02:32 UTC 2009

> From: Petar Bogdanovic <petar@smokva.net>

> Lines in map.txt beginning with `@' match and ::1, right?

yes, "@" is a kludge that is resolved to and/or ::1 depending
on whether the system seems to understand IPv4, IPv6, or both.

> Also, when creating a map out of a map.txt (load map.txt) in a chrooted,
> network-less environment (w/o resolv.conf), cdcc-1.3.104 seems to mark
> all hostnames in map.txt as invalid (or unresolvable) and doesn't retry
> them even if DNS/network is available again:

> This wasn't a problem with cdcc-1.3.103.  It printed an error, but
> seemed to work when DNS/network was available again:
> 	# cdcc -qh/var/dcc "new map; load map.txt"
> 	dcc1.dcc-servers.net: No address associated with hostname

How does it not work?  I just tried loading a map file with bad DNS
names.  There were error messages, but the names were copied to the
map file and cdcc quit an exit status of 0 (success).

> I checked man cdcc but there is no such thing as `load -noresolv'.  Is
> there a way to solve this without reissuing `cdcc "load map.txt"' when
> DNS/network is available?

The old DCC client code re-resolve names whenever the DCC servers 
seemed to not answer.  That generates unnecessary DNS traffic.
Version 1.3.104 routinely re-resolves server names every 2 hours.
If no IP addresses were found the last time, it re-resolves on the
next use of the /var/dcc/map file at least 5 minutes later.
`cdcc rtt` forces an immediate resolution.

] From: Petar Bogdanovic <petar@smokva.net>

] `cdcc info' with a ``broken'' map on a host with network:
] 	# 05/27/09 14:16:27 CEST  /var/dcc/map
] 	# Re-resolve names after 16:04:27  Check RTTs after 14:19:27
] 	# 1 total, 0 working servers
] 	# skipping asking DCC server 62 seconds more
] 	IPv6 on   version=3
] 	dcc1.dcc-servers.net,-      RTT+1000 ms  anon
] 	#   undefined name or wrong IP version
] ...

] Ok, makes sense.  He'll retry on 16:04:27.  `cdcc RTT' will trigger the
] re-resolve immediately, so I'll run that from somewhere..

If the next use of the /var/dcc/map file by dccifd, dccproc, or dccm
has access to the Internet, why is `cdcc rtt` needed?

Why not arrange to have working DNS service?

} From: Petar Bogdanovic <petar@smokva.net>

} Sorry for the monologue but even if `cdcc RTT' re-resolves all
} hostnames, I still get errors in the maillog:
} 	dccifd[329]: no DCC answer from dcc1.dcc-servers.net (,6277) after 6050 ms

That says that the DCC server at was not heard from
after 6 seconds.  That sounds unrelated to DNS problems.

} 	dccifd[329]: write(MTA socket,75): Broken pipe

That says that the MTA (perhaps SpamAssassin) gave up and stopped waiting
while dccifd was waiting for an answer from

} I tried "IPv6 off" (since the local packet filter drops all IPv6
} traffic).. is an IPv4 address.  Dccifd should not have tried any
IPv6 addresses.  Judging from the `cdcc info` output, the DCC client
code has noticed that the system does not have IPv6 suppport (including
a working IPv6 interface on better than a site- or link-local network)
and so is ignoring the two public DCC server IPv6 addresses.

} 	#     100% of  4 requests ok  667.04+1000 ms RTT       100 ms queue wait
} 	#,-                                     x.dcc-servers ID 104
} 	#      33% of  6 requests ok 2604.78+1000 ms RTT       100 ms queue wait
} 	#,-                                     x.dcc-servers ID 104

It looks as if access to the IPv4 Internet is dicey.

} > What's wrong here?  1.3.103 still runs fine..
} FYI, cdcc-1.3.103 info:

} No failed requests, much lower RTTs.

Is the 1.3.103 installation on the same computer?
Are there any differences in firewalls?
Any oddities from virtualization?
Does snooping with tcpdump or ethereal show that the DCC requests are
going out?  Being answered?

Vernon Schryver    vjs@rhyolite.com

More information about the DCC mailing list

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