Update "error"

Dear Eset,

If I have unplugged network cable and switched off Wi-Fi, then, naturally, programs(including NOD32) cannot access internet, and it is not an error!

Consequently, there is no need to display an error message, as actually no error has occurred. In case signatures are outdated, there is another message for that.

 

With flawed design, problems will not become history

I notice that thread about NOD32 reporting outdated database as current(again!) is conveniently closed, and obvious design flaw is declared a temporary problem. Therefore I have few questions.

1. Why server overload leads to display of wrong (potentially dangerous) information, not "server connection error"?

2. Is NOD32, in case of server overload, knowingly (by design) misinforming the user, in attempt to hide server problems?

Thanks.

 

Re: With flawed design, problems will not become history

The thread was most likely closed because there are a few other threads going about the same problem in multiple forums. No need to have multiple threads about the same issue.

Also, in regards to the incorrect message showing up. I obviously do not know what the code looks like that eset uses to download updates. But from my own experience in programming, a lot of times you can only go by error/message codes. You write you code to handle errors/messages a specific way. If an error/message occurs that would normally mean the system is up to date, but it is caused by something else entirely, then of course the software is going to report what it was designed to do. If the software is looking for an update, but an overload on the server is reporting no new update available, then the software is going to report back as being up to date.

The important thing to remember is, Eset is aware of the issue and are working to get it fixed.
Something similar happened awhile back, but they fixed it then as fast as possible and they are doing the same thing now.

And keep in mind, NOD32 has one of the best track records in the world when dealing with threats and having out-dated definitions. It's heuristics engine has pushed it to the top of the list for a reason. Just because your system is reporting the definitons being a few days old, doesn't mean your system isn't protected. The definitions help, but the heuristics engine has a great track record of getting baddies without the definition.

 

Re: With flawed design, problems will not become history

Except that many of us have to disable heuristics or deal with an unresponsive system.

 

Re: With flawed design, problems will not become history

The only way how to do load balancing is by changing update.ver with information about available version. For this reason, the program can only inform that it's up to date. In order for the program to return a correct message, a new system supporting the logic would need to be implemented into the program. I have an idea of how this could work, but it would require support both on the server and the client. We'll see if we could manage it until the next major update, but generally we don't expect such a problem to recur with v3, especially with more and more users upgrading to it from v2 and increasing number of update servers. This was the very first such an enormous update in the history of NOD32.

 

Re: With flawed design, problems will not become history

That is how I handle updates with my software as well.
But, not that this is what happened, but if I open my program and click "Check for updates" and my web server isn't responding or its locked up, or any number of reasons, my software is going to report back that it is up to date because there is no new information to compare it too.
Of course my setup is miniscule compared to Esets, but I"m sure it is some what on the same path.

This is the largest update I've seen in all my years of being a reseller.

 

Re: With flawed design, problems will not become history

I, too, have never seen more than 100,000 mostly generic signatures added in one update

 

Re: With flawed design, problems will not become history

Did you bother to test them? or just 5 out of the 100,000?

 

Re: With flawed design, problems will not become history

How difficult is an if statement seriously? I mean if server is up then download else printf "Server is down".

 

Re: With flawed design, problems will not become history

Its not that simple. File transfer is more than just black and white. Plus a server being "down" doesn't necessarily mean it is not functioning. It could just be hung. It could be overloaded. It could have a bandwidth exceded issue. there are a bunch of different things and reporting "Server is down" when it is actually not would only cause another flood of new threads on the forums with people asking about them, asking if eset is under attack, asking if their configuration is messed up, etc..

 

Re: With flawed design, problems will not become history

is there a list of the signatures added anywhere, or was it too large to list on the updates page?

 

Re: With flawed design, problems will not become history

No, a full list is not disclosed. I think it'd be too large to fit anywhere

 

Re: With flawed design, problems will not become history

If I understand what you are saying - to balance load, on some (or all) servers, update.ver is changed to incorrect(older) one? This would be theoretically acceptable - I would happily wait few days till the update is available, if I knew that "no update necessary" part is correct (that is - new update is not released due to some new massive threat) and only "your version is up to date" part is wrong (not a big deal). It would then be enough to release small updates in case of serious threats and everybody would be protected.

However, I have serious doubts if above is really the case. As I have mentioned numerous times before, I have seen NOD32v2 displaying that it is up to date, even with signature version more than a year old! And, I have my reasons to believe that NOD32v3 is the same - I have seen this same message from v3, with more than a month old signatures.
So it means - either update.ver is changed to something few years old (would not be a good idea) or the actual way NOD works is a bit different from what you described.

If a user with really old signatures is trying to update, he should be let through, whatever the server load.