DCC version 1.3.104/2.3.104 released

Petar Bogdanovic petar@smokva.net
Wed May 27 20:54:22 UTC 2009


On Wed, May 27, 2009 at 08:02:32PM +0000, Vernon Schryver wrote:
> > From: Petar Bogdanovic <petar@smokva.net>
> 
> > Lines in map.txt beginning with `@' match 127.0.0.1 and ::1, right?
> 
> yes, "@" is a kludge that is resolved to 127.0.0.1 and/or ::1 depending
> on whether the system seems to understand IPv4, IPv6, or both.

Ok.


> > 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).

Never mind.  It works, 1.3.104 just needs some time to re-resolve the
hostnames which were previously unresolvable.


> > 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.

Did you mean ``*or* at least 5 minutes later''?

Otherwise this pretty much explains why I didn't take notice while using
dcc <= 1.3.103.


> ] 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?

It's not, I just didn't know. :)


> Why not arrange to have working DNS service?

DNS is just absent during the installation.  As soon as we run dccifd
for the first time, DNS is available again.


> } 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 (209.169.14.26,6277) after 6050 ms
> 
> That says that the DCC server at 209.169.14.26 was not heard from
> after 6 seconds.  That sounds unrelated to DNS problems.

You're right.  The DNS problem above probably has nothing to do with the
weird network problems we're seeing here..


> } 	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 209.169.14.26.

Ok.


> } I tried "IPv6 off" (since the local packet filter drops all IPv6
> } traffic)..
> 
> 209.169.14.26 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.

Ok.


> } 	#     100% of  4 requests ok  667.04+1000 ms RTT       100 ms queue wait
> } 	#  209.169.14.26,-                                     x.dcc-servers ID 104
> } 	#      33% of  6 requests ok 2604.78+1000 ms RTT       100 ms queue wait
> } 	#  209.169.14.29,-                                     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?

Yes.


> Are there any differences in firewalls?

No.  We use a custom upgrade system where we're able to track all
possible changes in git.  Therefore it's pretty safe to assume that
the only files that have changed are the dcc files.


> Any oddities from virtualization?

No.  netbsd-4 on raw hardware.


> Does snooping with tcpdump or ethereal show that the DCC requests are
> going out?  Being answered?

I'll try 1.3.104 again today or during the next few days, check the
traffic with tcpdump and report back.


Thanks for the help so far.



   Petar Bogdanovic






More information about the DCC mailing list

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