|
View:
New views
6 Messages
—
Rating Filter:
Alert me
|
|
|
|
|
|
Re: DCC digest, Vol 1 #1007 - 1 msg
by Vernon Schryver
::
Rate this Message:
Reply (Restricted by the Administrator) | Reply to Author | View Threaded | Show Only this Message > From: PeakPeak Customer Service <support@...>
> I'm getting this after a few seconds: > > # /var/dcc/libexec/updatedcc > stopping; please wait > # > > Just quits. Are there any clues from debugging, which can be turned on with /var/dcc/libexec/updatedcc -x Vernon Schryver vjs@... _______________________________________________ DCC mailing list DCC@... http://www.rhyolite.com/mailman/listinfo/dcc |
|
|
Re: DCC digest, Vol 1 #1007 - 1 msg
by Vernon Schryver
::
Rate this Message:
Reply (Restricted by the Administrator) | Reply to Author | View Threaded | Show Only this Message > From: PeakPeak Customer Service <support@...>
> I'm getting this after a few seconds: > > # /var/dcc/libexec/updatedcc > stopping; please wait > # > > Just quits. I've released version 1.3.90 which I hope fixes that problem. Updatedcc failed after shutting down the localhost DCC server and finding no working server and when the environment variable DCC_UPDATEDCC_FAST is not set to "yes". The easiest work-around is to add the public DCC servers to the local /var/dcc/map file with `cdcc "add dcc1.dcc-servers.net RTT+1000 ms"` Besides working around the updatedcc problem, that uses the public DCC servers as backups for the local server. Vernon Schryver vjs@... _______________________________________________ DCC mailing list DCC@... http://www.rhyolite.com/mailman/listinfo/dcc |
|
|
Re: DCC digest, Vol 1 #1007 - 1 msg
by William Taylor-4
::
Rate this Message:
Reply (Restricted by the Administrator) | Reply to Author | View Threaded | Show Only this Message Vernon Schryver wrote:
>> From: PeakPeak Customer Service <support@...> >> > > >> I'm getting this after a few seconds: >> >> # /var/dcc/libexec/updatedcc >> stopping; please wait >> # >> >> Just quits. >> > > I've released version 1.3.90 which I hope fixes that problem. > > Updatedcc failed after shutting down the localhost DCC server and > finding no working server and when the environment variable > DCC_UPDATEDCC_FAST is not set to "yes". The easiest work-around > is to add the public DCC servers to the local /var/dcc/map file > with `cdcc "add dcc1.dcc-servers.net RTT+1000 ms"` Besides working > around the updatedcc problem, that uses the public DCC servers > as backups for the local server. > > > Vernon Schryver vjs@... > _______________________________________________ > DCC mailing list DCC@... > http://www.rhyolite.com/mailman/listinfo/dcc > > sudden. Can't figure out why r 21 21:18:26 lds dccifd[9887]: continue not asking DCC 3 seconds after failure Apr 21 21:18:27 lds dccifd[9887]: continue not asking DCC 2 seconds after failure Apr 21 21:18:27 lds dccifd[9887]: continue not asking DCC 2 seconds after failure Apr 21 21:18:27 lds dccifd[9887]: continue not asking DCC 2 seconds after failure Apr 21 21:18:29 lds dccifd[9887]: no working DCC serversdcc1.dcc-servers.net dcc2.dcc-servers.net dcc3.dcc-servers.net ... at 194.228.41.73 192.135.10.19 Apr 21 21:18:29 lds dccifd[9887]: no working DCC serversdcc1.dcc-servers.net dcc2.dcc-servers.net dcc3.dcc-servers.net ... at 194.228.41.73 192.135.10.19 Apr 21 21:18:29 lds dccifd[9887]: no working DCC serversdcc1.dcc-servers.net dcc2.dcc-servers.net dcc3.dcc-servers.net ... at 194.228.41.73 192.135.10.19 Apr 21 21:18:29 lds dccifd[9887]: no working DCC serversdcc1.dcc-servers.net dcc2.dcc-servers.net dcc3.dcc-servers.net ... at 194.228.41.73 192.135.10.19 [root@lds dcc]# cdcc stats no working DCC serversdcc1.dcc-servers.net dcc2.dcc-servers.net dcc3.dcc-servers.net ... at 194.228.41.73 192.135.10.19 ? 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? Thanks, William _______________________________________________ DCC mailing list DCC@... http://www.rhyolite.com/mailman/listinfo/dcc |
|
|
Re: DCC digest, Vol 1 #1007 - 1 msg
by Vernon Schryver
::
Rate this Message:
Reply (Restricted by the Administrator) | Reply to Author | View Threaded | Show Only this Message > From: William Taylor <williamt@...>
> 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 206.81.96.54 is sending a few requests and NOPs typical of small tests. 206.81.97.109 is also currently (April 22, 06:30 UTC) making a few tests. A client at 206.81.96.33 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 64.124.52.0/24 and 209.169.14.0/24 to dccifd at 206.81.96.33 from about 02:10 UTC. Vernon Schryver vjs@... _______________________________________________ DCC mailing list DCC@... http://www.rhyolite.com/mailman/listinfo/dcc |
|
|
Re: DCC digest, Vol 1 #1007 - 1 msg
by William Taylor-4
::
Rate this Message:
Reply (Restricted by the Administrator) | Reply to Author | View Threaded | Show Only this Message Vernon Schryver wrote:
>> From: William Taylor <williamt@...> >> > > >> 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 206.81.96.54 > is sending a few requests and NOPs typical of small tests. > > 206.81.97.109 is also currently (April 22, 06:30 UTC) making a few tests. > > A client at 206.81.96.33 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 64.124.52.0/24 and 209.169.14.0/24 to > dccifd at 206.81.96.33 from about 02:10 UTC. > > > Vernon Schryver vjs@... > _______________________________________________ > DCC mailing list DCC@... > http://www.rhyolite.com/mailman/listinfo/dcc > > 206.81.96.33 and things were getting autoblocked. I installed a temp server at 206.81.96.54 which seemed to make the dcc client happy again. I also added rules this morning for the firewall stuff on .33. 206.81.97.109 is a colo customer running their own mailserver. BTW I ordered the new server for the mirror yesterday so that should be here soon. Do I need to have an official server-id for 206.81.96.54? Thanks, William _______________________________________________ DCC mailing list DCC@... http://www.rhyolite.com/mailman/listinfo/dcc |
| Free Forum Powered by Nabble | Forum Help |