Jump to content

ESET Network Attack Protection (IDS) is non-functional


Recommended Posts

So I have Windows 10 Pro clients all running ESET Endpoint Antivirus v8.1.2031.0. Randomly after restarting their PC's I see one of these alerts fire up in my web console every 2-3 days.

Reading other forum threads (such as -->   

) I don't think I'm an outlier with this. Yes, a reboot resolves the issue each any every time. But asking for my endusers to reboot their PC's after they just did and have gotten back into their business apps isn't reasonable. If this is a known issue, is there a fix via an update or anything?

Link to comment
Share on other sites

I've seen this occasionally and it's always right after a reboot. It usually seems to resolve itself on it's own. Maybe the next time the client "checks in" to the server??

Link to comment
Share on other sites

18 minutes ago, LesRMed said:

I've seen this occasionally and it's always right after a reboot. It usually seems to resolve itself on it's own. Maybe the next time the client "checks in" to the server??

I was wondering if later on the client connecting to the ESET Protect Server would clear the issue. But when I looked a few hours after the initial alert the issue persisted. So for me the only resolution was having the client reboot again. Not the most elegant solution. If there was a remote task that could allow ESET services and modules to be started (if stopped) that would be helpful.  Recently upgraded after having clients on ESET 4.2, and overall find the newer versions much richer functionality-wise and management-wise. Just this one bug being annoying...

Link to comment
Share on other sites

  • 2 weeks later...

This was never resolved for us.  The recommendation to turn on advanced logging was of no use as the reboot cleared the problem on that computer.  Randomly happens every few days.   I chatted with ESET Support and no one can give me a resolution.  Very annoying.

Link to comment
Share on other sites

  • 2 months later...

Back here again. With the amount of sites and endpoints I administer, this is so annoying. Especially since I had policy that automatically reboots the computers daily. So when the user first logs in they have to shut down and restart again. I'd say at least 2-3 computers fall into this trap every single day. 

And there have been client and modules updates rolled out the past few months. You'd think this would be a known issue that could be patched. *sigh*  

Link to comment
Share on other sites

  • Administrators

In order to troubleshoot the issue, we will need you to:
- enable advanced network protection logging under Tools -> Diagnostics
- reboot the machine
- reproduce the issue and make sure the error is reported
- disable logging
- collect logs with ESET Log Collector and provide the generated archive.

Link to comment
Share on other sites

Reading other similar forum posts, this was done by others. Yet the bug still persists. This bug affects machines arbitrarily. So it's not just one particular PC that I would need to perform this on. At more of an enterprise scale this isn't practical. I suppose I could just pick a few PC's, enable logging as directed, and wait to see if it's their turn to fall into this scenario.

Link to comment
Share on other sites

If I were to just enable this logging through ESET Protect policy for all clients, apparently the logging facility is too primitive to provide for rotating circular logs. If the client doesn't encounter the bug quickly enough, then these Wireshark-style PCAP files will be enormous. See below the disclaimer that was in this article --> https://support.eset.com/en/kb7272-enable-firewall-advanced-logging-in-eset-endpoint-products-7x

So there aren't native error logs that would detail why this modular service failed?

Disable advanced logging when you have finished collecting logs

Make sure you disable advanced logging after you collect the logs you need. It will generate a large log file if you forget to disable it.

 

 

Link to comment
Share on other sites

  • 1 month later...

FYI that ever since I deployed the 9.0.2032.2 update to my Windows clients the problem seems to have disappeared. Although the changelogs don't list this as a bugfix, I assume it was. The macOS clients never had the issue.

Link to comment
Share on other sites

Guest
This topic is now closed to further replies.
  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...