Bugzilla – Full Text Bug Listing
| Summary: | [transport] Can't connect to eclipse.org | ||
|---|---|---|---|
| Product: | [Eclipse Project] Equinox | Reporter: | Peter Quodling <peter> |
| Component: | p2 | Assignee: | Pascal Rapicault <pascal> |
| Status: | CLOSED WORKSFORME | QA Contact: | |
| Severity: | major | ||
| Priority: | P3 | CC: | bsd, guido, henrik.lindberg, james.beard, joonas.koivunen, matti.jarvinen, pascal, peter, pwebster, remy.suen, support |
| Version: | 3.6 | ||
| Target Milestone: | --- | ||
| Hardware: | Macintosh | ||
| OS: | Mac OS X - Carbon (unsup.) | ||
| Whiteboard: | |||
|
Description
Peter Quodling
Perhaps this is just a timing thing or related to server-load at eclipse.org? I just downloaded that package from the website and tried to update and it found the repositories ok. Can you try again? Thanks. I have tried this about 4 times now. Most recently I have tried just doing an "Update" rather than adding software fromt he repositories. I got - "Problem occured" some sites could not be found see the error log for more details. ANd in the detail box, I get Some sites could not be found. See the error log for more detail. Unable to read repository at http://download.eclipse.org/eclipse/updates/3.6/content.jar. Read timed out Unable to read repository at http://download.eclipse.org/webtools/repository/helios/content.jar. Read timed out Unable to read repository at http://download.eclipse.org/tools/mylyn/update/helios/content.jar. Read timed out Unable to read repository at http://download.eclipse.org/releases/helios/content.jar. Read timed out So, can I see download.eclipse.org? peter-quodlings-macbook-pro-15:tmp pquodling$ ping download.eclipse.org PING download.eclipse.org (206.191.52.47): 56 data bytes 64 bytes from 206.191.52.47: icmp_seq=0 ttl=114 time=276.561 ms 64 bytes from 206.191.52.47: icmp_seq=1 ttl=114 time=277.418 ms 64 bytes from 206.191.52.47: icmp_seq=2 ttl=114 time=276.889 ms 64 bytes from 206.191.52.47: icmp_seq=3 ttl=114 time=278.303 ms 64 bytes from 206.191.52.47: icmp_seq=4 ttl=114 time=277.994 ms ^C --- download.eclipse.org ping statistics --- 5 packets transmitted, 5 packets received, 0.0% packet loss round-trip min/avg/max/stddev = 276.561/277.433/278.303/0.652 ms But, I thought, can I get to the files? peter-quodlings-macbook-pro-15:~ pquodling$ cd tmp peter-quodlings-macbook-pro-15:tmp pquodling$ wget http://download.eclipse.org/eclipse/updates/3.6/content.jar--2010-09-16 08:36:24-- http://download.eclipse.org/eclipse/updates/3.6/content.jar Resolving download.eclipse.org (download.eclipse.org)... 206.191.52.47 Connecting to download.eclipse.org (download.eclipse.org)|206.191.52.47|:80... connected. HTTP request sent, awaiting response... 404 Not Found 2010-09-16 08:36:25 ERROR 404: Not Found. Is this why it is timing out? Is it looking in the wrong place? If so, why, and how to I fix it? You can't see those particular files because they don't exist on the server. There is an ordering for the files that we look for when we connect to a server: - compositeContent.jar - compositeContent.xml - content.jar - content.xml - site.xml So we should be connecting to the server and trying to retrieve the files in that order. I logged in and checked all the folders that you are trying to retrieve the data from and they are all good citizens and have the first (compositeContent.jar) file only. Perhaps someone else on the team more familiar with network issues can comment. INdeed, I find that I can wget compositeContent.jar from the respective directories to my target system - ANd I can unzip it to get the .xml file. (In reply to comment #4) > INdeed, I find that I can wget compositeContent.jar from the respective > directories to my target system - ANd I can unzip it to get the .xml file. Given that I appear to be able to see the right systems on the net, and can access manually the right files - is there a way of a) turning on some form of debug in the P2/Equinox process to work out what is really failing, so that I can fix it, or b) a work around, whereby I can manually install/update what I need to so that I can get some development done.? One probably cause is that you keep hitting mirrors that are not responding as they should. You could try running with: -Declipse.p2.mirrors=false to turn of use of mirrors to see if you then get what you want. The warning you got that modification time was <= 0 indicates that a server is not processing the request as it should - it is supposed to return a correct modification time stamp and the content (or return an error). When a faulty timestamp is returned, the file will be downloaded as if it was later than any cached copy. (In reply to comment #6) > One probably cause is that you keep hitting mirrors that are not responding as > they should. > You could try running with: -Declipse.p2.mirrors=false > to turn of use of mirrors to see if you then get what you want. > > The warning you got that modification time was <= 0 indicates that a server is > not processing the request as it should - it is supposed to return a correct > modification time stamp and the content (or return an error). When a faulty > timestamp is returned, the file will be downloaded as if it was later than any > cached copy. Thanks Henrik. Just one quick question - I am running the 32 bit version on a slightly older MacBookPro, running snowleopard. Firing up eclipse is normally clicking an icon - any ideas on how to activate it from a commandline so as to feed it the above argument? I have tried plugging this line into eclipse.ini in /Applications/DevTools/eclipse/Eclipse.app/Contents/MacOS/ but to no avail. (In reply to comment #7) > (In reply to comment #6) > > One probably cause is that you keep hitting mirrors that are not responding as > > they should. > > You could try running with: -Declipse.p2.mirrors=false > > to turn of use of mirrors to see if you then get what you want. > > > > The warning you got that modification time was <= 0 indicates that a server is > > not processing the request as it should - it is supposed to return a correct > > modification time stamp and the content (or return an error). When a faulty > > timestamp is returned, the file will be downloaded as if it was later than any > > cached copy. > > Thanks Henrik. Just one quick question - I am running the 32 bit version on a > slightly older MacBookPro, running snowleopard. Firing up eclipse is normally > clicking an icon - any ideas on how to activate it from a commandline so as to > feed it the above argument? I have tried plugging this line into eclipse.ini in > > /Applications/DevTools/eclipse/Eclipse.app/Contents/MacOS/ but to no avail. When I need to change things (like amount of virtual memory), I edit the .ini file inside Eclipse.app folder. Afaik. additional -D should go at the end of the file as it is a vmargs -startup ../../../plugins/org.eclipse.equinox.launcher_1.1.0.N20100512-2000.jar --launcher.library ../../../plugins/org.eclipse.equinox.launcher.cocoa.macosx.x86_64_1.1.0.N20100512-2000 -showsplash org.eclipse.platform --launcher.XXMaxPermSize 256m --launcher.defaultAction openFile -vmargs -Xms40m -Xmx512m -Xdock:icon=../Resources/Eclipse.icns -XstartOnFirstThread -Dorg.eclipse.swt.internal.carbon.smallFonts -Declipse.p2.mirrors=false For other hints regarding mirrors see bug 276813 and other bugs mentioned there. For instance, you can see what mirrors are being considered by looking at the sorted mirror list for a particular file: http://www.eclipse.org/downloads/download.php?file=/tools/buckminster/doc/BuckyBook.pdf&format=xml This gives and XML list for a particular .pdf file (note that if you try this in safari you have to check the content with the web developer as it does not show XML content - in FF you see the content immediately. The list you get back is used by p2 - there is a scheme that favours mirrors closer to the top. Anyway - see more info in the mentioned bug how to turn on more detailed debugging if/when required. I have the same problem on a brand new iMac with snow leopard: Mac OS X 10.6.5 Eclipse version: Version: Helios Service Release 1 Build id: 20100917-0705 I've done several re-installs, tried older versions of Eclipse (back to Ganymede) to no avail. -Declipse.p2.mirrors=false does not make a difference either. Someone else suggested that the problem might be the stripped down JDK on the newer Mac OS, so installed the Java Developer pack. That didn't fix it either. The problem ONLY seems to occur when hitting the eclipse.org update sites. Other sites seem to work fine, but since most have dependencies on eclipse.org stuff, no updates complete successfully. The same Eclipse versions on a Windows 7 machine on the same network work just fine. In fact, I got past my roadblock by copying the plugins directory from that Windows system to my Mac. It seems (from this and other reports of this problem I've found) that it's correlated with the latest Snow Leopard releases. I have not seen anyone post a solution/fix yet. I'm running snow leopard as my primary machine for about a year and I have not run into this problem. I'm suspecting that it is triggered by the redirect to cloudfront that are done by the foundation but I have no evidence of that. In which country are you located? Do you have steps to consistently reproduce? Can you monitor traffic to see what is happening? Thx (In reply to comment #10) > I'm running snow leopard as my primary machine for about a year and I have not > run into this problem. I'm suspecting that it is triggered by the redirect to > cloudfront that are done by the foundation but I have no evidence of that. > > In which country are you located? > Do you have steps to consistently reproduce? > Can you monitor traffic to see what is happening? > Thx I am located in Brisbane, Australia. Consistently reproduce. Aboslutely - it doesn't seem to work any other way. Monitoring traffic - can do. With what, looking for what? follows is a traceroute root@pqpbx:/etc/asterisk $ traceroute download.eclipse.org traceroute to download.eclipse.org (206.191.52.47), 30 hops max, 40 byte packets 1 192.168.2.254 (192.168.2.254) 0.800 ms 0.850 ms 0.971 ms 2 lb0.bras2.brs.iprimus.net.au (203.134.103.65) 49.400 ms 49.629 ms 50.038 ms 3 vlan1451.sw01.brs.iprimus.net.au (203.134.98.73) 50.615 ms 51.172 ms 51.344 ms 4 vlan05.csr02.bne.iprimus.net.au (211.27.143.105) 51.831 ms 52.246 ms 52.659 ms 5 ge-1-0-6.csr01.syd.iprimus.net.au (203.134.2.5) 69.953 ms 70.833 ms 74.952 ms 6 irb-5.bsr01.equ.iprimus.net.au (210.50.143.163) 41.164 ms 76.260 ms 67.238 ms 7 xe-5-3-0.sjc12.ip4.tinet.net (173.241.128.13) 218.131 ms 218.464 ms 218.661 ms 8 xe-2-0-0.sjc10.ip4.tinet.net (89.149.184.126) 219.364 ms 219.729 ms xe-10-1-0.sjc10.ip4.tinet.net (89.149.184.122) 220.046 ms 9 te8-7.mpd01.sjc03.atlas.cogentco.com (154.54.10.213) 220.242 ms te3-4.ccr02.sjc03.atlas.cogentco.com (154.54.13.13) 220.701 ms 221.356 ms 10 te3-2.mpd01.sjc01.atlas.cogentco.com (154.54.6.81) 221.093 ms te2-2.mpd01.sjc01.atlas.cogentco.com (66.28.4.73) 221.803 ms te7-2.mpd01.sjc01.atlas.cogentco.com (154.54.41.205) 222.245 ms 11 te0-1-0-5.ccr21.sfo01.atlas.cogentco.com (154.54.2.137) 222.686 ms 222.828 ms te0-1-0-5.mpd22.sfo01.atlas.cogentco.com (66.28.4.181) 223.310 ms 12 te0-2-0-2.ccr21.mci01.atlas.cogentco.com (154.54.6.162) 225.399 ms 241.246 ms te0-0-0-2.mpd22.mci01.atlas.cogentco.com (154.54.6.33) 229.541 ms 13 te0-1-0-2.mpd22.ord01.atlas.cogentco.com (154.54.3.201) 246.138 ms te0-2-0-0.ccr21.mci01.atlas.cogentco.com (154.54.30.157) 246.336 ms te0-1-0-2.ccr21.ord01.atlas.cogentco.com (154.54.25.82) 246.819 ms 14 te0-1-0-3.ccr21.yyz02.atlas.cogentco.com (66.28.4.214) 260.099 ms te0-0-0-2.mpd22.yyz02.atlas.cogentco.com (154.54.7.17) 259.380 ms te0-2-0-2.ccr21.yyz02.atlas.cogentco.com (154.54.27.242) 263.681 ms 15 38.104.158.130 (38.104.158.130) 264.862 ms te0-1-0-3.ccr21.yyz02.atlas.cogentco.com (66.28.4.214) 269.490 ms 273.614 ms 16 38.104.158.130 (38.104.158.130) 272.094 ms * 38.104.158.130 (38.104.158.130) 291.456 ms 17 * * * 18 * * * 19 206.191.0.120 (206.191.0.120) 276.368 ms * 206.191.0.120 (206.191.0.120) 278.992 ms 20 206.191.0.120 (206.191.0.120) 279.329 ms 280.494 ms 280.501 ms 21 * * * 22 * * * 23 * * * 24 * * * 25 * * * 26 * * * 27 * * * 28 * * * 29 * * * 30 * * * I'm thinking that your caches may be in a corrupted state. Before going any further could you please try to delete the folder called: eclipse/p2/org.eclipse.equinox.p2.repository before starting eclipse If this still does not help, then monitoring the traffic could help. I would like to see all the http related traffic when you are checking for updates. I'm especially interested in seeing whether or not you are being redirected. Finally you may also want to check in the .log file in your workspace for any sort of error. As this bug is still NEW I add to this, instead of creating a new one. My problems are with Eclipse 3.6 but the source I guess is the same; download.eclipse.org answers *very* slowly. I cannot seem to find a way to force it use a mirror, for example ftp.ing.umu.se/mirror/eclipse is fast and close. Regarding bug #276813; turning on the advertised .options debug flags (comment #9) and starting with -debug no mirror related or anything related to p2 downloading is printed or appended to workspace log. Looking the process through wireshark, all I can see is requests to download.eclipse.org, zero requests for mirrors. Downloading the latest content.jar (2.07MB has now taken over 30 minutes). Wireshark often reports TCP retransmissions with http connections to download.eclipse.org, something which I have only now seen for the first time (wasn't aware that it had the ability). There are no redirects either. My system is Ubuntu 10.10 based, 8/1 ADSL line. No other networking/Internet problems. In the past we have solved download.eclipse.org problems by using a transparent squid, which rewrote all requests to download.eclipse.org to sweden. As I've now setting this up at my home, I really wouldn't want to install squid just to run eclipse. Attempted fixes: - Add -Djava.net.preferIPv4Stack=true to eclipse.ini - $ sudo /sbin/sysctl net.ipv6.bindv6only=0 - Clear p2 cache like in #12 - Rewrite default repos to be found from sweden* * = does not help as many of the dependencies (when for example installing Spring Tool Suite) while being available at ftp.ing.umu.se are only asked from download.eclipse.org. Side note, when exiting eclipse normally after checking the updates, a message from p2 appears (the only message ever received, apart from timeouts in workspace log): [p2] Mon Mar 21 20:59:34 EET 2011 - [main] Unsaved preferences when shutting down org.eclipse.equinox.internal.p2.metadata.repository.MetadataRepositoryManager This message appears even without me ever accessing preferences in a session. If the mirrors are configured to always redirect back to download.eclipse.org (as suggested elsewhere [1]), then that seems to make download.eclipse.org a single point of failure. Even if the machine itself it fine, if there are any connectivity issues, users are hosed. [1] http://divby0.blogspot.com/2010/07/troubleshooting-eclipseorg-mirrors.html I have also experienced slow downloads (and timeouts) over the last 1-2 weeks. Monitoring downloads I see transfer rate drop to 0 for long periods. I wonder if this could have anything to do with network/routing setup for EclipseCon ? (In reply to comment #13) > There are no redirects either. I just noticed that there is correct mirror usage when you actually start to download updates. However merely checking for updates is the slow one, as it always attempts to check updates from download.eclipse.org. And I was testing/stalking with wireshark only the update checking phase. archive.eclipse.org is almost as slow as download.eclipse.org, same goes for marketplace.eclipse.org (which I might add worked surprisingly well when I tested it for the first time!) -- luckily the search responses are rather small. I've solved this problem at my home using squid which rewrites the requests to download.eclipse.org to go to my nearby mirror; it makes updates fast, except for the WTP which is hosted at archive.eclipse.org. I still think that using squid is not a permanent solution. I have a new MacBook - clean install of Eclipse and I have the exact same problem. I've tried the suggestion -Declipse.p2.mirrors=false without any success. I did change from my ISP's DNS servers to OpenDNS and for the 1st update I tried it seemed to work - but now it's doing the same again - i.e Timeouts and very slow. Has anyone explain what is causing this ? Is it something with the Eclipse version I'm running, OSX, Java ? Thanks Dave (In reply to comment #18) > I have a new MacBook - clean install of Eclipse and I have the exact same > problem. I've tried the suggestion -Declipse.p2.mirrors=false without any > success. I did change from my ISP's DNS servers to OpenDNS and for the 1st > update I tried it seemed to work - but now it's doing the same again - i.e > Timeouts and very slow. > > Has anyone explain what is causing this ? Is it something with the Eclipse > version I'm running, OSX, Java ? Look at what eclipse does using wireshark (or something similar for Mac OS X, if not avail), try downloading the same URL with for example web browser, wget or curl. Compare performance. That way you can rule out java being at fault. You are most likely just experiencing a "bad moment" with the Internet :) I'm still using rewriting local proxy servers for eclipse -- as long as it needs to contact *.eclipse.org for any reason, people with bad connectivity to this eclipse foundation will be suffering. It's not just a bad moment unfortunately - it's been almost impossible to connect to updates for a couple of weeks now. I have a 50mb optical fibre connection and all other random sites appear instantly from by browser while eclipse is struggling. Communication with repository at http://download.eclipse.org/tools/mylyn/update/helios failed. Read timed out (In reply to comment #19) > (In reply to comment #18) > > I have a new MacBook - clean install of Eclipse and I have the exact same > > problem. I've tried the suggestion -Declipse.p2.mirrors=false without any > > success. I did change from my ISP's DNS servers to OpenDNS and for the 1st > > update I tried it seemed to work - but now it's doing the same again - i.e > > Timeouts and very slow. > > > > Has anyone explain what is causing this ? Is it something with the Eclipse > > version I'm running, OSX, Java ? > > Look at what eclipse does using wireshark (or something similar for Mac OS X, > if not avail), try downloading the same URL with for example web browser, wget > or curl. Compare performance. That way you can rule out java being at fault. > > You are most likely just experiencing a "bad moment" with the Internet :) I'm > still using rewriting local proxy servers for eclipse -- as long as it needs to > contact *.eclipse.org for any reason, people with bad connectivity to this > eclipse foundation will be suffering. I suspect something amis on the internet. Sometimes my link to this website is unavailable and sometimes its instant. https://bugs.eclipse.org/bugs/show_bug.cgi?id=325299 I HAVE DONE 3 TRACEROUTES HERE (N.B. MAX 64 HOPS) 1) FROM OSX TO bugs.eclipse.org Traceroute has started… traceroute to bugs.eclipse.org (206.191.52.49), 64 hops max, 52 byte packets 1 192.168.1.1 (192.168.1.1) 4.553 ms 1.232 ms 1.094 ms 2 93.186.152.1 (93.186.152.1) 12.272 ms 10.547 ms 10.836 ms 3 10.0.0.1 (10.0.0.1) 11.284 ms 9.244 ms 10.089 ms 4 ge-2-0-0-xcr1.lsw.cw.net (194.112.69.129) 10.862 ms 8.162 ms 10.529 ms 5 xe-8-1-0-xcr1.lnd.cw.net (195.2.25.125) 10.918 ms xe-0-1-0-xcr1.lnd.cw.net (195.2.4.194) 12.312 ms 16.933 ms 6 xe-5-3-0-xcr1.nyk.cw.net (195.2.25.197) 89.150 ms 86.167 ms 85.194 ms 7 gw-nyiix.bb1.eastyork.primus.ca (198.32.160.89) 98.100 ms 98.744 ms 96.140 ms 8 * * * 9 * * * 10 * * * 11 206.191.0.111 (206.191.0.111) 105.647 ms 103.726 ms 101.578 ms 12 * * * 13 * * * 14 * * * 15 * * * 16 * * * 17 * * * 18 * * * 19 * * * 20 * * * 21 * * * 22 * * * 23 * * * 24 * * * 25 * * * 26 * * * 27 * * * 28 * * * 29 * * * 30 * * * 31 * * * 32 * * * 33 * * * 34 * * * 35 * * * 36 * * * 37 * * * 38 * * * 39 * * * 40 * * * 41 * * * 42 * * * 43 * * * 44 * * * 45 * * * 46 * * * 47 * * * 48 * * * 49 * * * 50 * * * 51 * * * 52 * * * 53 * * * 54 * * * 55 * * * 56 * * * 57 * * * 58 * * * 59 * * * 60 * * * 61 * * * 62 * * * 63 * * * 64 * * * 1) FROM OSX TO download.eclipse.org Traceroute has started… traceroute to download.eclipse.org (206.191.52.47), 64 hops max, 52 byte packets 1 192.168.1.1 (192.168.1.1) 3.711 ms 1.042 ms 0.663 ms 2 93.186.152.1 (93.186.152.1) 8.238 ms 9.206 ms 10.892 ms 3 10.0.0.1 (10.0.0.1) 16.128 ms 8.895 ms 10.416 ms 4 ge-2-0-0-xcr1.lsw.cw.net (194.112.69.129) 12.178 ms 7.963 ms 11.010 ms 5 xe-0-1-0-xcr1.lnd.cw.net (195.2.4.194) 20.295 ms xe-8-1-0-xcr1.lnd.cw.net (195.2.25.125) 36.197 ms xe-4-2-0-xcr1.lnd.cw.net (195.2.25.58) 10.652 ms 6 xe-5-3-0-xcr1.nyk.cw.net (195.2.25.197) 100.476 ms 87.017 ms 87.541 ms 7 gw-nyiix.bb1.eastyork.primus.ca (198.32.160.89) 93.080 ms 94.764 ms 97.619 ms 8 * * * 9 * * * 10 * * * 11 206.191.0.111 (206.191.0.111) 107.053 ms 102.570 ms 101.472 ms 12 * * * 13 * * * 14 * * * 15 * * * 16 * * * 17 * * * 18 * * * 19 * * * 20 * * * 21 * * * 22 * * * 23 * * * 24 * * * 25 * * * 26 * * * 27 * * * 28 * * * 29 * * * 30 * * * 31 * * * 32 * * * 33 * * * 34 * * * 35 * * * 36 * * * 37 * * * 38 * * * 39 * * * 40 * * * 41 * * * 42 * * * 43 * * * 44 * * * 45 * * * 46 * * * 47 * * * 48 * * * 49 * * * 50 * * * 51 * * * 52 * * * 53 * * * 54 * * * 55 * * * 56 * * * 57 * * * 58 * * * 59 * * * 60 * * * 61 * * * 62 * * * 63 * * * 64 * * * 3) FROM WINDOWS (VMWARE) TO download.eclipse.org Microsoft Windows [Version 5.2.3790] (C) Copyright 1985-2003 Microsoft Corp. C:\Documents and Settings\Administrator>tracert download.eclipse.org Tracing route to download.eclipse.org [206.191.52.47] over a maximum of 30 hops: 1 1 ms 1 ms <1 ms my.router [192.168.1.1] 2 11 ms 10 ms 9 ms 93.186.152.1 3 21 ms 10 ms 10 ms 10.0.0.1 4 15 ms 12 ms 10 ms ge-2-0-0-xcr1.lsw.cw.net [194.112.69.129] 5 13 ms 10 ms 10 ms xe-4-2-0-xcr1.lnd.cw.net [195.2.25.125] 6 86 ms 85 ms 85 ms xe-4-2-0-xcr1.lnd.cw.net [195.2.25.197] 7 96 ms 101 ms 96 ms gw-nyiix.bb1.eastyork.primus.ca [198.32.160.89] 8 * * * Request timed out. 9 * * * Request timed out. 10 * * * Request timed out. 11 106 ms 102 ms 99 ms 206.191.0.111 12 100 ms 101 ms 101 ms download.eclipse.org [206.191.52.47] Trace complete. WHY DOES WINDOWS REPORT THAT THE TRACE HAS COMPLETED AFTER 12 HOPS WHEN ODX EFFECTIVELY TIMES OUT ? > WHY DOES WINDOWS REPORT THAT THE TRACE HAS COMPLETED AFTER 12 HOPS WHEN ODX
> EFFECTIVELY TIMES OUT ?
I can confirm the behaviour you saw with traceroute download.eclipse.org with both traceroute and tracepath in kubuntu 11.04.
I did some testing, and found out that "sudo traceroute -In download.eclipse.org" will get to download.eclipse.org finally (just like the windows traceroute).
If you look at manual page of traceroute, under "LIST OF AVAILABLE METHODS", you'll see that by default, traceroute (and tracepath, but not configurable) will send UDP packets (does not require root privs) to port 33434 on destination, hoping for ICMP "port unreachable".
It'd seem that windows traceroute or tracert, what ever it's called nowdays defaults to icmp traceroute, which is "send icmp pings with growing ttl".
No funny business here between operating systems; it could be that download.eclipse.org is configured with a firewall that silently drops other than allowed traffic, whereas ttl icmp will be sent by devices on the route as they conform to the standard.
So - if I understand you we have not made any progress in detecting the nature of the problem ? (In reply to comment #23) > So - if I understand you we have not made any progress in detecting the nature > of the problem ? Well.. I have detected that this is because the update process starts with fetching files from download.eclipse.org. This is done BEFORE any mirror resolution. I do not think that it matters that it could be a routing/traffic priorization problem. You simply cannot build on assumption that master (download.eclipse.org) is more available than its geographically distributed mirrors; the network cables will always be cut. IF the update system would first ask user to select a preferred mirror (either from recently fetched or download-time supplied mirror list) AND it'd then proceed to use this mirror in favor of download.eclipse.org (and perhaps archive.eclipse.org), dropping the need to contact download.eclipse.org at all. AFAIK www.eclipse.org/downloads/download.php is already capable of doing some geopriorization; this could be leveraged to build closest mirrors to try before falling back to download.eclipse.org. But how all the above relates to equinox p2 I haven't got the slightest clue. I've just commented anything I've found here as an effort to help developers when they have time to tackle this problem. Might not be any help at all, just noise. I think that my solution (see comment #c17) works is a step forward allowing devs to think of replacing download.eclipse.org with mirrors. You should try it too, and report your experiences here. It could be that a mirror does not have all the files required from download.eclipse.org. I can confirm that http://ftp.ing.umu.se/mirror/eclipse/ does have all the required files, as I successfully install and update eclipse instances home and at work using rewrite http://pastebin.com/z71XKL5B Joonas, it is interesting that you are mentioning this redirect on to a mirror for the download of initial files because this has been implemented at various points in time and burnt us. The "implementation" consisted in having the foundation servers automatically do a redirect to another mirror, however for some reason some of these mirrors were returning bad bytes and completely prevented any install. Maybe we have a set of trusted (regularly verified) mirrors from the obtention of the necessary metadata can done from. However I still don't see how to resolve the issue of contacting the foundation servers to bootstrap. Today I've tested Indigo RC1 with proxy settings (but from a Windows machine), and everything seems to work fine. At this point I'm not quite sure what else to do on this. Closing for now. Please reopen or open a new bug if the problem still occurs. Didn't work for me today @30.7.2012 ~13:30 Eclipse version Version: 4.2.0 Build id: I20120608-1400 Had to add this to eclipse.ini to get updates working -Djava.net.preferIPv4Stack=true C:\tracert download.eclipse.org Tracing route to download.eclipse.org [206.191.52.47] over a maximum of 30 hops: 1 1 ms <1 ms <1 ms 10.10.10.1 2 1 ms 1 ms 1 ms 192.168.1.1 3 1 ms 1 ms 1 ms 82.215.205.161 4 4 ms 4 ms 4 ms ge0-0-0-410.bbr1.hel2.fi.eunetip.net [213.192.190.137] 5 132 ms 132 ms 132 ms so3-3-0-0.bbr1.nyc1.us.eunetip.net [213.192.191.206] 6 147 ms 147 ms 147 ms gw-nyiix.bb1.eastyork.primus.ca [198.32.160.89] 7 * * * Request timed out. 8 * * * Request timed out. 9 * * * Request timed out. 10 * * * Request timed out. 11 156 ms 159 ms 168 ms 206.191.0.120 12 156 ms 157 ms 156 ms download.eclipse.org [206.191.52.47] Trace complete. Additional information for anyone still having this problem, especially on OSX. Digging a little deeper, there were NoClassDefFoundError/s related to org.apache.commons.httpclient.HttpClient occurring in my DE. I tried many of the suggestions listed on a Mac running Lion, Eclipse 4.2, and Java 1.6.0. Eventually found this article - http://stackoverflow.com/questions/6651653/install-new-software-on-eclipse-not-working-on-mac To paraphrase, delete the version of log4j that comes packaged with your JDK. Eclipse updating worked fine thereafter, as did installing plugins. Hopefully that helps! Cheers James |