Jump to content

Recommended Posts

Posted

We have a strange problem with mirror tool.

Whenever a mirror task gets interrupted for whatever reason. Subsequent mirror tasks run incredible slow. This is absolutely reproducible.  Only chance to recover from this is to reboot the computer.

Is this a known problem and is there any workaround for that?

THX for you help.

Posted

It is even worse.

Running the tool the first time runs without problem. Running it a second time is getting incredible slow (hangs)? To recover from it you have to reboot the machine.

  • ESET Staff
Posted

Would it be possible to check from which server/IP address is data downloaded? We have seen such behavior in case different data centers were used, especially US datacenters might be slow in case MirrorTool is executed in EU and vice versa.

Are you using MirrorTool to create offline update mirror for products, or offline repository to be used in ESMC for deployment?

Posted (edited)

We are doing both. Currently we are trying to mirror repo.

Downloading is done from 91.228.167.23 which worked fine for one msi file. Then for what I can see on the next msi it switched to 91.228.167.25 and stall again.

Cheers.

 

Edited by offbyone
Posted

Same thing again today

91.228.167.25 -> slow
91.228.166.23 -> fast

To circumvent the problem I set --repositoryServer to hxxp://91.228.166.23/v1 which seems to work.

 

  • ESET Staff
Posted
On 6/18/2020 at 9:29 PM, offbyone said:

Same thing again today

91.228.167.25 -> slow
91.228.166.23 -> fast

To circumvent the problem I set --repositoryServer to hxxp://91.228.166.23/v1 which seems to work.

 

Could you please provide us tracert or similar logs that would show us your network routing to those datacenters? We are aware of one similar issue, occurring when specific telecommunication operator (global company from Germany...) is used.

Posted
Routenverfolgung zu 91-228-167-25.ptr.eset.com [91.228.167.25] über maximal 30 Abschnitte:

  1    <1 ms    <1 ms    <1 ms  XXX.XXX.XXX.XXX
  2     5 ms     4 ms     5 ms  p3e9bf089.dip0.t-ipconnect.de [62.155.240.137]
  3    12 ms    18 ms    12 ms  pd9ef2ca2.dip0.t-ipconnect.de [217.239.44.162]
  4    14 ms    14 ms    13 ms  80.157.201.198
  5    14 ms    14 ms    14 ms  be3187.ccr42.fra03.atlas.cogentco.com [130.117.1.118]
  6    19 ms    18 ms    18 ms  be2960.ccr22.muc03.atlas.cogentco.com [154.54.36.254]
  7    25 ms    25 ms    25 ms  be3462.ccr52.vie01.atlas.cogentco.com [154.54.59.181]
  8    31 ms    27 ms    28 ms  149.6.174.42
  9    26 ms    26 ms    26 ms  91-228-167-25.ptr.eset.com [91.228.167.25]
Routenverfolgung zu 91-228-166-23.ptr.eset.com [91.228.166.23] über maximal 30 Abschnitte:

  1    <1 ms    <1 ms    <1 ms  XXX.XXX.XXX.XXX
  2    18 ms     5 ms     4 ms  p3e9bf089.dip0.t-ipconnect.de [62.155.240.137]
  3    26 ms    26 ms    26 ms  pd9ef2e3e.dip0.t-ipconnect.de [217.239.46.62]
  4    26 ms    26 ms    26 ms  80.150.170.82
  5    26 ms    25 ms    26 ms  dupdevs-static-222.213-81-253.telecom.sk [213.81.253.222]
  6     *        *        *     Zeitüberschreitung der Anforderung.
  7     *        *        *     Zeitüberschreitung der Anforderung.
  8    30 ms    31 ms    30 ms  91-228-166-23.ptr.eset.com [91.228.166.23]

 

Access Provider is "Deutsche Telekom"

  • ESET Staff
Posted
8 hours ago, offbyone said:

Access Provider is "Deutsche Telekom"

Thanks for confirmation. It is currently in analysis whether we can somehow resolve this issues, which seems to be well known and affecting not only ESET infrastructure. See for example this document: https://www.cogentco.com/files/docs/news/press_releases/Cogent_Sues_Deutsche_Telekom_for_Congesting_Internet_Connections.pdf

  • ESET Staff
Posted

There has been a few changes implemented in DNS servers that should possibly help with this case, as problematic data center should be used only as a fallback for connections from Germany.

Posted (edited)

From here it still works very unreliable.

Since yesterday I try to create an offline repro without success. On every attempt it is interrupted at a different file with the message.

Error: Downloading file : ......

Error occured.

Cheers.

Edited by offbyone
  • 3 weeks later...
Posted

Seems that indeed this is a problem with one carrier in Germany.

We have implemented ESET for two customers meanwhile which use a different carrier in Germany and there we have no problems.

 

  • 4 weeks later...
Posted

Will this ever be fixed?

On every customer we implement ESET which uses Deutsche Telekom as provider it is a mess to get an offline repo, as it nearly always fails with errors.

Sometimes you need about 20 attempts to get a repo which is complete.

Cheers.

  • ESET Staff
Posted

I would recommend to contact your local distributor, as this would probably require more significant changes in infrastructure - which might get higher priority in case there will be more such customers in region.

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

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