But if BOINC is uploading result files, and works for other projects, surely it's there already? I've only ever had to do that for port 31416, for remote management of BOINC by BoincView/BoincTasks.
But if BOINC is uploading result files, and works for other projects, surely it's there already? I've only ever had to do that for port 31416, for remote management of BOINC by BoincView/BoincTasks.
I'm not sure if you are referring to "in general" or Alex's case specifically.
Alex mentioned he has one computer working - the other not here
Alex log file symptoms, and start time suggest an exact match to OPs here.
The suggestion for Alex matches as best i could - the Kapersky workaround.
In general, why is this happening "now" and "for this project" and for "some hosts" ? E@H is the only project(?) that is doing a 301 redirect on a HTTP POST - this started after upgrade.
Doing a 301 on a POST (not a GET) gets a "MUST NOT..." in the spec below. Clearly this is causing the issue for some security software (and one could say "working as designed")
The workaround in the Kapersky case relaxes the built-in firewall inspection rules for the program "boinc.exe"
I don't know why this is not affecting more users, perhaps those without problems have slightly lower or different security settings somehow.
I get the same error message (no start tag) as I already mentioned in Backend upgrade scheduled for Wed Nov 18, but I use the Windows firewall, not Kaspersky's. The problem started with the site upgrade. I already have an exception in the firewall for communication between my computers. I extended it to the internet, without success.
Actually you get a different error message I just realized. This thread was started because the OP could not reach the scheduler. Your computer can reach the scheduler but gets an error message back.
I just looked at /hosts_user.php?userid=8434 and it seems that your i7 is getting work but the Pentium 4 is not. This may have to do with the old client version and should be discussed in a separate thread (because it is a different issue).
Thanks Alex - there are two parts to boinc - can you confirm both programs ?
For the Windows builds, the two programs are:
boinc.exe - this is the client, and performs all external internet communications. This is the one that must be allowed through the firewall in all cases, and is usually set as an exception automatically when BOINC is installed.
boincmgr.exe - this is the Manager, or graphical interface (the bit you see on screen). This program doesn't need internet access: it simply communicates with the client via an internal loopback. You may need to allow it access to the local network (not the internet at large) if you want to use the Manager on one computer to monitor and control the Client on a different computer.
I installed BOINC v5.10.45 into a test directory, and got the same result as Alex. The full message is:
Quote:
21/11/2015 12:06:39|Einstein@Home|Message from server: Error in request message: no start tag
(my emphasis) - so the new server doesn't like the request it received.
Comparing the scheduler request messages (v5.10.45 and v7.6.9) side-by-side, there's no actual tag in either! The first significant difference seems to be
0
0
0
0.000000
0.000000
0.000000
0.000000
1
- that block appears in v7.6.9, but is entirely absent from v5.10.45
I installed BOINC v5.10.45 into a test directory, and got the same result as Alex.
Thanks Richard that's good news. Can you put my mind to rest and confirm your client firewall settings don't improve or worsen this behaviour for v5.10.45?
Well, I actually got a scheduler reply, so I don't think it triggered the firewall - but then, I was the one getting replies anyway, since I don't use Kaspersky.
I don't know if that changed with the upgrade. If it did, then can you try changing the master project url to https://einstein.phys.uwm.edu/ Edit: (only on the v5.10.45)?
But if BOINC is uploading
)
But if BOINC is uploading result files, and works for other projects, surely it's there already? I've only ever had to do that for port 31416, for remote management of BOINC by BoincView/BoincTasks.
Boinc was already entered as
)
Boinc was already entered as an exception. This doesn't help.
RE: But if BOINC is
)
I'm not sure if you are referring to "in general" or Alex's case specifically.
Alex mentioned he has one computer working - the other not here
Alex log file symptoms, and start time suggest an exact match to OPs here.
The suggestion for Alex matches as best i could - the Kapersky workaround.
In general, why is this happening "now" and "for this project" and for "some hosts" ? E@H is the only project(?) that is doing a 301 redirect on a HTTP POST - this started after upgrade.
Doing a 301 on a POST (not a GET) gets a "MUST NOT..." in the spec below. Clearly this is causing the issue for some security software (and one could say "working as designed")
The workaround in the Kapersky case relaxes the built-in firewall inspection rules for the program "boinc.exe"
I don't know why this is not affecting more users, perhaps those without problems have slightly lower or different security settings somehow.
RE: Boinc was already
)
Thanks Alex - there are two parts to boinc - can you confirm both programs ?
"Boinc", and "Boinc client"
"Boinc" will be there by default (i am guessing)
You will have to find "Boinc client" the EXE listed in earlier post.
If that does not work, and this may not be possible or acceptable- are you able to test without firewall running?
Also you mentioned earlier two computers, one is working perfectly the second - is not able to contact E@H at all. Correct?
RE: I get the same error
)
Actually you get a different error message I just realized. This thread was started because the OP could not reach the scheduler. Your computer can reach the scheduler but gets an error message back.
I just looked at /hosts_user.php?userid=8434 and it seems that your i7 is getting work but the Pentium 4 is not. This may have to do with the old client version and should be discussed in a separate thread (because it is a different issue).
RE: Thanks Alex - there are
)
For the Windows builds, the two programs are:
boinc.exe - this is the client, and performs all external internet communications. This is the one that must be allowed through the firewall in all cases, and is usually set as an exception automatically when BOINC is installed.
boincmgr.exe - this is the Manager, or graphical interface (the bit you see on screen). This program doesn't need internet access: it simply communicates with the client via an internal loopback. You may need to allow it access to the local network (not the internet at large) if you want to use the Manager on one computer to monitor and control the Client on a different computer.
I installed BOINC v5.10.45
)
I installed BOINC v5.10.45 into a test directory, and got the same result as Alex. The full message is:
(my emphasis) - so the new server doesn't like the request it received.
Comparing the scheduler request messages (v5.10.45 and v7.6.9) side-by-side, there's no actual tag in either! The first significant difference seems to be
0 0 0 0.000000 0.000000 0.000000 0.000000 1- that block appears in v7.6.9, but is entirely absent from v5.10.45
RE: I installed BOINC
)
Thanks Richard that's good news. Can you put my mind to rest and confirm your client firewall settings don't improve or worsen this behaviour for v5.10.45?
Well, I actually got a
)
Well, I actually got a scheduler reply, so I don't think it triggered the firewall - but then, I was the one getting replies anyway, since I don't use Kaspersky.
The reply (in full) was
which doesn't tell us much more.
It seems to come (in current code) from line 269 of sched/sched_types.cpp:
if (!xp.match_tag("scheduler_request")) return "no start tag";but is present and correct in the v5.10.45 request."Current code" probably doesn't help here. 611 is quite old - other projects are returning 705 or 707.
The only additional point
)
The only additional point (probably a red herring) to note, but easy to check http://einstein.phys.uwm.edu/ gives a http 301 redirect to https://einstein.phys.uwm.edu/
I don't know if that changed with the upgrade. If it did, then can you try changing the master project url to https://einstein.phys.uwm.edu/ Edit: (only on the v5.10.45)?
Edit++: ignore this herring - it is red