Strangely i don't get a response from Windows to the same address, so that muddies the water a little more.
Well, if it is normal for a Windows ping there to time out, than my time out is not a useful means of distinguishing why my machine can't use Einstein and others can. But since our sample size is currently two we don't even know that.
It still, however, might possibly be a clue to an unintentional configuration issue on a server.
I have no idea what that distinctions means practically, however.
OK i have been doing some testing (i had to startup a laptop to see) and in fact the only thing that is being blocked is ICMP data size 32 exactly which is the windows default ping size.
Which is a bit weird to block "only" that, but it also looks like a perimeter firewall doing the blocking, as further upstream these are being dropped.
I was seeing a difference - now i can see why. (and it doesn't help you sadly)
No, I don't. Is there a reason you suspect it does not stop doing this when "pause protection" is expressly invoked?
a) the only examples we have of this issue is with Kapersky -so far
b) no Kapersky users have said "i'm ok" - yet
c) I quote your post i referred earlier
Quote:
True story: I very recently was involved in a thread on a weather reporting software site involving sudden inability of the weather program on a given PC to post data to a publicly visible site. The original poster was an Avast user, and I am a Kaspersky user. When the software author advised us both that the likely cause of our trouble (with specific symptoms) was security software, we both responded that we had already checked that. We both were wrong. In my specific case, telling my software (Kaspersky) to "pause protection" was not enough to avert the problem. I don't know just what the Avast user had done, but he too had falsely concluded that his security software was not his problem.
Security software can be a bit mysterious.
A very true statement and i have seen many times "on host" firewall and intrusion detection systems "play games" with your network stack.
I'd quite forgotten that episode which involved a new release of the weather posting software Cumulus, which had wound up in my Kaspersky trust grouping as less than fully trusted.
However, just now I reviewed the Kaspersky trust classifications for applications containing the string "boinc" and found them to be at full trust level. I'd guess that the setup server interactions are seen as coming from the boinc application, but if someone has another application name to check, I'm all ears.
Fully uninstalling security software from even one of my machines is probably farther than I'm interested in going without more reason for suspicion than this.
So it's not the router - it must be filtered either upstream (ISP?) or downstream (local antivirus/internet security?).
AgentB wrote:
Do all Kapersky users enjoy the same problem?
Do you have anything not running Kapersky?
OK, you guys win. On all three out of my four hosts where I have actually tried it, rebooting the machine with Kaspersky autorun disabled resulted in Boinc promptly reporting all the (large amount of) pending work, and successfully requesting and downloading new work.
On two of the machines I waited until the work requests had tapered down to zero before starting Kaspersky (and re-enabling autorun). On the third I waited until the request size had tapered down pretty small, then started up Kaspersky. As the incremental requests come about once per minute, it was clear to see that the very next request after Kaspersky started up went back to the bad behavior.
So we have a key enabling variable on my hosts. We don't begin to have an explanation or a satisfactory solution. Sadly for me, Kaspersky users may not represent much of the Einstein computing capacity (and possibly not all Kaspersky users are affected either). Of course, whatever the problem is may well affect some other security software as well.
A few observations:
1. This failure only occurred after the recent big server change (which, I think carried many associated changes--not just a move of the same old software to a new home).
2. The software on my computers (including Windows, Boinc, Kaspersky) remains perfectly happy to interact with the SETI scheduler)
3. Even in dealing with Einstein, there appears to be a difference between successful interactions with einstein.phys.uwm.edu and utter failure with scheduler.einsteinathome.org.
I can easily understand that the Einstein developers have plenty of good opportunities for their efforts, and may initially regard the evidence in hand as suggesting a Kaspersky bug, which in any case may not reduce their user base by much.
If I can help to shed light on this matter, or possibly to enable work on a solution, I'd be pleased to try.
If it would be of any help, I can provide selected samples of http_debug-enabled logs, with some guidance as to what part is interesting--or the whole things by some agreed transfer method. I think I've already posted more in this forum than was probably civilized.
Okay, so after your las post i again tried some different Settings in Kaspersky.
As a Workaround I can suggest telling Kaspersky not to look at the Network traffic from the BOINC Client. After Setting this there is no Problem at all.
It is just a bit weird because Kasperksy has been told to let the program do whatever it wants to do, so for any reason there seems to be something SINCE THE SERVER UPDATE about the Network traffic which Kaspersky recognizes as dangerous.
As a Workaround I can suggest telling Kaspersky not to look at the Network traffic from the BOINC Client.
Agreed. As it took me a little looking to find the setting you are suggesting, I'll spell out details in case another Kaspersky user comes by here.
one path:
right click Kaspersky tray icon
choose settings|protection|application control|manage applications
type boinc into the search box
right click on boinc client
select "details and rules"
click the "exclusions" tab
check the box on "do not scan network traffic"
click "save"
Something about the server change software details must either have caused a change in what network traffic the boinc client generates when talking to the scheduler, or else the current scheduler no longer tolerates tampering Kaspersky was doing with that traffic all along. At a guess.
dunno27--thank you very much. I would not have found this setting, and without it I might have decided to quit Einstein after a few days of limping along with a reboot every couple of days to report and download.
I still would like a fix, but I can't even guess what a fix would look like, nor guess how much effort developing it might cost.
I'm really, really pleased that you have a workaround that you are comfortable with for the moment. You should not feel at all concerned at the volume of messages that have been flowing back and forth as a result of this issue. You are such a valued and valuable member of this community that I'm sure the Devs will be investigating this issue thoroughly until a proper solution is found. Since everything works at Seti but doesn't work here, there has to be a reason that should be able to be found.
I've followed the entire conversation but stayed right out simply because I didn't know enough to make any sort of meaningful contribution. I would like to thank very much, those who did respond to your pleas for ideas to try - in particular, Richard and AgentB and dunno27 for the information about getting Kaspersky to not look at traffic from the BOINC client.
I was also very pleased to see you give the details of how to change that setting. Like a true professional, you always 'complete the story' so that others having the same issue and finding this thread can benefit from your full description. Thanks very much for taking the trouble to do that.
The place wouldn't be the same if you moved elsewhere :-).
RE: Strangely i don't get a
)
Well, if it is normal for a Windows ping there to time out, than my time out is not a useful means of distinguishing why my machine can't use Einstein and others can. But since our sample size is currently two we don't even know that.
It still, however, might possibly be a clue to an unintentional configuration issue on a server.
RE: try with "-l 50" So
)
So the ping help describes the -l switch as governing "send buffer size"
Here using send buffer size of 50 does indeed get response from all of the following targets:
130.75.116.40
scheduler.einsteinathome.org
einstein10.aei.uni-hannover.de
none of which gave responses without that adjustment.
I have no idea what that distinctions means practically, however.
RE: I have no idea what
)
OK i have been doing some testing (i had to startup a laptop to see) and in fact the only thing that is being blocked is ICMP data size 32 exactly which is the windows default ping size.
Which is a bit weird to block "only" that, but it also looks like a perimeter firewall doing the blocking, as further upstream these are being dropped.
I was seeing a difference - now i can see why. (and it doesn't help you sadly)
Do you have a non Kapersky host?
RE: Do you have a non
)
No, I don't. Is there a reason you suspect it does not stop doing this when "pause protection" is expressly invoked?
RE: RE: Do you have a non
)
a) the only examples we have of this issue is with Kapersky -so far
b) no Kapersky users have said "i'm ok" - yet
c) I quote your post i referred earlier
A very true statement and i have seen many times "on host" firewall and intrusion detection systems "play games" with your network stack.
d) one more thing to eliminate.
RE: Security software can
)
I'd quite forgotten that episode which involved a new release of the weather posting software Cumulus, which had wound up in my Kaspersky trust grouping as less than fully trusted.
However, just now I reviewed the Kaspersky trust classifications for applications containing the string "boinc" and found them to be at full trust level. I'd guess that the setup server interactions are seen as coming from the boinc application, but if someone has another application name to check, I'm all ears.
Fully uninstalling security software from even one of my machines is probably farther than I'm interested in going without more reason for suspicion than this.
Richard Haselgrove wrote:So
)
OK, you guys win. On all three out of my four hosts where I have actually tried it, rebooting the machine with Kaspersky autorun disabled resulted in Boinc promptly reporting all the (large amount of) pending work, and successfully requesting and downloading new work.
On two of the machines I waited until the work requests had tapered down to zero before starting Kaspersky (and re-enabling autorun). On the third I waited until the request size had tapered down pretty small, then started up Kaspersky. As the incremental requests come about once per minute, it was clear to see that the very next request after Kaspersky started up went back to the bad behavior.
So we have a key enabling variable on my hosts. We don't begin to have an explanation or a satisfactory solution. Sadly for me, Kaspersky users may not represent much of the Einstein computing capacity (and possibly not all Kaspersky users are affected either). Of course, whatever the problem is may well affect some other security software as well.
A few observations:
1. This failure only occurred after the recent big server change (which, I think carried many associated changes--not just a move of the same old software to a new home).
2. The software on my computers (including Windows, Boinc, Kaspersky) remains perfectly happy to interact with the SETI scheduler)
3. Even in dealing with Einstein, there appears to be a difference between successful interactions with einstein.phys.uwm.edu and utter failure with scheduler.einsteinathome.org.
I can easily understand that the Einstein developers have plenty of good opportunities for their efforts, and may initially regard the evidence in hand as suggesting a Kaspersky bug, which in any case may not reduce their user base by much.
If I can help to shed light on this matter, or possibly to enable work on a solution, I'd be pleased to try.
If it would be of any help, I can provide selected samples of http_debug-enabled logs, with some guidance as to what part is interesting--or the whole things by some agreed transfer method. I think I've already posted more in this forum than was probably civilized.
Okay, so after your las post
)
Okay, so after your las post i again tried some different Settings in Kaspersky.
As a Workaround I can suggest telling Kaspersky not to look at the Network traffic from the BOINC Client. After Setting this there is no Problem at all.
It is just a bit weird because Kasperksy has been told to let the program do whatever it wants to do, so for any reason there seems to be something SINCE THE SERVER UPDATE about the Network traffic which Kaspersky recognizes as dangerous.
RE: As a Workaround I can
)
Agreed. As it took me a little looking to find the setting you are suggesting, I'll spell out details in case another Kaspersky user comes by here.
one path:
right click Kaspersky tray icon
choose settings|protection|application control|manage applications
type boinc into the search box
right click on boinc client
select "details and rules"
click the "exclusions" tab
check the box on "do not scan network traffic"
click "save"
Something about the server change software details must either have caused a change in what network traffic the boinc client generates when talking to the scheduler, or else the current scheduler no longer tolerates tampering Kaspersky was doing with that traffic all along. At a guess.
dunno27--thank you very much. I would not have found this setting, and without it I might have decided to quit Einstein after a few days of limping along with a reboot every couple of days to report and download.
I still would like a fix, but I can't even guess what a fix would look like, nor guess how much effort developing it might cost.
Peter, I'm really, really
)
Peter,
I'm really, really pleased that you have a workaround that you are comfortable with for the moment. You should not feel at all concerned at the volume of messages that have been flowing back and forth as a result of this issue. You are such a valued and valuable member of this community that I'm sure the Devs will be investigating this issue thoroughly until a proper solution is found. Since everything works at Seti but doesn't work here, there has to be a reason that should be able to be found.
I've followed the entire conversation but stayed right out simply because I didn't know enough to make any sort of meaningful contribution. I would like to thank very much, those who did respond to your pleas for ideas to try - in particular, Richard and AgentB and dunno27 for the information about getting Kaspersky to not look at traffic from the BOINC client.
I was also very pleased to see you give the details of how to change that setting. Like a true professional, you always 'complete the story' so that others having the same issue and finding this thread can benefit from your full description. Thanks very much for taking the trouble to do that.
The place wouldn't be the same if you moved elsewhere :-).
Cheers,
Gary.