Delay Update Attempt?

[rlcronin 3]

My normal mode of operation is to put my PC's to sleep rather than shutting them down. This is because I have them wake up at various times to perform unattended maintenance tasks. On one of my PC's, nearly every time it wakes up, if nod32 attempts to update the virus signature database "too soon" after the wakeup, it fails because the server can't be found. I am guessing this is because the network interface on that machine is a bit slow in restoring connectivity after resume. On another PC that operates in exactly the same manner, this never happens. The problematic PC has a Marvell network interface. The well behaved one has an Intel network interface. All the drivers are up to date.

 

Anyway, I am wondering if there might be some way to have nod32 wait until the network connection is available before attempting to run the update. Perhaps something similar to the way you can specify that tasks scheduled via the Windows task scheduler should not try to run unless a network connection is available. Or maybe a setting to have the update retried after a failure after a user-specified interval (perhaps defaulting to a minute).

 

Thoughts on this?

--

bc

Edited August 12, 2014 by rlcronin

[Arakasi 549]

Hello,

If you go into Tools > Scheduler, you should find the updates and be able to alter the events, follow-ups, actions to take if failed or success etc.

I am not sure which one to edit, but you could also create a new one, with user logon, and if fails, have it run again as soon as possible.

This may not solve the issue of update error, but may cause it to update again immediately after the failed attempted allowing time for your adapter to renew IP.

 

I am not aware of any way to facilitate a delay in updates if it is already scheduled at the specified time or event trigger.

[Marcos 5,070]

Update tasks are already delayed a bit. There's no way to configure this delay, however. We'll consider improving scheduler for future versions.

[rlcronin 3]

Update tasks are already delayed a bit. There's no way to configure this delay, however. We'll consider improving scheduler for future versions.

Thanks.  Iam aware I can have it retry in relatively short order, I was indeed wondering if there were a way to delay the attempt through the ui (or even better, specify that the task should not run if the network connection is not available as one can do with the Windows task scheduler).

--

bc

[Aryeh Goretsky 378]

Hello,

Out of curiosity, do you know how long it takes for a network interface to fully initialize on the machine with the Marvell NIC?

Regards,

Aryeh Goretsky

[rlcronin 3]

Hello,

Out of curiosity, do you know how long it takes for a network interface to fully initialize on the machine with the Marvell NIC?

Regards,

Aryeh Goretsky

I'm not sure how I'd figure that out, but I'll work on it. Thanks.

--

bc

Edited August 19, 2014 by rlcronin

[Aryeh Goretsky 378]

Hello,

Perhaps you could start "ping -t" in a command windows, sleep the computer, wake it, and see how long it takes for the ping to resume normal activity?

I'm just trying to get a rough idea of how much time is involved (a few seconds, a minute, etc.), not measure it down to the millisecond.

Regards,

Aryeh Goretsky

[rlcronin 3]

I tried the ping thing but didn't get any useful info. Then I thought of looking in the event log.

 

This is the very first entry in the system event log at the time of wakeup:

 

09:45:42 The system time has changed to ‎2014‎-‎08‎-‎20T13:45:42.500000000Z from ‎2014‎-‎08‎-‎20T10:04:56.750426100Z.

 

Then in the application event log I saw these two events:

 

09:45:48 Fault bucket -861546332, type 5

Event Name: WPNConnectionFailure

Response: Not available

 

followed by

 

09:45:51 Customer Experience Improvement Program data was successfully sent to Microsoft.

 

From this I conclude that it took almost 10 seconds from wakeup time for the network to be able to successfully connect to the Internet.

 

How's that?

--

bc

[Aryeh Goretsky 378]

Hello,

 

I thought the program was already waiting more than ten seconds, but I could be wrong about that; I'll let the engineering staff know, though. 

 

Regards,

 

Aryeh Goretsky

[SweX 871]

Hello,

 

I thought to share my experience on this even though I rarely put my PC to sleep unless I will be away for several hours. But the few times I do and when I wake it up, I would say on average that it takes between 2-4 seconds before the program starts to check for an update, and it's usually already finished by the time the monitor lights up. So yeah it goes quite fast.

 

I think through all the years I have had max 5 failed update attempts at "wake up" because it tried to update too early. And of course if you do a manual update by clicking the button a few seconds after the failed update it works just fine.

[rlcronin 3]

I can now substantiate SweX's comments with hard data. I have a System event log entry dated 08/22/2014 at 3:59:31 PM recording the PC being woken up. Then in the nod32 log file I have an entry at 3:59:33 from the Update module saying "Server not found". So nod32 is not waiting very long to make the attempt.

--

bc

[Arakasi 549]

You can also code a js, vbs, or batch to move even quicker to distribute or launch a malicious payload into changing registry items or replace drivers, services etc, etc.

There is a huge reason why ESET updates so quickly to grab what potentially could be an update to a recently malicous distributed file and how to neutralize it.

 

Dare i ask why we have an option to manually update our definitions in the event of failure ?

[rlcronin 3]

You can also code a js, vbs, or batch to move even quicker to distribute or launch a malicious payload into changing registry items or replace drivers, services etc, etc.

There is a huge reason why ESET updates so quickly to grab what potentially could be an update to a recently malicous distributed file and how to neutralize it.

 

Dare i ask why we have an option to manually update our definitions in the event of failure ?

Alright, that makes sense, but what good does it do to try so quickly only to have it fail because the network card is not fully ready only to have it then not try again for the default 60 minute regular automatic update interval. A lot more could happen in those 60 minutes than would happen in the 6-8 seconds longer you'd be waiting for the network to be ready.

--

bc

[SweX 871]

 

You can also code a js, vbs, or batch to move even quicker to distribute or launch a malicious payload into changing registry items or replace drivers, services etc, etc.

There is a huge reason why ESET updates so quickly to grab what potentially could be an update to a recently malicous distributed file and how to neutralize it.

 

Dare i ask why we have an option to manually update our definitions in the event of failure ?

A lot more could happen in those 60 minutes than would happen in the 6-8 seconds longer you'd be waiting for the network to be ready.

--

bc

First, Thanks for your report above

 

Second, yes that's kind of like I think too, a delay of 10-20 sec must surely be better than risking a failed update and then the time it takes until the next automatic check is performed 59+ min later, unless the user does a manual update straight after like most experienced users probably would do if they see that it failed.

Or do both of us think wrong here 

Edited August 23, 2014 by SweX

[Arakasi 549]

 

You can also code a js, vbs, or batch to move even quicker to distribute or launch a malicious payload into changing registry items or replace drivers, services etc, etc.

There is a huge reason why ESET updates so quickly to grab what potentially could be an update to a recently malicous distributed file and how to neutralize it.

 

Dare i ask why we have an option to manually update our definitions in the event of failure ?

Alright, that makes sense, but what good does it do to try so quickly only to have it fail because the network card is not fully ready only to have it then not try again for the default 60 minute regular automatic update interval. A lot more could happen in those 60 minutes than would happen in the 6-8 seconds longer you'd be waiting for the network to be ready.

--

bc

 

 

Not all network controllers are slow ... Most should keep up, but there are some that are 50mbps lol

Edited August 23, 2014 by Arakasi

[Arakasi 549]

I agree that the update should be delayed like you guys are stating, however.....

 

In scheduler you can add events like, "Upon update failure, try again..... and again....." These are similar to Tasks in windows.

I could also suggest that maybe ESET should just code in the multiple attempts at updating upon failure to the default updates ??

 

What do you guys think ?

[SweX 871]

 

 

You can also code a js, vbs, or batch to move even quicker to distribute or launch a malicious payload into changing registry items or replace drivers, services etc, etc.

There is a huge reason why ESET updates so quickly to grab what potentially could be an update to a recently malicous distributed file and how to neutralize it.

 

Dare i ask why we have an option to manually update our definitions in the event of failure ?

Alright, that makes sense, but what good does it do to try so quickly only to have it fail because the network card is not fully ready only to have it then not try again for the default 60 minute regular automatic update interval. A lot more could happen in those 60 minutes than would happen in the 6-8 seconds longer you'd be waiting for the network to be ready.

--

bc

 

 

Not all network controllers are slow ... Most should keep up, but there are some that are 50mbps lol

 

Yep, but I guess it's impossible to know how many ESET users that actually is aware of this, the tray icon will not turn orange or red after 1 failed update(for me anyway), if the second update checks fails as well then it will change color afaik. So unless they open up the GUI they will not see that it failed. 

[SweX 871]

I agree that the update should be delayed like you guys are stating, however.....

 

In scheduler you can add events like, "Upon update failure, try again..... and again....." These are similar to Tasks in windows.

I could also suggest that maybe ESET should just code in the multiple attempts at updating upon failure to the default updates ??

 

What do you guys think ?

I think anything that can help or fix this is worth a try.   

I wonder how many that would still be affected if they would increase the delay to 10sec. 

[Arakasi 549]

I wonder how many malware writers would attempt to sneak scripts that will launch in under 10 seconds though, especially if we discussed it here on the forum.

[SweX 871]

Hmmm yeah shhhhh. 

[rugk 397]

Can it be that setting the option to restart the task as soon as possible (see screenshot) is a solution?

 

If the update fails then it should be repeated as long as it is successfully. This would be like "first update failed - wait 30 sec - second update failed - wait 30 sec - third update was successfully".

Or do I get this option wrong?