|
DCC version 1.3.104/2.3.104 released
|
View:
New views
14 Messages
—
Rating Filter:
Alert me
|
 |
DCC version 1.3.104/2.3.104 released
by Vernon Schryver
::
Rate this Message:
Reply (Restricted by the Administrator) | Reply to Author | View Threaded | Show Only this Message Version 1.3.104 of the DCC source is in
http://www.dcc-servers.net/dcc/source/dcc.tar.Z and http://www.rhyolite.com/dcc/source/dcc.tar.Z Commercial version 2.3.104 of the DCC Reputation code is in the usual place. The CHANGES file starts with Fix bogus 0 second retries for DNSBL lookups in dccm, dccifd, and dccproc. Accept blocks of addresses in whitelists and elsewhere as starting and ending pairs like 10.2.3.4-10.5.6.7 as well as CIDR blocks. Reduce name space pollution for sites using dccif() in dcclib.a. Fix IPv6 ifindex bug reported by Joe Breu. Change IPv6 support to use separate sockets instead of sharing IPv4 sockets. This is necessary on FreeBSD systems with IPv4 mapped addresses in IPv6 sockets turned off. Ignore and replace settings of "IPv6 on" and "IPv6 off" in existing /var/dcc/map files with new values name "IPv6 on", "IPv6 off", and "IPv6 only". The new default of "IPv6 on" combined with distinct socket change described above should make DCC client programs including dccproc, dccifd, and dccm seamlessly use avaliable IPv6 and IPv4 DCC servers. "IPv6 only" and "IPv6 off" should not be needed but are available just in case. Ignore `dccd -6` and `dccd -4` instead of enabling IPv6. The server code now opens IPv6 and IPv4 sockets to receive requests from clients corresponding to IPv6 and IPv4 addresses on network interfaces. I think the right things happen if the DCC server has no IPv6 support and if the server has only link-local or site-local addresses. Those are substantial changes. /var/dcc/libexec/updatedcc should automagically fetch, build, and install the commercial or free version, depending on the .updatedcc_pfile file, unless you have installed a version of Linux with the broken default `sort` collating sequence since last upgrading. If so, an easy way to get the old updatedcc script working is to delete the entire /var/dcc/build/dcc directory before running updatedcc. Vernon Schryver vjs@... _______________________________________________ DCC mailing list DCC@... http://www.rhyolite.com/mailman/listinfo/dcc |
|
|
Re: DCC version 1.3.104/2.3.104 released
by Petar Bogdanovic-6
::
Rate this Message:
Reply (Restricted by the Administrator) | Reply to Author | View Threaded | Show Only this Message On Mon, May 25, 2009 at 02:50:58PM +0000, Vernon Schryver wrote:
> Version 1.3.104 of the DCC source is in > http://www.dcc-servers.net/dcc/source/dcc.tar.Z and > http://www.rhyolite.com/dcc/source/dcc.tar.Z > > Commercial version 2.3.104 of the DCC Reputation code is in the usual place. > > The CHANGES file starts with > Fix bogus 0 second retries for DNSBL lookups in dccm, dccifd, and dccproc. > Accept blocks of addresses in whitelists and elsewhere as starting > and ending pairs like 10.2.3.4-10.5.6.7 as well as CIDR blocks. > Reduce name space pollution for sites using dccif() in dcclib.a. > Fix IPv6 ifindex bug reported by Joe Breu. > Change IPv6 support to use separate sockets instead of sharing IPv4 > sockets. This is necessary on FreeBSD systems with IPv4 mapped > addresses in IPv6 sockets turned off. > Ignore and replace settings of "IPv6 on" and "IPv6 off" in existing > /var/dcc/map files with new values name "IPv6 on", "IPv6 off", and > "IPv6 only". The new default of "IPv6 on" combined with distinct > socket change described above should make DCC client programs including > dccproc, dccifd, and dccm seamlessly use avaliable IPv6 and IPv4 DCC > servers. "IPv6 only" and "IPv6 off" should not be needed but are > available just in case. Lines in map.txt beginning with `@' match 127.0.0.1 and ::1, right? 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: /var/dcc/map.txt: (...) dcc1.dcc-servers.net,- RTT+1000 ms anon # undefined name or wrong IP version (...) /var/log/maillog: (...) no working DCC servers dcc1.dcc-servers.net dcc2.dcc-servers.net dcc3.dcc-servers.net ... at 127.0.0.1 (...) 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 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? Petar Bogdanovic _______________________________________________ DCC mailing list DCC@... http://www.rhyolite.com/mailman/listinfo/dcc |
|
|
Re: DCC version 1.3.104/2.3.104 released
by Petar Bogdanovic-6
::
Rate this Message:
Reply (Restricted by the Administrator) | Reply to Author | View Threaded | Show Only this Message On Wed, May 27, 2009 at 01:43:57PM +0200, Petar Bogdanovic wrote:
> On Mon, May 25, 2009 at 02:50:58PM +0000, Vernon Schryver wrote: > > Version 1.3.104 of the DCC source is in > > http://www.dcc-servers.net/dcc/source/dcc.tar.Z and > > http://www.rhyolite.com/dcc/source/dcc.tar.Z > > > > Commercial version 2.3.104 of the DCC Reputation code is in the usual place. > > > > The CHANGES file starts with > > Fix bogus 0 second retries for DNSBL lookups in dccm, dccifd, and dccproc. > > Accept blocks of addresses in whitelists and elsewhere as starting > > and ending pairs like 10.2.3.4-10.5.6.7 as well as CIDR blocks. > > Reduce name space pollution for sites using dccif() in dcclib.a. > > Fix IPv6 ifindex bug reported by Joe Breu. > > Change IPv6 support to use separate sockets instead of sharing IPv4 > > sockets. This is necessary on FreeBSD systems with IPv4 mapped > > addresses in IPv6 sockets turned off. > > Ignore and replace settings of "IPv6 on" and "IPv6 off" in existing > > /var/dcc/map files with new values name "IPv6 on", "IPv6 off", and > > "IPv6 only". The new default of "IPv6 on" combined with distinct > > socket change described above should make DCC client programs including > > dccproc, dccifd, and dccm seamlessly use avaliable IPv6 and IPv4 DCC > > servers. "IPv6 only" and "IPv6 off" should not be needed but are > > available just in case. > > > Lines in map.txt beginning with `@' match 127.0.0.1 and ::1, right? > > 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: > > /var/dcc/map.txt: > (...) > dcc1.dcc-servers.net,- RTT+1000 ms anon > # undefined name or wrong IP version > (...) > > /var/log/maillog: > (...) > no working DCC servers dcc1.dcc-servers.net > dcc2.dcc-servers.net dcc3.dcc-servers.net ... > at 127.0.0.1 > (...) `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 dcc2.dcc-servers.net,- RTT+1000 ms anon # undefined name or wrong IP version dcc3.dcc-servers.net,- RTT+1000 ms anon # undefined name or wrong IP version dcc4.dcc-servers.net,- RTT+1000 ms anon # undefined name or wrong IP version dcc5.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.. Thanks anyway, Petar Bogdanovic _______________________________________________ DCC mailing list DCC@... http://www.rhyolite.com/mailman/listinfo/dcc |
|
|
Re: DCC version 1.3.104/2.3.104 released
by Petar Bogdanovic-6
::
Rate this Message:
Reply (Restricted by the Administrator) | Reply to Author | View Threaded | Show Only this Message On Wed, May 27, 2009 at 02:32:15PM +0200, Petar Bogdanovic wrote:
> > (...) > > 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.. 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 dccifd[329]: write(MTA socket,75): Broken pipe dccifd[329]: no DCC answer from dcc2.dcc-servers.net (203.81.36.6,6277) after 8641 ms dccifd[329]: write(MTA socket,72): Broken pipe dccifd[329]: no DCC answer from dcc4.dcc-servers.net (152.20.253.5,6277) after 13910 ms dccifd[329]: write(MTA socket,71): Broken pipe dccifd[329]: no DCC answer from dcc3.dcc-servers.net (194.228.41.73,6277) after 6050 ms dccifd[329]: write(MTA socket,71): Broken pipe I tried "IPv6 off" (since the local packet filter drops all IPv6 traffic).. IPv6 off version=3 dcc1.dcc-servers.net,- RTT+1000 ms anon # 137.208.8.26,- wuwien ID 1290 # protocol version 8 # 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 # 33% of 6 requests ok 2604.76+1000 ms RTT 100 ms queue wait dcc2.dcc-servers.net,- RTT+1000 ms anon # 195.20.8.232,- EATSERVER ID 1166 # 33% of 6 requests ok 2533.57+1000 ms RTT 100 ms queue wait # 203.81.36.6,- PacNet-SG ID 1358 # 50% of 8 requests ok 4000.00+1000 ms RTT 200 ms queue wait dcc3.dcc-servers.net,- RTT+1000 ms anon # *194.228.41.73,- CTc-dcc1 ID 1030 # protocol version 8 # 100% of 2 requests ok 135.03+1000 ms RTT 100 ms queue wait # 209.169.14.27,- x.dcc-servers ID 104 # 33% of 6 requests ok 4000.00+1000 ms RTT 100 ms queue wait dcc4.dcc-servers.net,- RTT+1000 ms anon # 152.20.253.5,- dcc.uncw.edu ID 1201 # 33% of 6 requests ok 2638.36+1000 ms RTT 100 ms queue wait # 194.228.41.13,- CTc-dcc2 ID 1031 # protocol version 8 # 100% of 2 requests ok 135.52+1000 ms RTT 100 ms queue wait dcc5.dcc-servers.net,- RTT+1000 ms anon # 209.34.225.42,- # not answering # 216.240.97.12,- dmv.com ID 1181 # protocol version 8 # 100% of 2 requests ok 211.64+1000 ms RTT 100 ms queue wait ..but no luck: dccifd[208]: no DCC answer from dcc1.dcc-servers.net (209.169.14.26,6277) after 6050 ms dccifd[208]: write(MTA socket,75): Broken pipe dccifd[208]: no DCC answer from dcc2.dcc-servers.net (203.81.36.6,6277) after 8722 ms dccifd[208]: write(MTA socket,71): Broken pipe What's wrong here? 1.3.103 still runs fine.. Petar Bogdanovic _______________________________________________ DCC mailing list DCC@... http://www.rhyolite.com/mailman/listinfo/dcc |
|
|
Re: DCC version 1.3.104/2.3.104 released
by Chris Aseltine
::
Rate this Message:
Reply (Restricted by the Administrator) | Reply to Author | View Threaded | Show Only this Message Starting in the last few days I've been getting dupes from this list, any
idea? Petar's "monologue" showed up at least twice, maybe more... On Wed, 27 May 2009, Petar Bogdanovic wrote: > > 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.. > > Sorry for the monologue but even if `cdcc RTT' re-resolves all > hostnames, I still get errors in the maillog: _______________________________________________ DCC mailing list DCC@... http://www.rhyolite.com/mailman/listinfo/dcc |
|
|
Re: DCC version 1.3.104/2.3.104 released
by Vernon Schryver
::
Rate this Message:
Reply (Restricted by the Administrator) | Reply to Author | View Threaded | Show Only this Message > From: Chris Aseltine <ophidian@...>
> Starting in the last few days I've been getting dupes from this list, any > idea? Petar's "monologue" showed up at least twice, maybe more... Sendmail's log here mentions only one copy of each message going to ophidian@.... A test mailbox at Hotmail I subscribed to the list to see how Microsoft treats List-Unsubscribe headers received only one copy. Is there any any chance that an alias or similar mechanism at newsnation.com is doubling the messages? Is anyone else seeing duplicate copies? Vernon Schryver vjs@... P.S. As usual, Microsoft didn't bother to actually read the relevant RFCs, and so they do the wrong thing with standard Mailman headers. But hacking Mailman to fit their precondeptions was easy and did not lose too much functionality. _______________________________________________ DCC mailing list DCC@... http://www.rhyolite.com/mailman/listinfo/dcc |
|
|
Re: DCC version 1.3.104/2.3.104 released
by Chris Aseltine
::
Rate this Message:
Reply (Restricted by the Administrator) | Reply to Author | View Threaded | Show Only this Message On Wed, 27 May 2009, Vernon Schryver wrote:
> Is there any any chance that an alias or similar mechanism at > newsnation.com is doubling the messages? Uhh, sorry about that. Apparently, my Comcast address is also subscribed, and I recently enabled forwarding on that address to my newsnation.com address. :( _______________________________________________ DCC mailing list DCC@... http://www.rhyolite.com/mailman/listinfo/dcc |
|
|
Re: DCC version 1.3.104/2.3.104 released
by Petar Bogdanovic-6
::
Rate this Message:
Reply (Restricted by the Administrator) | Reply to Author | View Threaded | Show Only this Message On Wed, May 27, 2009 at 02:32:43PM +0000, Vernon Schryver wrote:
> > From: Chris Aseltine <ophidian@...> > > > Starting in the last few days I've been getting dupes from this list, any > > idea? Petar's "monologue" showed up at least twice, maybe more... > > Sendmail's log here mentions only one copy of each message going to > ophidian@.... > A test mailbox at Hotmail I subscribed to the list to see how > Microsoft treats List-Unsubscribe headers received only one copy. > > Is there any any chance that an alias or similar mechanism at newsnation.com > is doubling the messages? > > Is anyone else seeing duplicate copies? No. _______________________________________________ DCC mailing list DCC@... http://www.rhyolite.com/mailman/listinfo/dcc |
|
|
Re: DCC version 1.3.104/2.3.104 released
by Petar Bogdanovic-6
::
Rate this Message:
Reply (Restricted by the Administrator) | Reply to Author | View Threaded | Show Only this Message On Wed, May 27, 2009 at 03:08:18PM +0200, Petar Bogdanovic wrote:
> On Wed, May 27, 2009 at 02:32:15PM +0200, Petar Bogdanovic wrote: > > > > (...) > > > > 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.. > > > 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 > dccifd[329]: write(MTA socket,75): Broken pipe > dccifd[329]: no DCC answer from dcc2.dcc-servers.net (203.81.36.6,6277) after 8641 ms > dccifd[329]: write(MTA socket,72): Broken pipe > dccifd[329]: no DCC answer from dcc4.dcc-servers.net (152.20.253.5,6277) after 13910 ms > dccifd[329]: write(MTA socket,71): Broken pipe > dccifd[329]: no DCC answer from dcc3.dcc-servers.net (194.228.41.73,6277) after 6050 ms > dccifd[329]: write(MTA socket,71): Broken pipe > > > I tried "IPv6 off" (since the local packet filter drops all IPv6 > traffic).. > > IPv6 off version=3 > > dcc1.dcc-servers.net,- RTT+1000 ms anon > # 137.208.8.26,- wuwien ID 1290 > # protocol version 8 > # 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 > # 33% of 6 requests ok 2604.76+1000 ms RTT 100 ms queue wait > > dcc2.dcc-servers.net,- RTT+1000 ms anon > # 195.20.8.232,- EATSERVER ID 1166 > # 33% of 6 requests ok 2533.57+1000 ms RTT 100 ms queue wait > # 203.81.36.6,- PacNet-SG ID 1358 > # 50% of 8 requests ok 4000.00+1000 ms RTT 200 ms queue wait > > dcc3.dcc-servers.net,- RTT+1000 ms anon > # *194.228.41.73,- CTc-dcc1 ID 1030 > # protocol version 8 > # 100% of 2 requests ok 135.03+1000 ms RTT 100 ms queue wait > # 209.169.14.27,- x.dcc-servers ID 104 > # 33% of 6 requests ok 4000.00+1000 ms RTT 100 ms queue wait > > dcc4.dcc-servers.net,- RTT+1000 ms anon > # 152.20.253.5,- dcc.uncw.edu ID 1201 > # 33% of 6 requests ok 2638.36+1000 ms RTT 100 ms queue wait > # 194.228.41.13,- CTc-dcc2 ID 1031 > # protocol version 8 > # 100% of 2 requests ok 135.52+1000 ms RTT 100 ms queue wait > > dcc5.dcc-servers.net,- RTT+1000 ms anon > # 209.34.225.42,- > # not answering > # 216.240.97.12,- dmv.com ID 1181 > # protocol version 8 > # 100% of 2 requests ok 211.64+1000 ms RTT 100 ms queue wait > > > ..but no luck: > > dccifd[208]: no DCC answer from dcc1.dcc-servers.net (209.169.14.26,6277) after 6050 ms > dccifd[208]: write(MTA socket,75): Broken pipe > dccifd[208]: no DCC answer from dcc2.dcc-servers.net (203.81.36.6,6277) after 8722 ms > dccifd[208]: write(MTA socket,71): Broken pipe > > > What's wrong here? 1.3.103 still runs fine.. FYI, cdcc-1.3.103 info: # cdcc info # 05/27/09 16:47:58 CEST /var/dcc/map # Re-resolve names after 17:11:44 # 1225.45 ms threshold, 1222.13 ms average 12 total, 10 working servers IPv6 off dcc1.dcc-servers.net,- RTT+1000 ms anon # 137.208.8.26,- wuwien ID 1290 # protocol version 8 # 100% of 1 requests ok 125.45+1000 ms RTT 100 ms queue wait # 209.169.14.26,- x.dcc-servers ID 104 # 100% of 1 requests ok 244.98+1000 ms RTT 100 ms queue wait # 209.169.14.29,- x.dcc-servers ID 104 # 100% of 1 requests ok 244.26+1000 ms RTT 100 ms queue wait dcc2.dcc-servers.net,- RTT+1000 ms anon # *195.20.8.232,- EATSERVER ID 1166 # 100% of 13 requests ok 123.01+1000 ms RTT 100 ms queue wait # 203.81.36.6,- PacNet-SG ID 1358 # 100% of 2 requests ok 619.84+1000 ms RTT 200 ms queue wait dcc3.dcc-servers.net,- RTT+1000 ms anon # 194.228.41.73,- CTc-dcc1 ID 1030 # protocol version 8 # 100% of 1 requests ok 135.40+1000 ms RTT 100 ms queue wait # 209.169.14.27,- x.dcc-servers ID 104 # 100% of 1 requests ok 244.91+1000 ms RTT 100 ms queue wait dcc4.dcc-servers.net,- RTT+1000 ms anon # 152.20.253.5,- dcc.uncw.edu ID 1201 # 100% of 1 requests ok 227.51+1000 ms RTT 100 ms queue wait # 194.228.41.13,- CTc-dcc2 ID 1031 # protocol version 8 # 100% of 1 requests ok 135.43+1000 ms RTT 100 ms queue wait dcc5.dcc-servers.net,- RTT+1000 ms anon # 209.34.225.42,- # not answering # 216.240.97.12,- dmv.com ID 1181 # protocol version 8 # 100% of 1 requests ok 213.90+1000 ms RTT 100 ms queue wait No failed requests, much lower RTTs. _______________________________________________ DCC mailing list DCC@... http://www.rhyolite.com/mailman/listinfo/dcc |
|
|
Re: DCC version 1.3.104/2.3.104 released
by Vernon Schryver
::
Rate this Message:
Reply (Restricted by the Administrator) | Reply to Author | View Threaded | Show Only this Message > From: Petar Bogdanovic <petar@...>
> 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. > 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@...> ] `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@...> } 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. } 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. } 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. } # 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? 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@... _______________________________________________ DCC mailing list DCC@... http://www.rhyolite.com/mailman/listinfo/dcc |
|
|
Re: DCC version 1.3.104/2.3.104 released
by Petar Bogdanovic-6
::
Rate this Message:
Reply (Restricted by the Administrator) | Reply to Author | View Threaded | Show Only this Message On Wed, May 27, 2009 at 08:02:32PM +0000, Vernon Schryver wrote:
> > From: Petar Bogdanovic <petar@...> > > > 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@...> > > ] `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@...> > > } 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 _______________________________________________ DCC mailing list DCC@... http://www.rhyolite.com/mailman/listinfo/dcc |
|
|
Re: DCC version 1.3.104/2.3.104 released
by Petar Bogdanovic-6
::
Rate this Message:
Reply (Restricted by the Administrator) | Reply to Author | View Threaded | Show Only this Message On Wed, May 27, 2009 at 10:54:22PM +0200, Petar Bogdanovic wrote:
> On Wed, May 27, 2009 at 08:02:32PM +0000, Vernon Schryver wrote: > > 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. Lets begin with `re-resolve on first use' vs. `cdcc rtt'. map contains names which were not resolved during the initial installation (due to lack of DNS): # spamassassin -D <gtube.txt 2>&1 | grep -i dcc (...) [669] dbg: dcc: dccifd is available: /var/dcc/dccifd [669] dbg: dcc: dccifd got response: X-DCC--Metrics: MYHOST 0; Body=1 Fuz1=1 Fuz2=1 # grep dcc /var/log/maillog dccifd[501]: 1.3.104 listening to /var/dcc/dccifd for ASCII protocol dccifd[501]: no working DCC servers dcc1.dcc-servers.net dcc2.dcc-servers.net dcc3.dcc-servers.net ... at 127.0.0.1 dccifd[501]: continue not asking DCC 124 seconds after failure Ok, lets wait. # cdcc info # 05/27/09 23:32:28 CEST /var/dcc/map # Re-resolve names after 01:23:53 Check RTTs after 23:38:53 # 1 total, 0 working servers # skipping asking DCC server 4 seconds more Only 4 more seconds.. # cdcc info # 05/27/09 23:32:36 CEST /var/dcc/map # Re-resolve names after 01:23:53 Check RTTs after 23:38:53 # 1 total, 0 working servers Ready? Lets try. # spamassassin -D <gtube.txt 2>&1 | grep -i dcc (...) [669] dbg: dcc: dccifd is available: /var/dcc/dccifd [669] dbg: dcc: dccifd got response: X-DCC--Metrics: MYHOST 0; Body=1 Fuz1=1 Fuz2=1 # cdcc info # 05/27/09 23:32:46 CEST /var/dcc/map # Re-resolve names after 01:23:53 Check RTTs after 23:38:53 # 1 total, 0 working servers # skipping asking DCC server 508 seconds more Not really. # cdcc rtt # 05/27/09 23:35:42 CEST /var/dcc/map # Re-resolve names after 01:35:37 Check RTTs after 23:50:42 # 1347.14 ms threshold, 1222.97 ms average 12 total, 10 working servers IPv6 on version=3 dcc1.dcc-servers.net,- RTT+1000 ms anon # 137.208.8.26,- wuwien ID 1290 # protocol version 8 # 100% of 3 requests ok 1031.91+1000 ms RTT 100 ms queue wait # 209.169.14.26,- x.dcc-servers ID 104 # 100% of 1 requests ok 322.07+1000 ms RTT 100 ms queue wait # 209.169.14.29,- x.dcc-servers ID 104 # 100% of 1 requests ok 321.08+1000 ms RTT 100 ms queue wait dcc2.dcc-servers.net,- RTT+1000 ms anon # *195.20.8.232,- EATSERVER ID 1166 # 100% of 1 requests ok 122.97+1000 ms RTT 100 ms queue wait # 203.81.36.6,- PacNet-SG ID 1358 # 100% of 2 requests ok 569.62+1000 ms RTT 200 ms queue wait dcc3.dcc-servers.net,- RTT+1000 ms anon # 194.228.41.73,- CTc-dcc1 ID 1030 # protocol version 8 # 100% of 1 requests ok 134.76+1000 ms RTT 100 ms queue wait # 209.169.14.27,- x.dcc-servers ID 104 # 100% of 1 requests ok 322.75+1000 ms RTT 100 ms queue wait dcc4.dcc-servers.net,- RTT+1000 ms anon # 152.20.253.5,- dcc.uncw.edu ID 1201 # 100% of 1 requests ok 247.14+1000 ms RTT 100 ms queue wait # 194.228.41.13,- CTc-dcc2 ID 1031 # protocol version 8 # 100% of 1 requests ok 135.25+1000 ms RTT 100 ms queue wait dcc5.dcc-servers.net,- RTT+1000 ms anon # 209.34.225.42,- # not answering # 216.240.97.12,- dmv.com ID 1181 # protocol version 8 # 100% of 1 requests ok 211.29+1000 ms RTT 100 ms queue wait All right, thats better. Lets retry SpamAssassin. # spamassassin -D <gtube.txt 2>&1 | grep -i dcc (...) [554] dbg: dcc: dccifd is available: /var/dcc/dccifd [554] dbg: dcc: dccifd check timed out after 8 secs. # grep dcc /var/log/maillog dccifd[501]: no DCC answer from dcc4.dcc-servers.net (152.20.253.5,6277) after 6050 ms dccifd[501]: write(MTA socket,76): Broken pipe As expected. Lets run SpamAssassin a couple of times. # for i in $(seq 1 100); do spamassassin -D <gtube.txt 2>&1 | grep -i dcc; done (...) Minutes later.. # cdcc info # 05/27/09 23:42:52 CEST /var/dcc/map # Re-resolve names after 01:35:37 Check RTTs after 23:50:42 # 8000.00 ms threshold, 1222.97 ms average 12 total, 10 working servers IPv6 on version=3 dcc1.dcc-servers.net,- RTT+1000 ms anon # 137.208.8.26,- wuwien ID 1290 # protocol version 8 # 27% of 11 requests ok 4000.00+1000 ms RTT 100 ms queue wait # 209.169.14.26,- x.dcc-servers ID 104 # 20% of 5 requests ok 4000.00+1000 ms RTT 100 ms queue wait # 209.169.14.29,- x.dcc-servers ID 104 # 20% of 5 requests ok 4000.00+1000 ms RTT 100 ms queue wait dcc2.dcc-servers.net,- RTT+1000 ms anon # 195.20.8.232,- EATSERVER ID 1166 # 8% of 13 requests ok 4000.00+1000 ms RTT 100 ms queue wait # 203.81.36.6,- PacNet-SG ID 1358 # 33% of 6 requests ok 4000.00+1000 ms RTT 200 ms queue wait dcc3.dcc-servers.net,- RTT+1000 ms anon # 194.228.41.73,- CTc-dcc1 ID 1030 # protocol version 8 # 8% of 13 requests ok 4000.00+1000 ms RTT 100 ms queue wait # 209.169.14.27,- x.dcc-servers ID 104 # 20% of 5 requests ok 4000.00+1000 ms RTT 100 ms queue wait dcc4.dcc-servers.net,- RTT+1000 ms anon # 152.20.253.5,- dcc.uncw.edu ID 1201 # 8% of 13 requests ok 4000.00+1000 ms RTT 100 ms queue wait # 194.228.41.13,- CTc-dcc2 ID 1031 # protocol version 8 # 8% of 13 requests ok 4000.00+1000 ms RTT 100 ms queue wait dcc5.dcc-servers.net,- RTT+1000 ms anon # 209.34.225.42,- # not answering # 216.240.97.12,- dmv.com ID 1181 # protocol version 8 # 8% of 13 requests ok 4000.00+1000 ms RTT 100 ms queue wait It seems that I don't get any answers at all. Lets tcpdump one session. # spamassassin -D <gtube.txt 2>&1 | grep -i dcc (...) [1047] dbg: dcc: dccifd is available: /var/dcc/dccifd [1047] dbg: dcc: dccifd check timed out after 8 secs. # tcpdump -vvvv -i rtk0 udp port 6277 tcpdump: listening on rtk0, link-type EN10MB (Ethernet), capture size 96 bytes 23:50:10.094242 IP (... length: 180) MYHOST.65500 > dcc-1.eatserver.nl.6277: UDP, length: 152 23:50:10.217154 IP (... length: 116) dcc-1.eatserver.nl.6277 > MYHOST.65500: UDP, length: 88 23:50:10.444220 IP (... length: 180) MYHOST.65500 > dcc-1.eatserver.nl.6277: UDP, length: 152 23:50:10.569212 IP (... length: 116) dcc-1.eatserver.nl.6277 > MYHOST.65500: UDP, length: 88 23:50:11.044208 IP (... length: 180) MYHOST.65500 > dcc-1.eatserver.nl.6277: UDP, length: 152 23:50:11.165145 IP (... length: 116) dcc-1.eatserver.nl.6277 > MYHOST.65500: UDP, length: 88 23:50:12.144210 IP (... length: 180) MYHOST.65500 > dcc-1.eatserver.nl.6277: UDP, length: 152 23:50:12.265192 IP (... length: 116) dcc-1.eatserver.nl.6277 > MYHOST.65500: UDP, length: 88 23:50:16.144244 IP (... length: 180) MYHOST.65500 > h4-vjs.colo.indra.com.6277: UDP, length: 152 23:50:16.374800 IP (... length: 116) h4-vjs.colo.indra.com.6277 > MYHOST.65500: UDP, length: 88 23:50:16.494252 IP (... length: 180) MYHOST.65500 > h4-vjs.colo.indra.com.6277: UDP, length: 152 23:50:16.726501 IP (... length: 116) h4-vjs.colo.indra.com.6277 > MYHOST.65500: UDP, length: 88 23:50:17.094246 IP (... length: 180) MYHOST.65500 > h4-vjs.colo.indra.com.6277: UDP, length: 152 23:50:17.352498 IP (... length: 116) h4-vjs.colo.indra.com.6277 > MYHOST.65500: UDP, length: 88 23:50:18.194257 IP (... length: 180) MYHOST.65500 > h4-vjs.colo.indra.com.6277: UDP, length: 152 23:50:18.447587 IP (... length: 116) h4-vjs.colo.indra.com.6277 > MYHOST.65500: UDP, length: 88 I can't really read that output but it seems to me that I'm actually getting an answer every time I'm asking for one. Lets see (log) what ipfilter sees. pass out log proto udp from any to any port = 6277 keep state # DCC ^^^ ipmon[317]: 23:54:09.999847 rtk0 @0:16 p MYHOST,65500 -> 209.169.14.27,6277 PR udp len 20 180 K-S OUT ipmon[317]: 23:54:10.237437 rtk0 @0:16 p 209.169.14.27,6277 -> MYHOST,65500 PR udp len 20 116 K-S IN ipmon[317]: 23:54:10.349835 rtk0 @0:16 p MYHOST,65500 -> 209.169.14.27,6277 PR udp len 20 180 K-S OUT ipmon[317]: 23:54:10.583213 rtk0 @0:16 p 209.169.14.27,6277 -> MYHOST,65500 PR udp len 20 116 K-S IN ipmon[317]: 23:54:10.949831 rtk0 @0:16 p MYHOST,65500 -> 209.169.14.27,6277 PR udp len 20 180 K-S OUT ipmon[317]: 23:54:11.180647 rtk0 @0:16 p 209.169.14.27,6277 -> MYHOST,65500 PR udp len 20 116 K-S IN ipmon[317]: 23:54:12.049829 rtk0 @0:16 p MYHOST,65500 -> 209.169.14.27,6277 PR udp len 20 180 K-S OUT ipmon[317]: 23:54:12.278444 rtk0 @0:16 p 209.169.14.27,6277 -> MYHOST,65500 PR udp len 20 116 K-S IN ipmon[317]: 23:54:16.049879 rtk0 @0:16 p MYHOST,65500 -> 203.81.36.6,6277 PR udp len 20 180 K-S OUT ipmon[317]: 23:54:16.619082 rtk0 @0:16 p 203.81.36.6,6277 -> MYHOST,65500 PR udp len 20 116 K-S IN ipmon[317]: 23:54:16.719552 rtk0 @0:16 p MYHOST,65500 -> 203.81.36.6,6277 PR udp len 20 180 K-S OUT ipmon[317]: 23:54:17.288365 rtk0 @0:16 p 203.81.36.6,6277 -> MYHOST,65500 PR udp len 20 116 K-S IN ipmon[317]: 23:54:17.958900 rtk0 @0:16 p MYHOST,65500 -> 203.81.36.6,6277 PR udp len 20 180 K-S OUT ipmon[317]: 23:54:18.527800 rtk0 @0:16 p 203.81.36.6,6277 -> MYHOST,65500 PR udp len 20 116 K-S IN ipmon[317]: 23:54:20.337624 rtk0 @0:16 p MYHOST,65500 -> 203.81.36.6,6277 PR udp len 20 180 K-S OUT ipmon[317]: 23:54:20.906424 rtk0 @0:16 p 203.81.36.6,6277 -> MYHOST,65500 PR udp len 20 116 K-S IN Again, this just seems good to *me*. Why am I using SpamAssassin anyway? Lets try dccproc a couple of times. # for i in $(seq 1 100); do dccproc <gtube.txt | grep -i dcc; done no DCC answer from dcc2.dcc-servers.net (195.20.8.232,6277) after 15838 ms X-DCC--Metrics: MYHOST 0; Body=1 Fuz1=1 Fuz2=1 no DCC answer from dcc1.dcc-servers.net (209.169.14.29,6277) after 15882 ms X-DCC--Metrics: MYHOST 0; Body=1 Fuz1=1 Fuz2=1 no DCC answer from dcc4.dcc-servers.net (152.20.253.5,6277) after 15882 ms X-DCC--Metrics: MYHOST 0; Body=1 Fuz1=1 Fuz2=1 no DCC answer from dcc1.dcc-servers.net (209.169.14.26,6277) after 16000 ms X-DCC--Metrics: MYHOST 0; Body=1 Fuz1=1 Fuz2=1 no DCC answer from dcc3.dcc-servers.net (209.169.14.27,6277) after 15883 ms X-DCC--Metrics: MYHOST 0; Body=1 Fuz1=1 Fuz2=1 no DCC answer from dcc1.dcc-servers.net (137.208.8.26,6277) after 15840 ms X-DCC--Metrics: MYHOST 0; Body=1 Fuz1=1 Fuz2=1 no DCC answer from dcc4.dcc-servers.net (194.228.41.13,6277) after 15844 ms X-DCC--Metrics: MYHOST 0; Body=1 Fuz1=1 Fuz2=1 no DCC answer from dcc5.dcc-servers.net (216.240.97.12,6277) after 15875 ms X-DCC--Metrics: MYHOST 0; Body=1 Fuz1=1 Fuz2=1 no DCC answer from dcc3.dcc-servers.net (194.228.41.73,6277) after 15974 ms X-DCC--Metrics: MYHOST 0; Body=1 Fuz1=1 Fuz2=1 continue not asking DCC 64 seconds after failure X-DCC--Metrics: MYHOST 0; Body=1 Fuz1=1 Fuz2=1 continue not asking DCC 64 seconds after failure X-DCC--Metrics: MYHOST 0; Body=1 Fuz1=1 Fuz2=1 continue not asking DCC 64 seconds after failure (...) That's all I have for now. And I don't get it. As soon as I replace 1.3.104 with 1.3.103 all this suddenly works. Petar Bogdanovic _______________________________________________ DCC mailing list DCC@... http://www.rhyolite.com/mailman/listinfo/dcc |
|
|
Re: DCC version 1.3.104/2.3.104 released
by Vernon Schryver
::
Rate this Message:
Reply (Restricted by the Administrator) | Reply to Author | View Threaded | Show Only this Message I think I've found the problem. It affects systems with IPv6 support,
without IPv6 Internet connectivity, and either lack the poll() system call or are NetBSD. Version 1.3.105 of the DCC source is in http://www.dcc-servers.net/dcc/source/dcc.tar.Z and http://www.rhyolite.com/dcc/source/dcc.tar.Z Commercial version 2.3.105 of the DCC Reputation code is in the usual place. thanks, Vernon Schryver vjs@... _______________________________________________ DCC mailing list DCC@... http://www.rhyolite.com/mailman/listinfo/dcc |
|
|
Re: DCC version 1.3.104/2.3.104 released
by Petar Bogdanovic-6
::
Rate this Message:
Reply (Restricted by the Administrator) | Reply to Author | View Threaded | Show Only this Message On Thu, May 28, 2009 at 02:07:24AM +0000, Vernon Schryver wrote:
> I think I've found the problem. It affects systems with IPv6 support, > without IPv6 Internet connectivity, and either lack the poll() system > call or are NetBSD. > > Version 1.3.105 of the DCC source is in > http://www.dcc-servers.net/dcc/source/dcc.tar.Z and > http://www.rhyolite.com/dcc/source/dcc.tar.Z > Commercial version 2.3.105 of the DCC Reputation code is in the usual place. # cdcc info # Re-resolve names after 13:15:34 Check RTTs after 11:30:34 # 1 total, 0 working servers # skipping asking DCC server 43 seconds more # dccproc <gtube no working DCC servers dcc1.dcc-servers.net dcc2.dcc-servers.net dcc3.dcc-servers.net ... at 127.0.0.1 # dccproc <gtube continue not asking DCC 55 seconds after failure # dccproc <gtube continue not asking DCC 9 seconds after failure # dccproc <gtube continue not asking DCC 1 seconds after failure # dccproc <gtube no working DCC servers dcc1.dcc-servers.net dcc2.dcc-servers.net dcc3.dcc-servers.net ... at 127.0.0.1 # cdcc rtt # 05/28/09 11:27:01 CEST /var/dcc/map # Re-resolve names after 13:26:57 Check RTTs after 11:42:01 # 1328.10 ms threshold, 1212.58 ms average 12 total, 10 working servers # 496 dccproc balance since 11:26:51 IPv6 on version=3 dcc1.dcc-servers.net,- RTT+1000 ms anon # 137.208.8.26,- wuwien ID 1290 # protocol version 8 # 100% of 2 requests ok 640.16+1000 ms RTT 100 ms queue wait # 209.169.14.26,- x.dcc-servers ID 104 # 100% of 1 requests ok 228.49+1000 ms RTT 100 ms queue wait # 209.169.14.29,- x.dcc-servers ID 104 # 100% of 1 requests ok 228.10+1000 ms RTT 100 ms queue wait dcc2.dcc-servers.net,- RTT+1000 ms anon # *195.20.8.232,- EATSERVER ID 1166 # 100% of 1 requests ok 112.58+1000 ms RTT 100 ms queue wait # 203.81.36.6,- PacNet-SG ID 1358 # 100% of 2 requests ok 567.34+1000 ms RTT 200 ms queue wait dcc3.dcc-servers.net,- RTT+1000 ms anon # 194.228.41.73,- CTc-dcc1 ID 1030 # protocol version 8 # 100% of 1 requests ok 135.21+1000 ms RTT 100 ms queue wait # 209.169.14.27,- x.dcc-servers ID 104 # 100% of 1 requests ok 230.05+1000 ms RTT 100 ms queue wait dcc4.dcc-servers.net,- RTT+1000 ms anon # 152.20.253.5,- dcc.uncw.edu ID 1201 # 100% of 1 requests ok 301.63+1000 ms RTT 100 ms queue wait # 194.228.41.13,- CTc-dcc2 ID 1031 # protocol version 8 # 100% of 1 requests ok 135.48+1000 ms RTT 100 ms queue wait dcc5.dcc-servers.net,- RTT+1000 ms anon # 209.34.225.42,- # not answering # 216.240.97.12,- dmv.com ID 1181 # protocol version 8 # 100% of 1 requests ok 209.22+1000 ms RTT 100 ms queue wait # for i in $(seq 1 100); do dccproc <gtube | grep -i dcc; done X-DCC-EATSERVER-Metrics: MYHOST 1166; Body=9929 Fuz1=9929 Fuz2=many X-DCC-EATSERVER-Metrics: MYHOST 1166; Body=9930 Fuz1=9930 Fuz2=many X-DCC-EATSERVER-Metrics: MYHOST 1166; Body=9931 Fuz1=9931 Fuz2=many (...) # cdcc info # 05/28/09 11:28:00 CEST /var/dcc/map # Re-resolve names after 13:26:57 Check RTTs after 11:42:01 # 1328.10 ms threshold, 1212.58 ms average 12 total, 10 working servers # 401 dccproc balance since 11:27:56 IPv6 on version=3 dcc1.dcc-servers.net,- RTT+1000 ms anon # 137.208.8.26,- wuwien ID 1290 # protocol version 8 # 100% of 2 requests ok 640.16+1000 ms RTT 100 ms queue wait # 209.169.14.26,- x.dcc-servers ID 104 # 100% of 1 requests ok 228.49+1000 ms RTT 100 ms queue wait # 209.169.14.29,- x.dcc-servers ID 104 # 100% of 1 requests ok 228.10+1000 ms RTT 100 ms queue wait dcc2.dcc-servers.net,- RTT+1000 ms anon # *195.20.8.232,- EATSERVER ID 1166 # 100% of 32 requests ok 114.18+1000 ms RTT 100 ms queue wait # 203.81.36.6,- PacNet-SG ID 1358 # 100% of 2 requests ok 567.34+1000 ms RTT 200 ms queue wait dcc3.dcc-servers.net,- RTT+1000 ms anon # 194.228.41.73,- CTc-dcc1 ID 1030 # protocol version 8 # 100% of 1 requests ok 135.21+1000 ms RTT 100 ms queue wait # 209.169.14.27,- x.dcc-servers ID 104 # 100% of 1 requests ok 230.05+1000 ms RTT 100 ms queue wait dcc4.dcc-servers.net,- RTT+1000 ms anon # 152.20.253.5,- dcc.uncw.edu ID 1201 # 100% of 1 requests ok 301.63+1000 ms RTT 100 ms queue wait # 194.228.41.13,- CTc-dcc2 ID 1031 # protocol version 8 # 100% of 1 requests ok 135.48+1000 ms RTT 100 ms queue wait dcc5.dcc-servers.net,- RTT+1000 ms anon # 209.34.225.42,- # not answering # 216.240.97.12,- dmv.com ID 1181 # protocol version 8 # 100% of 1 requests ok 209.22+1000 ms RTT 100 ms queue wait Good work, thank you! Petar Bogdanovic _______________________________________________ DCC mailing list DCC@... http://www.rhyolite.com/mailman/listinfo/dcc |
| Free embeddable forum powered by Nabble | Forum Help |
