Community
Participate
Working Groups
Steps to reproduce: 1. Setup a target connection in RSE and make sure it works. 2. Exit Eclipse and start it again. 3. Go to menu Window/Preferences/General/Network Connections 4. Set Active Provider to 'manual'. 5. Enter a valid IP address and port 8080 for the HTTP proxy. 6. apply & close the windows. 7. Connect to the target in the RSE perspective. That will fail. Even if you specify the target IP address in the proxy bypass list, it is still not possible to create a connection. Analysis: RSE attempts to always use the proxy if one is specified, even for protocols that should not use a proxy (like ssh) to devices that never should use a proxy (like targets). I've been reading the sources (RSE 3.2.2) of the jsch and I see that jsch tries to obtain the proxy for the given host using the Eclipse's IProxyService interface. 1. Currently used jsch version (3.2.2) uses the getProxyDataForHost(host, type) which does not take into account the protocol (ssh in our case), This function is depricated in the latest Eclipse (I use Indigo). I believe that it is one of the root problem. 2. Jsch tries to find proxy for the type SOCKS or else HTTPS. This is also a bit strange from my point of view. Anyway, in case if there is a proxy for SOCKS or HTTPS it will be used for ssh, which is not correct actuially. As a workaround It's possible to clear entries for SOCKS and HTTPS in network configuration. In such case the proxy won't be used for ssh. It works for me.
This sounds like bug 221843, which was resolved as a duplicate of bug 238796 . I think that the "Proxy bypass" list on the Preferences : General : Network page should work to exclude hosts. I'm not sure whether it can also exclude networks (I think it should, so that might be a valid enhancement request against Platform e.g. using netmask notation like "128.224.199.0/ffffff00" or "128.224.199.0/24). Beyond that, protocol-specific proxy lists have often been discussed but AFAIK never been implemented; AFAIK a SOCKS proxy is meant to be able and translate ANY socket connection protocol including SSH. So in my understanding, as of today Eclipse Proxy UI is meant to be used for all protocols (which is at least consistent, ant may be expected in many cases). See also bug 221332 comment 1 for some background. Maybe somebody (org.eclipse.core.net ?) would need to register a special proxy provider for SSH and give it priority over SOCKS
I tested it and the bypass option now works for hosts, haven't tested networks yet.
Martin, do you think it would be possible to at least have an option in the new connection wizard to inherit/bypass the proxies? I agree about SOCKS, but jcraft also uses HTTPS settings. I think it's incorrect.
This is an interesting idea. Since we know that jsch uses a configured proxy by default (for SOCKS at least), the new connection wizard could have an option Direct connection (bypass proxies) When it's enabled, the target IP is automatically added to the proxy exclusion list. I guess my only concern is about lifecycle of such automatic settings. What if the target IP is changed / deleted ... the proxy exclusion would remain. It may be better to just add a button to the new connection wizard, which brings up the proxy configuration preference page (maybe with the new IP prefilled). Then users know what gets configured and where, rather than doing magic under the hood. I dont quite understand your comment about HTTPS.
Created attachment 209133 [details] a link to the preferences in the wizard page Martin, How about something like this?
Never mind, I read the links you mentioned before and I now take this back. (In reply to comment #4) > I dont quite understand your comment about HTTPS.
I certainly have no objections to this approach (provided that you can code it with OK dependencies). Is this kind of integration sufficient for you in terms of usability ? I.e. will users know when they need to navigate into the Proxy Preferences ?
Created attachment 210019 [details] Patch that implements the proposed UI Here is how I want to do it. Martin, do you think it's okay to check this in?
Also, which properties file should I use to externalize my string?
I checked in the proposed patch. I don't think there is much else we can do here, so I am resolving it as fixed.
