letztmaliger Kontakt mit Server 18 Nov 2015, 5:01:05 UTC
This is the last time my PC connected with the server as stated on my account page.
I am also gonna make it visible to you.
This problem also exists with my old notebook as well. my Laptop being unable to connect since about 17:00 yesterday evening.
In my case the most recent work sent mentioned on the task pages is time-stamped 18 Nov 2015, 6:52:02 UTC
and the most recent work reported is time-stamped 18 Nov 2015, 6:56:37
So the time of onset of your problem seems possibly compatible with mine--OK before the big server migration, failing subsequently.
On my laptop, I've tried sequentially:
1. set project
2. remove project--followed by re-enlistment to Einstein
3. uninstall BOINC using the uninstaller made available to Windows followed by a reboot, then a fresh BOINC install of 64-bit Windows 7.6.9 (the current latest recommended for general use).
After the fresh BOINC install, I first re-enlisted at SETI, which went smoothly including sending me work, which is currently running.
Then I re-enlisted at Einstein, which failed. While I've saved extensive log file content, here I'll show where it appeared to divert from success (up through the steps of
First many startup steps seemed to process successfully:
11/19/2015 2:32:03 PM | | [http] [ID#2] Info: Connected to einstein.phys.uwm.edu (129.89.61.70) port 80 (#7)
11/19/2015 2:32:03 PM | | [http] [ID#2] Sent header to server: GET /get_project_config.php HTTP/1.1
11/19/2015 2:32:03 PM | | [http] [ID#2] Sent header to server: User-Agent: BOINC client (windows_x86_64 7.6.9)
11/19/2015 2:32:03 PM | | [http] [ID#2] Sent header to server: Host: einstein.phys.uwm.edu
11/19/2015 2:32:03 PM | | [http] [ID#2] Sent header to server: Accept: */*
11/19/2015 2:32:03 PM | | [http] [ID#2] Sent header to server: Accept-Encoding: deflate, gzip
11/19/2015 2:32:03 PM | | [http] [ID#2] Sent header to server: Content-Type: application/x-www-form-urlencoded
11/19/2015 2:32:03 PM | | [http] [ID#2] Sent header to server: Accept-Language: en_US
11/19/2015 2:32:03 PM | | [http] [ID#2] Sent header to server:
11/19/2015 2:32:04 PM | | [http] [ID#2] Received header from server: HTTP/1.1 200 OK
11/19/2015 2:32:04 PM | | [http] [ID#2] Received header from server: Date: Thu, 19 Nov 2015 21:32:02 GMT
11/19/2015 2:32:04 PM | | [http] [ID#2] Received header from server: Server: Apache/2.4.10 (Debian)
11/19/2015 2:32:04 PM | | [http] [ID#2] Received header from server: Vary: Accept-Encoding
11/19/2015 2:32:04 PM | | [http] [ID#2] Received header from server: X-Content-Type-Options: nosniff
1
and so on for many lines.
to my non-expert eye, it appears that several more transactions with einstein.phys.uwm.edu are successful.
But then it tries to go to Hannover
This snippet shows the transition from success to failure :
11/19/2015 2:32:26 PM | Einstein@Home | [http] [ID#1] Received header from server: Content-Encoding: gzip
11/19/2015 2:32:26 PM | Einstein@Home | [http] [ID#1] Received header from server: Content-Length: 6003
11/19/2015 2:32:26 PM | Einstein@Home | [http] [ID#1] Received header from server:
11/19/2015 2:32:26 PM | Einstein@Home | [http] [ID#1] Info: Connection #9 to host einstein.phys.uwm.edu left intact
11/19/2015 2:32:27 PM | Einstein@Home | Master file download succeeded
11/19/2015 2:32:32 PM | Einstein@Home | Sending scheduler request: Project initialization.
11/19/2015 2:32:32 PM | Einstein@Home | Requesting new tasks for CPU
11/19/2015 2:32:32 PM | Einstein@Home | [http] HTTP_OP::init_post(): http://scheduler.einsteinathome.org/EinsteinAtHome_cgi/cgi
11/19/2015 2:32:32 PM | Einstein@Home | [http] HTTP_OP::libcurl_exec(): ca-bundle set
11/19/2015 2:32:33 PM | Einstein@Home | [http] [ID#1] Info: timeout on name lookup is not supported
11/19/2015 2:32:33 PM | Einstein@Home | [http] [ID#1] Info: Hostname was NOT found in DNS cache
11/19/2015 2:32:33 PM | Einstein@Home | [http] [ID#1] Info: Trying 130.75.116.40...
11/19/2015 2:32:33 PM | Einstein@Home | [http] [ID#1] Info: Connected to scheduler.einsteinathome.org (130.75.116.40) port 80 (#10)
11/19/2015 2:32:33 PM | Einstein@Home | [http] [ID#1] Sent header to server: POST /EinsteinAtHome_cgi/cgi HTTP/1.1
11/19/2015 2:32:33 PM | Einstein@Home | [http] [ID#1] Sent header to server: User-Agent: BOINC client (windows_x86_64 7.6.9)
11/19/2015 2:32:33 PM | Einstein@Home | [http] [ID#1] Sent header to server: Host: scheduler.einsteinathome.org
11/19/2015 2:32:33 PM | Einstein@Home | [http] [ID#1] Sent header to server: Accept: */*
11/19/2015 2:32:33 PM | Einstein@Home | [http] [ID#1] Sent header to server: Accept-Encoding: deflate, gzip
11/19/2015 2:32:33 PM | Einstein@Home | [http] [ID#1] Sent header to server: Content-Type: application/x-www-form-urlencoded
11/19/2015 2:32:33 PM | Einstein@Home | [http] [ID#1] Sent header to server: Accept-Language: en_US
11/19/2015 2:32:33 PM | Einstein@Home | [http] [ID#1] Sent header to server: Content-Length: 11921
11/19/2015 2:32:33 PM | Einstein@Home | [http] [ID#1] Sent header to server: Expect: 100-continue
11/19/2015 2:32:33 PM | Einstein@Home | [http] [ID#1] Sent header to server:
11/19/2015 2:32:33 PM | Einstein@Home | [http] [ID#1] Info: Empty reply from server
11/19/2015 2:32:33 PM | Einstein@Home | [http] [ID#1] Info: Connection #10 to host scheduler.einsteinathome.org left intact
11/19/2015 2:32:33 PM | Einstein@Home | [http] HTTP error: Server returned nothing (no headers, no data)
11/19/2015 2:32:33 PM | Einstein@Home | Scheduler request failed: Server returned nothing (no headers, no data)
11/19/2015 2:32:34 PM | | Project communication failed: attempting access to reference site
I did notice after the reinstall that there appear to be files left over from my previous BOINC install in the BOINC data directory.
Needless to say, there were probably many leftover entries in the Windows registry as well. So I'm not claiming I've proved failure on a completely fresh install on a new machine. But this seems really strange.
As to security software interference, as I documented doing once before in this thread, I again paused protection, and ran another update on Einstein. This attempt again failed, including the key lines:
11/19/2015 2:48:44 PM | Einstein@Home | [http] [ID#1] Sent header to server:
11/19/2015 2:48:44 PM | Einstein@Home | [http] [ID#1] Info: Empty reply from server
11/19/2015 2:48:44 PM | Einstein@Home | [http] [ID#1] Info: Connection #16 to host scheduler.einsteinathome.org left intact
11/19/2015 2:48:44 PM | Einstein@Home | [http] HTTP error: Server returned nothing (no headers, no data)
11/19/2015 2:48:44 PM | Einstein@Home | Scheduler request failed: Server returned nothing (no headers, no data)
Now I really am out of ideas for the moment. I can run SETI to maintain system readiness, but that has no appeal for me. I appear to have lost completely the ability to run Einstein at all.
Is anything being logged in the Windows System / Kapersky event logs?
On my daily driver, Kaspersky summary reports show 0 cases in the last thirty days for each of neutralized threats, applications blocked, and network attacks blocked.
I suppose regarding Windows you speak of things visible in the Event Viewer. In response to your interest I just spent some time looking around in there. If it is trying to tell me something useful, it escapes me. If you have a more specific question, I'll take another look.
Is anything being logged in the Windows System / Kapersky event logs?
On my daily driver, Kaspersky summary reports show 0 cases in the last thirty days for each of neutralized threats, applications blocked, and network attacks blocked.
I suppose regarding Windows you speak of things visible in the Event Viewer. In response to your interest I just spent some time looking around in there. If it is trying to tell me something useful, it escapes me. If you have a more specific question, I'll take another look.
If I recall it will be "Network" events i would hope generated by Kapersky, if i recall K does log into the event log.
Do all Kapersky users enjoy the same problem?
Do you have anything not running Kapersky?
OK one point easy tested. Your solitary ping earlier did not get a response. It should have. Drop the "-n 1" and see if you do get a reply. If you do not get a reply something is inspecting and dropping traffic. Find out what that is.
Kapersky i know has a separate event log and some settings can be forced to produce a trace.
You have already confirmed the http protocol is working fine using a browser. This proves a lot of your network and hosts are working well.
You are seeing the correct response in the browser to that IP address and also the correct response to see an XML file at .../cgi below.
OK one point easy tested. Your solitary ping earlier did not get a response. It should have. Drop the "-n 1" and see if you do get a reply. If you do not get a reply something is inspecting and dropping traffic. Find out what that is.
Not necessarily. Many servers are deliberately configured to drop ping requests.
OK one point easy tested. Your solitary ping earlier did not get a response.
I don't know that. But you can help.
Please ping scheduler.einsteinathome.org and advise of the response. If you have no access to a Windows machine from which to try this, perhaps another reader here will be willing to try.
As to your concern about my ping being "solitary", I already mentioned that I had run the Windows default 4 repetitions several times without result. I am currently running a 100 repetition trial with the timeout set to 20 seconds. About 10 cycles into the trial they have all timed out.
My traceroute result posted earlier shows things getting through deep into Germany, well beyond any place I have any means to adjust myself.
OK one point easy tested. Your solitary ping earlier did not get a response. It should have. Drop the "-n 1" and see if you do get a reply. If you do not get a reply something is inspecting and dropping traffic. Find out what that is.
Not necessarily. Many servers are deliberately configured to drop ping requests.
My view is this.
agentb@gluon:~/boinc$ ping 130.75.116.40
PING 130.75.116.40 (130.75.116.40) 56(84) bytes of data.
64 bytes from 130.75.116.40: icmp_seq=1 ttl=51 time=30.0 ms
64 bytes from 130.75.116.40: icmp_seq=2 ttl=51 time=29.8 ms
64 bytes from 130.75.116.40: icmp_seq=3 ttl=51 time=29.9 ms
64 bytes from 130.75.116.40: icmp_seq=4 ttl=51 time=29.6 ms
Strangely i don't get a response from Windows to the same address, so that muddies the water a little more.
RE: RE: letztmaliger
)
In my case the most recent work sent mentioned on the task pages is time-stamped 18 Nov 2015, 6:52:02 UTC
and the most recent work reported is time-stamped 18 Nov 2015, 6:56:37
So the time of onset of your problem seems possibly compatible with mine--OK before the big server migration, failing subsequently.
On my laptop, I've tried
)
On my laptop, I've tried sequentially:
1. set project
2. remove project--followed by re-enlistment to Einstein
3. uninstall BOINC using the uninstaller made available to Windows followed by a reboot, then a fresh BOINC install of 64-bit Windows 7.6.9 (the current latest recommended for general use).
After the fresh BOINC install, I first re-enlisted at SETI, which went smoothly including sending me work, which is currently running.
Then I re-enlisted at Einstein, which failed. While I've saved extensive log file content, here I'll show where it appeared to divert from success (up through the steps of
First many startup steps seemed to process successfully:
and so on for many lines.
to my non-expert eye, it appears that several more transactions with einstein.phys.uwm.edu are successful.
But then it tries to go to Hannover
This snippet shows the transition from success to failure :
I did notice after the reinstall that there appear to be files left over from my previous BOINC install in the BOINC data directory.
Needless to say, there were probably many leftover entries in the Windows registry as well. So I'm not claiming I've proved failure on a completely fresh install on a new machine. But this seems really strange.
As to security software interference, as I documented doing once before in this thread, I again paused protection, and ran another update on Einstein. This attempt again failed, including the key lines:
Now I really am out of ideas for the moment. I can run SETI to maintain system readiness, but that has no appeal for me. I appear to have lost completely the ability to run Einstein at all.
RE: I appear to have lost
)
Is anything being logged in the Windows System / Kapersky event logs?
RE: Is anything being
)
On my daily driver, Kaspersky summary reports show 0 cases in the last thirty days for each of neutralized threats, applications blocked, and network attacks blocked.
I suppose regarding Windows you speak of things visible in the Event Viewer. In response to your interest I just spent some time looking around in there. If it is trying to tell me something useful, it escapes me. If you have a more specific question, I'll take another look.
Same for me plus BOINC is a
)
Same for me plus BOINC is a trusted program for KIS so Network traffic won't be blocked.
RE: RE: Is anything being
)
If I recall it will be "Network" events i would hope generated by Kapersky, if i recall K does log into the event log.
Do all Kapersky users enjoy the same problem?
Do you have anything not running Kapersky?
OK one point easy tested. Your solitary ping earlier did not get a response. It should have. Drop the "-n 1" and see if you do get a reply. If you do not get a reply something is inspecting and dropping traffic. Find out what that is.
Kapersky i know has a separate event log and some settings can be forced to produce a trace.
You have already confirmed the http protocol is working fine using a browser. This proves a lot of your network and hosts are working well.
You are seeing the correct response in the browser to that IP address and also the correct response to see an XML file at .../cgi below.
RE: OK one point easy
)
Not necessarily. Many servers are deliberately configured to drop ping requests.
RE: OK one point easy
)
I don't know that. But you can help.
Please ping scheduler.einsteinathome.org and advise of the response. If you have no access to a Windows machine from which to try this, perhaps another reader here will be willing to try.
As to your concern about my ping being "solitary", I already mentioned that I had run the Windows default 4 repetitions several times without result. I am currently running a 100 repetition trial with the timeout set to 20 seconds. About 10 cycles into the trial they have all timed out.
My traceroute result posted earlier shows things getting through deep into Germany, well beyond any place I have any means to adjust myself.
RE: RE: OK one point easy
)
My view is this.
agentb@gluon:~/boinc$ ping 130.75.116.40
PING 130.75.116.40 (130.75.116.40) 56(84) bytes of data.
64 bytes from 130.75.116.40: icmp_seq=1 ttl=51 time=30.0 ms
64 bytes from 130.75.116.40: icmp_seq=2 ttl=51 time=29.8 ms
64 bytes from 130.75.116.40: icmp_seq=3 ttl=51 time=29.9 ms
64 bytes from 130.75.116.40: icmp_seq=4 ttl=51 time=29.6 ms
Strangely i don't get a response from Windows to the same address, so that muddies the water a little more.
RE: Strangely i don't get
)
That really had me scratching my head.
Something is dropping ping packets of a certain length.
I do get a reply from Windows if i use length 50 (default windows is 64 iirc)
ping -l 50 130.75.116.40
try with "-l 50"