Jump to content

kingoftheworld

Members
  • Posts

    191
  • Joined

  • Days Won

    1

Posts posted by kingoftheworld

  1. On 12/16/2022 at 12:22 PM, Marcos said:

    It's a question for Microsoft to determine what was different since ESET was not the only vendor affected.

    The update generates a lot of disk activity inside C:\Windows\WinSxS\Catalogs by Cl.dll checking file hashes (generates more than 20,000 file opens).

    I don't know that it is a question for Microsoft to determine.  From the linked thread, only one other AV vendor was mentioned.  A bigger question is why is ESET not attempting to restart itself given the settings for the service is to always attempt to restart itself?

  2. 7 hours ago, rtaranov said:

    This identifier is assigned to a specific problem found in the ESET product by the user/specialist during work or testing.

    On the page of known issues you see only the description of the problem itself without the identifier.

    I understand that it is a bug tracking ID.  I am asking what the specific problem is as I am tracking a couple that I haven't reported to support yet. 

  3. 1 hour ago, Peter Randziak said:

    Hello guys,

    Direct Cloud communication module 1124 is available on pre-release update channel.

    The communication protocol has been simplified in it to improve compatibility especially with http inspection solutions.

    If you use any and you are still receiving warnings like

    try to switch to pre-release updates and let us know if the Direct Cloud communication module 1124 resolved the issue for you.

    Peter

    While I can't switch my entire environment to the pre-release, I did change my test machines and it resolved the issue.  How long will it be the pre-release before going to the main channel?

  4. 5 hours ago, Marcos said:

    It doesn't have to be necessarily caused by Fortigate but by any firewall or proxy that can block or intervene in the communication when performing http/https inspection.

    Judging by the number of posts in this page, is ESET planning on any fixes on their end to change the response from these servers to avoid this issue?  As someone from ESET previously mentioned, there was a change in the LiveGrid components between versions 7 and 8 which is when this started becoming a problem.

  5. 2 hours ago, FrenchItDirector said:

    Looks like this method :

    image.thumb.png.d4a7108c33c7f27462c036795ecd4a50.png

    is the quickest way to mitigate the threat. Of course updating endpoints is necessary.

    Quick question : why did I find this information on twitter and was never warned by Eset ? Looks like a pretty serious vulnerability, worth being advertised to Eset customers.

    They emailed customers about it. You should probably verify you are on the mailing list for product updates.  

  6. Has there been any information on if clients that only use a mirror server will receive these updates in v8 and v9? I know the question was posted in another thread a while back, but I don't think there was ever a response.  We have a number of clients that are not accessible to the Internet and only pull updates from an internal server and we would like for them to auto-update like the rest of our environment. 

  7. 6 minutes ago, steingat said:

    As an update, as I am not sure what changed, but all of our problematic endpoints seem to have been fixed and none that are currently connected are reporting a cloud connection problem.  This seems to have happened with in the last few hours

    I have seen a noticeable declines as well.  We are down maybe 300 from the 2000 we were seeing.  

  8. 33 minutes ago, Marcos said:

    The correct way is to tracert c.eset.com. Do not use a particular server which is located in EU.

    Thank you.  Just ran on one of my impacted machines and it successfully makes it to h1-c04-s.eset.com [91.228.165.44].  I am leaning back toward the problem being with this version as another machine with the issue running 8.1 was upgraded to v9 and the problem goes away.

  9. 34 minutes ago, itman said:

    Yesterday I did a tracert on a domain Eset uses for its mPico updates, etc., h1-epnsbroker03.eset.com.

    My ISP is AT&T and I use their DNS servers. Routing in the U.S. stayed pretty much through AT&T servers. Then to servers in Germany, Slovakia, and finally an Eset server.

    BTW - I never once have had an issue with LiveGrid connectivity.

    Maybe ESET will bring up some servers in the US to handle some of this communication given their large number of customers in the States.

  10. 20 hours ago, itman said:

    My own opinion is the only way to get to the bottom of this is by using tracert.

    The ideal test scenerio is on an installation using v8.1 where some connect OK and some do not. "My gut is telling me" Internet backbone relay server/s are the culprit.

    Further testing says your theory may be correct.  On some machines (working machines) the routes to the LiveGrid servers leave the US, go through Denmark and onto ESET.   On the ones that aren't working, the route appears to leave the US, head through Russia and some other locations but don't appear to make it to ESET.  Curious if anyone else is seeing similar. 

  11. 2 minutes ago, itman said:

    My own opinion is the only way to get to the bottom of this is by using tracert.

    The ideal test scenerio is on an installation using v8.1 where some connect OK and some do not. "My gut is telling me" Internet backbone relay server/s are the culprit.

    That is a good possibility.  Given that most (or all) of the IPs go to Europe which is a long way for at least me in the US. 

  12. I think there is something more going on here with the LiveGrid issue that many seem to report.  We had a large number of clients (1000+) running EEA 7.4.2041 for about 1 year without any issue.  I upgraded everything to 8.1.2037.2 and most seem to be reporting that it is unable to connect to LiveGrid.  I checked each of the domains listed on the KB to ensure they are reachable and that correct DNS resolutions are happening and everything was good.  Going off of the knowledge shared on the forum of the communication change with 8.1, I went ahead and upgraded one of the clients with the issue to v9.  This fixed the issue.   Assuming v9 uses the same communication mechanism as v8.1, I lean toward there being something wrong with v8.1 rather than a local network issue.  I have clients running v8.1 with the issue and without the issue that are running the exact same image, behind the same firewalls, configured exactly the same.  

×
×
  • Create New...