Jump to content

rlcronin

Members
  • Posts

    31
  • Joined

  • Last visited

  • Days Won

    1

Posts posted by rlcronin

  1. You might check the settings under Control Panel->Internet Options->Connections->LAN Settings and un-check "Automatically detect settings" if its checked (and you don't actually need Windows to try to figure out your proxy settings automatically). I've seen that cause delays like what you mention.

    --

    bc

  2. I've had a similar experience with the last two Windows 10 fast-ring insider builds, although in my case it wasn't all connectivity that was lost, just https connections didn't work until I uninstalled and reinstalled. Maybe related. Maybe not. I don't expect eset to do anything about it in my case since I knowingly opted for the fast ring, so anything that breaks is my responsibility to deal with myself.

    --

    bc

  3. What am I missing here? The ESET webpage is offering the multi device security product for 6 devices for 1 year for $42.49. It seemingly includes the full NOD32 product (as well as the Firewall and mobile product). Yet if I ask for the price for a 1 year license for NOD32 for 6 devices, I am told it is $149.94. If I get the multi-device product, am I really getting the same NOD32 that I'd have to pay $149.94 for the same number of devices? How does that make any sense?

    --

    bc

  4. If the past is any indication of the future, I'd expect a v9 beta in August or so and a general release in late October or early November (although that seems to have been tied more to new Windows releases that anything else, so if the rumors are true about a Fall general availability of Windows 10, perhaps it will be earlier this year).

    --

    bc

  5. And you haven't modified the VSD update task?

    Maybe a workaround could be to modify this task so that it e.g. will try to update every 20 minutes.

     

    However your assumption could be right:

    Could it be, that NOD32 is quicker to check internet than Windows opens WLAN connection and gets stuck there after first unsuccessfull attempt?

     

    Maybe you have a similar issue like the one discussed some time ago in another thread:

    Delay Update Attempt?

     

    There are also useful instructions how to test this, so maybe you should follow the instructions for the "ping test" from @Aryeh Goretsky to find out whether your assumption is true.

    ... an issue that was never resolved for what its worth. Sigh.

    --

    bc

  6. 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

  7. 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

  8. 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
  9. 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

  10. 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

  11. 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

  12. Researching this further, I've discovered (and tested) a workaround for this issue. I'm posting it here in case anyone else has the issue and would like to get around it. I'd still like some kind of fix for this in nod32, although since the cause of this is a less-than-ideal Windows design decision regarding how to deal with DisplayPort devices when they get turned off, I'd understand if ESET shrugged it off as a Microsoft issue.

     

    Here's the advice I found. It did work for me. However since it turns off USB selective suspend altogether, it can have possibly undesirable side-effects depending on the stable of USB devices you have and whether or not disabling the ability to selectively suspend them would cause an impact for you (e.g. as it might on a laptop running off battery). Why exactly a setting for *USB* selective suspend has an effect on how Windows deals with a non-USB DisplayPort monitor I'll leave to you to scratch your head about what Microsoft was thinking when it did this! Oh and despite the fact that the advice talks about Windows 7, it works for Windows 8.1 as well.

     

    Go to Control Panel, Power Options, Edit the plan you use by clicking Change Plan Settings, once here click Change Advanced Power Settings. Once there, go to USB Settings, open the menu by clicking the + open the next menu named USB Selective Suspend Setting and disable it. Once this is disabled Windows 7 will no longer adjust your display setup when a display is turned off.

  13. I didn't intend to imply it was that serious. In the grand scheme of things, I'd classify it as a minor annoyance (and doubleclicking the .reg file I created to apply the fix isn't that much of a burden). But life would be ever so slightly more fun if I didn't have to deal with this, so if sometime there's a rainy day with nothing better to do, maybe someone at Eset could have a wee look at it. Thanks.

    --

    bc

  14. I used to connect my monitor to my PC with a standard (dual-link) DVI cable. I recently switched to a DisplayPort cable. Ever since, when my PC turns itself on overnight to run various scheduled tasks (at which time the monitor is OFF), if a nod32 update comes through during the time it is up, the next morning when I wake the PC up for my work day and another nod32 update comes through, the alert that usually pops up in the lower right corner of the display instead pops up in the middle of the screen (at about the point that the lower right corner WOULD be if the monitor resolution were standard VGA). I presume the display being off at the time the overnight update comes in makes nod32 think the screen is standard VGA and so it adjusts the alert position accordingly.

     

    To restore the alert to where I want it I have to edit the registry and set the DesktopAlertPosition1 and DisplayAlertPosition2 to hex ffffffff. I suppose I could avoid it altogether if I were willing to leave the monitor on all the time, but that would waste electricity and I am loathe to do that.

     

    This is annoying!

     

    It'd be nice if this could be fixed so that it didn't happen in the first place, but if not, it'd be nice if the ResetWindowLayout command could be enhanced to reset the alert position, perhaps optionally (so those who have deliberately put theirs in a non-standard place and like it that way don't get annoyed).

    --

    bc

  15. Same here with an asus RT-ac66u

    Fixed it by adding to list of address's excluded from scanning

    Well half fixed it. Sometimes the pages are still slow to load.

    I found that adding the router's address under Web and Email->Protocol filtering->Excluded IP addresses->Add IPV4 address->Single Address->192.168.1.1 completely fixed the issue for me.

     

    I have sent numerous traces to Eset and received promises they'd follow up, but to date there has been none. I suspect there are simply bigger fish to fry, especially as there is such a simple workaround. I still hold out hope that Eset will get around to  looking at this on that rainy day when there's nothing better to do. This is definitely a new behavior in V7. I discovered this problem back when I first installed the V7 beta. Reverting to V6 made it go away. I reported it back then and hoped it would be fixed before V7 was shipped. Alas, it was not to be.

    --

    bc

  16. Dr Teeth,

     

    Do you mean that you haven't had to add the router IP to the exclusion list? I'm using an RT-N66U with Merlin 3.0.0.4.372.31 and unless I exclude it the web interface hangs with partially loaded pages, corrupts those that do load and often fails to execute tabs or links to other settings pages. Once I exclude it, everything works fine..

    Ditto (except that I am on Merlin's latest, 3.0.0.4.374.35_2). I am happy to help debug this (at least today, I won't have time the rest of the week).

    --

    bc

  17. You need to enter the router address as an excluded address under Protocol Filtering in EAV setup. 

    I found the same, but the question is, WHY? What is the router doing, exactly,  that is causing ESET to behave this way? I submitted some wireshark traces of this in response to a request from Marcos during the beta period and never heard anything back.

    --

    bc

×
×
  • Create New...