Downloaded file is damaged...

Netcabo's fault. Connected to Clix's ADSL, aint no prob.
When I switch to Netcabo, it restarts. "Downloaded file is
damaged" or "Ficheiro baixado danificado"
Dump Netcabo

 

But this is stupid, because the others program works fine...

Thanks

 

not every other program.
I had the same problem with Eudora e-mail client,
sometimes checking mail just fine, other times giving me
a similar error: "Unable to connect to SMTP server"
when I had mail to send. Odd, POP3 connection always
worked fine. That's Portugal...

 

I only get problems with NOD32.
And besides, as you know, Portugal was not a rich country, but could be improved in a lot of things...

Fica bem

 

I have the same problem....Downloaded file is damaged....I have tried uninstalling, re-installing, contacting tech support and contacting my service provider. They say it is not a problem from them...what else can I do? I am running the paid for version and only have version 1.578(20031212). I am beginning to think I wasted my money! I have only had this problem recently....when I was running the trial version it was fine, and it was also updating regularly (on dial-up) when I first changed to paid version.

 

Right now I sent an e-mail to netcabo, the Portuguese cableTV also acting as an ISP. As soon as they will answer me (shall they do it), I'll post it here.
I advised much people to buy NOD32, based on it's awards, my press readings, my trial, it's lightweight, user friendly interface, ... and price.

Now I don't feel comfortable since people using netcabo always (99%) of the times they click update, they get "download file damaged". It's not nice to hear What the sheet did you tell me to buy? If I haven't yet payed... My hope is netcabo will assume they are culprit.

Meanwhile I've been further investigating. After install, you have a folder named updfiles. While trying to update for the very first time, one can see there only two files zero lenght: update.ver e nodxxxx.nup. NOD32 windows displays "download 0/1942KB". FWIW, you ESET people

 

OK I've just managed to do an update, with only one "Downloaded file is damaged" message, and one "server connection failure". But...I am now updated! Maybe it is a service provider problem?

 

Same problem here.

Optus Cable Australia, its obviously a NOD issue. Even bodgey AVG Free would update (when one could get a connection) without such errors, it is a MAJOR issue that should be fixed now, not in weeks/months etc.

 

Obvious? Does anyone connecting to the internet via Dial-up or ADSL get the error message "Downloaded file is damaged?

TIA

 

Did you've some reply from NetCabo, Angelo?

 

Nope, and no much hope. I am not a netcabo user, I sent the mail from home and I don't feel comfortable emailing from some netcabo's customer friend's mail after "making" them buy NOD32.

Also from previous posts I see the problem doesn't only happen with Portuguese net cable users, and Spoonfed is right. "it is a MAJOR issue that should be fixed now, not in weeks/months".

If you want to make us a favour, here's the mail I sent them, cos I believe you're Portuguese and a netcabo customer:


<beautiful portuguese language>

Exmos Senhores


Tenho instalado em diversos computadores de pessoas amigas um software antivirus,
o NOD32 (http://www.nod32.com).
Trata-se de um software pouco conhecido, mas que nos testes da prestigiada e independente
revista Virus Bulletin, desde Junho de 1998, nunca falhou um único virus "In the Wild", virus
ou worms para os quais os produtores deste tipo de software ainda não lançaram "vacinas".

Tenho-o feito em variadas plataformas e em máquinas que se ligam à internet também de
variadíssimas formas; dial-up analógico, ADSL (sapo e clix), ou o v/ netcabo.

Nas máquinas que se ligam via netcabo, 99% das actualizações falham com a mensagem
"Arquivo baixado danificado", ou nas máquinas com o AV em Inglês, "Downloaded file
damaged". A actualização é feita online para servidores como u1.eset.com, u2.eset.com,
u3.eset.com, u4.eset.com, www.esetsoftware.com, www.nod32.com, www.eset.sk.

Agradecia que me informassem se de alguma forma barram o acesso a estes servidores,
se será um problema de cache nos v/ servidores, ou se passará pela forma como o AV
efectua as actualizações. A ESET tem para download uma versão trial de 30 dias em
http://www.nod32.com/download/trial.htm.


Sendo o que se me oferece no momento, e ficando a aguardar a v/ prezada resposta,
subscrevo-me com os meus mais respeitosos cumprimentos.

De V. Exas.,
Atentamente,
--
Angelo Lopes da Silva
Porto, Portugal

</beautiful portuguese language>


Will you write them?

Abraço,

 

I already sent an e-mail to the NetCabo and I'm waiting for a reply...
when I receveid, I will put here

Thanks

 

I never get the "Downloaded file is damaged" using a cable connection from my US location in Ft. Worth, Texas.
Nor does one of my grown kids using a dial-up connection.

If you do a tracert do you see some really high ping times or "Time Outs" along the route from you to the ESET update servers?

Below are my tracerts for reference.


D:\Documents and Settings\Administrator>tracert u1.eset.com

Tracing route to u1.eset.com [62.168.97.102]
over a maximum of 30 hops:

1 1 ms 1 ms 1 ms homeportal.homeportal.2wire.net [172.16.0.1]
2 10 ms 8 ms 10 ms 10.198.18.1
3 10 ms 11 ms 9 ms 66.169.205.145.ts46v-19.pkcty.ftwrth.tx.charter.
com [66.169.205.145]
4 11 ms 13 ms 13 ms er73-01.mhe.ftwrth.tx.charter.com [66.169.96.250
]
5 19 ms 14 ms 13 ms 12.124.219.29
6 15 ms 14 ms 14 ms gbr1-p70.auttx.ip.att.net [12.123.133.22]
7 22 ms 23 ms 18 ms tbr2-p013901.dlstx.ip.att.net [12.122.2.109]
8 17 ms 18 ms 17 ms ggr2-p390.dlstx.ip.att.net [12.123.17.85]
9 19 ms 18 ms 20 ms att-gw.dfw.sprint.net [192.205.32.70]
10 45 ms 45 ms 50 ms sl-bb20-chi-11-0.sprintlink.net [144.232.18.57]

11 54 ms 45 ms 45 ms sl-bb21-chi-15-0.sprintlink.net [144.232.26.2]
12 65 ms 64 ms 71 ms sl-bb22-nyc-15-0.sprintlink.net [144.232.9.148]

13 65 ms 66 ms 65 ms sl-bb20-nyc-14-0.sprintlink.net [144.232.7.105]

14 132 ms 131 ms 131 ms sl-bb22-lon-12-0.sprintlink.net [144.232.9.162]

15 152 ms 132 ms 138 ms sl-bb20-lon-12-0.sprintlink.net [213.206.128.52]

16 140 ms 140 ms 140 ms sl-bb21-par-14-0.sprintlink.net [213.206.129.70]

17 138 ms 143 ms 137 ms sl-bb20-par-15-0.sprintlink.net [217.118.224.33]

18 149 ms 148 ms 182 ms sl-bb21-fra-13-0.sprintlink.net [213.206.129.66]

19 190 ms 160 ms 182 ms sl-bb21-vie-2-0.sprintlink.net [213.206.129.122]

20 162 ms 159 ms 160 ms sl-gw10-vie-15-0.sprintlink.net [80.66.136.37]
21 164 ms 162 ms 159 ms sle-gtshu-14-0.sprintlink.net [80.66.137.30]
22 162 ms 166 ms 162 ms p2-2.sk.gtsce.net [195.39.208.130]
23 181 ms 160 ms 160 ms g1-0.gwa.gtsi.sk [62.168.110.49]
24 163 ms 188 ms 161 ms sun.uid0.sk [62.168.97.102]

Trace complete.

D:\Documents and Settings\Administrator>tracert u2.eset.com

Tracing route to u2.eset.com [140.239.119.12]
over a maximum of 30 hops:

1 1 ms 1 ms 1 ms homeportal.homeportal.2wire.net [172.16.0.1]
2 11 ms 11 ms 9 ms 10.198.18.1
3 11 ms 11 ms 11 ms 66.169.205.145.ts46v-19.pkcty.ftwrth.tx.charter.
com [66.169.205.145]
4 11 ms 12 ms 13 ms er73-01.mhe.ftwrth.tx.charter.com [66.169.96.250
]
5 15 ms 15 ms 15 ms 12.124.27.97
6 16 ms 14 ms 15 ms gbr1-p70.hs1tx.ip.att.net [12.123.134.22]
7 23 ms 17 ms 15 ms tbr2-p013401.hs1tx.ip.att.net [12.122.12.145]
8 56 ms 19 ms 19 ms tbr1-cl1.dlstx.ip.att.net [12.122.10.129]
9 20 ms 19 ms 19 ms ggr1-p340.dlstx.ip.att.net [12.122.12.74]
10 23 ms 19 ms 19 ms att-gw.dfw.allegiance.net [192.205.32.226]
11 20 ms 19 ms 26 ms dfw10-core2-so-7-2-0.atlas.algx.net [165.117.192
.73]
12 41 ms 41 ms 45 ms ord10-core1-so-7-0-0-0.atlas.algx.net [165.117.2
00.38]
13 101 ms 64 ms 64 ms jfk11-core2-so-0-2-0-0.atlas.algx.net [165.117.2
00.33]
14 59 ms 58 ms 61 ms jfk11-core1-so-0-1-0-0.atlas.algx.net [165.117.1
92.29]
15 64 ms 63 ms 63 ms ewr10-core1-pos6-0.atlas.algx.net [165.117.50.11
4]
16 66 ms 64 ms 90 ms ewr10-core2-pos7-0.atlas.algx.net [165.117.48.15
8]
17 96 ms 65 ms 63 ms bos10-core1-so-0-3-0-0.atlas.algx.net [165.117.1
92.253]
18 64 ms 63 ms 64 ms 67.89.91.81
19 65 ms 71 ms 71 ms g3-5-dsw1a.bos2.hosting.com [64.55.29.57]
20 71 ms 65 ms 64 ms 64.55.22.237
21 64 ms 67 ms 65 ms www.refdesk.com [140.239.119.12]

Trace complete.

D:\Documents and Settings\Administrator>tracert u3.eset.com

Tracing route to u3.eset.com [82.208.27.3]
over a maximum of 30 hops:

1 1 ms 1 ms 1 ms homeportal.homeportal.2wire.net [172.16.0.1]
2 8 ms 10 ms 23 ms 10.198.18.1
3 11 ms 12 ms 33 ms 66.169.205.145.ts46v-19.pkcty.ftwrth.tx.charter.
com [66.169.205.145]
4 11 ms 11 ms 11 ms er73-01.mhe.ftwrth.tx.charter.com [66.169.96.250
]
5 25 ms 17 ms 15 ms 12.124.27.97
6 48 ms 16 ms 15 ms gbr2-p70.hs1tx.ip.att.net [12.123.134.26]
7 16 ms 15 ms 15 ms tbr2-p013701.hs1tx.ip.att.net [12.122.12.149]
8 20 ms 20 ms 19 ms tbr1-cl1.dlstx.ip.att.net [12.122.10.129]
9 20 ms 23 ms 20 ms tbr2-p013601.dlstx.ip.att.net [12.122.9.162]
10 34 ms 33 ms 37 ms tbr2-cl6.sl9mo.ip.att.net [12.122.10.89]
11 41 ms 41 ms 49 ms tbr2-cl7.cgcil.ip.att.net [12.122.10.45]
12 44 ms 40 ms 42 ms ggr1-p370.chail.ip.att.net [12.123.216.145]
13 40 ms 40 ms 41 ms chi-bb1-pos0-3-0.telia.net [213.248.84.69]
14 64 ms 60 ms 60 ms nyk-bb1-pos0-3-0.telia.net [213.248.80.154]
15 140 ms 141 ms 140 ms kbn-bb1-pos2-1-0.telia.net [213.248.64.21]
16 172 ms 152 ms 151 ms hbg-bb1-pos5-0-0.telia.net [213.248.65.146]
17 167 ms 160 ms 164 ms prag-b1-pos2-0.telia.net [213.248.65.2]
18 160 ms 160 ms 162 ms casablanca-101464-prag-b1.c.telia.net [213.248.7
9.94]
19 162 ms 160 ms 167 ms henry.casablanca.cz [217.11.224.237]
20 162 ms 162 ms 216 ms eset.casablanca.cz [82.208.27.3]

Trace complete.

D:\Documents and Settings\Administrator>tracert u4.eset.com

Tracing route to u4.eset.com [62.168.97.99]
over a maximum of 30 hops:

1 1 ms 1 ms 1 ms homeportal.homeportal.2wire.net [172.16.0.1]
2 13 ms 8 ms 9 ms 10.198.18.1
3 11 ms 10 ms 9 ms 66.169.205.145.ts46v-19.pkcty.ftwrth.tx.charter.
com [66.169.205.145]
4 10 ms 10 ms 16 ms er73-01.mhe.ftwrth.tx.charter.com [66.169.96.250
]
5 14 ms 13 ms 13 ms 12.124.219.29
6 18 ms 14 ms 13 ms gbr1-p70.auttx.ip.att.net [12.123.133.22]
7 20 ms 19 ms 19 ms tbr2-p013901.dlstx.ip.att.net [12.122.2.109]
8 19 ms 17 ms 17 ms ggr2-p390.dlstx.ip.att.net [12.123.17.85]
9 18 ms 20 ms 19 ms att-gw.dfw.sprint.net [192.205.32.70]
10 41 ms 39 ms 39 ms sl-bb21-chi-6-0.sprintlink.net [144.232.8.53]
11 59 ms 60 ms 59 ms sl-bb22-nyc-15-0.sprintlink.net [144.232.9.148]

12 63 ms 58 ms 60 ms sl-bb20-nyc-14-0.sprintlink.net [144.232.7.105]

13 124 ms 124 ms 131 ms sl-bb22-lon-12-0.sprintlink.net [144.232.9.162]

14 130 ms 126 ms 126 ms sl-bb20-lon-12-0.sprintlink.net [213.206.128.52]

15 137 ms 173 ms 133 ms sl-bb21-par-14-0.sprintlink.net [213.206.129.70]

16 133 ms 132 ms 132 ms sl-bb20-par-15-0.sprintlink.net [217.118.224.33]

17 143 ms 142 ms 142 ms sl-bb21-fra-13-0.sprintlink.net [213.206.129.66]

18 152 ms 152 ms 165 ms sl-bb21-vie-2-0.sprintlink.net [213.206.129.122]

19 155 ms 154 ms 154 ms sl-gw10-vie-15-0.sprintlink.net [80.66.136.37]
20 154 ms 154 ms 154 ms sle-gtshu-14-0.sprintlink.net [80.66.137.30]
21 156 ms 154 ms 166 ms p2-2.sk.gtsce.net [195.39.208.130]
22 154 ms 154 ms 155 ms g1-0.gwa.gtsi.sk [62.168.110.49]
23 156 ms 164 ms 156 ms eset.uid0.sk [62.168.97.99]

Trace complete.

 

So it seems it is related to the end users connection location, or perhaps route to the eset servers?

It doesn't make to much sence. One can blame the ISP but ive never had an issue like this before. I'll know with more updates but i think the "u4" server is more reliable in this aspect, ie does not send "damaged files" where the other servers do?

Surely they must be fixing this issue if they want to remain on top? Updates are critical to AV softwares worth!

 

I think that this is more a problem with NOD32 that my ISP or other ISP, because this doesn't happen with others programs, so why this only happens with NOD32!!!

Can some developer of NOD32 say something about this, because we already saw that something is wrong with the servers of NOD32!!!

 

Hi VaMPiRiC_CRoW
I managed to make it work. You may want to give it a try:
Choose a Proxy Server from this list: http://www.aliveproxy.com/
Now, go to Update > Setup > Advanced > Proxy Server > Setup and fill in the IP Address and Port. Click OK > OK > OK > Update now.
It will update. It did it on the internet cable connected computers where previously I always got Downloaded file damaged. Please let us know the results since this does not harm anything

Ping times are high but twice faster than yahoo, and when you grow up with the packet size with -l parameter, yahoo times out much faster. Meanwhile I searched Netcabo for their Proxy parameters, and they never give it. They even teach on how to remove proxy settings when you have Netscape installed!

I only don't now if this is odd or if it is weird

 

Hi Angelo,

I tried and it seems that works...

But it's very boring to use a proxy to have the NOD32 updates working fine...

Thanks

 

Given it apparently works using a proxy, perhaps it is some weird conflict with the ISP's "transparent proxy"

I know Optus Cable here runs a transparent proxy as do many other ISP's. Perhaps a "cached" version of such is being fetched and somehow presenting the errors. I know SOME forums have issues if they do not FORCE refresh or force to get new file/whatever from the source server. If this is it, perhaps NOD needs to implement something like this at their servers?

 

 
> Given it apparently works using a proxy, perhaps it is some weird conflict with the ISP's "transparent proxy"

> I know Optus Cable here runs a transparent proxy as do many other ISP's. Perhaps a "cached" version of such is being fetched and somehow presenting the errors. I know SOME forums have issues if they do not FORCE refresh or force to get new file/whatever from the source server. If this is it, perhaps NOD needs to implement something like this at their servers?

It's not a "NOD32" problem ... it's an "Internet bogging down" problem. Internet bandwidth is being chewed up 24/7 by squillions of worms and viruses and spam ... although some sources claim that 50%+ of the waste is down to idiotic robot-generated "You sent me a virus!" responses from brain-dead antivirus filters. (Brian Martin has a good rant about this on http://www.attrition.org/security/rant/av-spammers.html)

Optusnet seems to be the main culprit/victim in Australia ... we get 10x complaints about Optusnet update failures than all other ISPs combined. (I don't know about "caching" ... maybe someone with a better knowledge of how this works will comment.)
 

 

Rodzilla,

I see your point, but how can it be a bandwidth problem unless its at the NOD server or the route required to access the server.

I can download at 500KB/Sec + from many overseas and local sites so while im not a "fan boy" of Optus (they piss me off in many ways, ie crappy mail services) i don't think its a bandwidth issue to do with Optus.

AVG and VET antivirus auto updats work fine, why doesn't NOD?

PS: NOD32 here at work also, 1500/256 WestNet ADSL, download speeds of updates, 20KB/sec, certainly not a WestNet issue, but at least the error is not there so its not a big deal anyways. Downloads of VET updates to same ISP are 90KB/sec.

 

 
> I see your point, but how can it be a bandwidth problem unless its at the NOD server or the route required to access the server.

Bandwidth choking is affecting the whole Internet ... not just NOD32's update servers. (Haven't you noticed that websites which loaded in a couple of seconds three months ago now take 10/15/more seconds to load ? Running on 1500/256 ADSL, I have a noticeable slowdown on Wilders in 2004 over what it was in 2003.)

> I can download at 500KB/Sec + from many overseas and local sites so while im not a "fan boy" of Optus (they piss me off in many ways, ie crappy mail services) i don't think its a bandwidth issue to do with Optus.

It seems that "something" at Optusnet makes them more prone to dropouts and failed connections on the NOD32 update servers than all other Australian ISPs combined ... but I have no idea what that "something" is.

> AVG and VET antivirus auto updats work fine, why doesn't NOD?

Maybe not as many users are trying to update at the same time. Who knows ?
 

 

So NOD/Eset are not looking into this issue? Is it only Optus that it occurs on? (which it seems no as the thread has it occuring for various ISPs).

Doing a traceroute of servers U1 to U4 reveals U1,2,4 leaveing Aust via Sinapore, and U3 via the states. The rest of the trace reveals substantially different routes, yet the same error can occur on ALL of the servers at random (more often than not). All but U2 server is located in Eastern Europe, ie Cech Republic and Slovakia etc with U2 perhaps in the US (not enough to resolve end of trace).

I will perhaps do a trace tommorrow at work and see how close it is from Westnet vs Optus. Be interesting if their was a local (Australian) server if the same issues would occur.

I guess Eset locally (Aust) must ceratinly be looking into the issue if at minium it affects the 2nd largest Telco/ISP in the country MAJORLY, plus perhaps others?

 

I'm glad I could find a "solution".
Something in Portuguese Netcabo invents "whatever" for HTTP traffic.
So the solution is to overlook those cable company servers and connect to a proxy. This way, cable companies won't identify updates as web traffic and will not place us into problems.
I believe this has nothing to see with cable technology, but with what they do at IP level and upper.

Eset must have experts on this subject, and have to find why and come out with a fix. Nobody can guarantee that the proxy I have configured on Eset properties, tomorrow will still exist.

Eset must also see that when someone set and forget NOD32 will never know they are not updating. You must see the logs to find those update errors, or click Update now to get the "Downloaded file is damaged" warning window.

 

This is very important!!!

I know some of my friend that have installed NOD32 on theirs computers, and when they saw this problem, auto uninstall it...!

It seems that NOD32 is not to give the importance that this problem deserves...

I hope that this will be fixed in a short future...

 

I have to admit this is giving me some concern. My auto update is no longer 100% with this error. Yes I'm with Optusnet, Yes I manually check daily to make sure but I feel from this discussion that NOD32 HQ is not listening. I tell a lot of folks about NOD32 and recommend it but unless NOD32 People start to pay attention and sort this out you are going to loose people. lets not waste a good reputation by not sorting this out 100%

Please