Jump to content

Small bug with "Use direct connection if proxy is not available"


Recommended Posts

We have ESET PROTECT VA and we're using it's proxy without issues. I wanted to do some experiment. Using iptables on server i blocked connections from my IP to port 3128 so my PC can't connect to proxy. I wanted to check if ESET Endpoint Security (v9.1.2051.0) would really use direct connection. And what I found out during testing was very weird. When I clicked on "Check for updates", it would try to connect to proxy for ~4 minutes and after those 4 minutes it would connect directly to eset servers and update just fine. I think that 4 minutes are much too long, especially since it receives "ICMP Destination unreachable (Port unreachable)". Here's a screenshot from wireshark, you can see it constantly tries to connect to proxy, receives Destination unreachable and tries again, and again, and again, and again, instead of just doing direct connection after first failed attempt.

Can you tell me something about this behavior? Is this as intended? Can it be changed? Will you classify it as a bug and fix it?

 

Clipboard02.png

Link to comment
Share on other sites

  • Administrators

As far as I know, the product goes through all update servers first and then falls back to using direct connection so yes, the "lag" is expected.

Link to comment
Share on other sites

But this is not a problem with "ESET can't connect to update server", it a problem with "ESET can't connect to proxy server". ESET should be aware that it can't connect to proxy server, but as it seems right now (like you explained) it doesn't know it and assumes it can't connect to update server and tries another one. From my perspective, it's a design flaw that can be called a bug.

Link to comment
Share on other sites

  • Administrators

Please carry on as follows:

  1. Enable advanced logging under Help and support -> Technical support
  2. Run update to reproduce the issue
  3. Stop logging
  4. Collect logs with ESET Log Collector and upload the generated archive here.
Link to comment
Share on other sites

  • Administrators

According to the logs it takes 1,5 to fallback to a direct connection. Had there been a new module update, an automatic update task would have downloaded it after 1,5 minute. The update progress bar lasts longer because also a check for pico updates and program updates is performed when update is run manually.

Link to comment
Share on other sites

Thanks for explanation. I still think it would be viable to change update procedure. Eset should detect that it can't connect to proxy and switch to direct connection immediately. That way the whole process should be much faster, I know that 99,99% of users won't notice the difference.

Link to comment
Share on other sites

  • Administrators
33 minutes ago, kapela86 said:

Thanks for explanation. I still think it would be viable to change update procedure. Eset should detect that it can't connect to proxy and switch to direct connection immediately. That way the whole process should be much faster, I know that 99,99% of users won't notice the difference.

The delay is there to give the system enough time to establish an Internet connection on system start.

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

 Share

  • Recently Browsing   0 members

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