[See Bugtracker] Force retrying a socks5 proxy?

Hi,

Is it possible to tell JD2 that it can retry a socks5 proxy again?

For example: If the file/proxy gets into a status of "download limit has been reached", it looks like the proxy is not (immediately?) retried even if the external/outbound IP of the proxy has changed.

For now, when I want to force JD2 to retry, what I do is change the port # of the proxy, and then add a new entry for it in JD2.

I was hoping there's something like a simple way to just force JD2 to retry the current one.

Thanks!

[raztoki]

what happens if you add a series of entries to connection manager, with different ports?

I believe JD will do a IP check to confirm each entry's outward bound IP

raztoki

Hi,

Yes, that's kind of what I'm currently doing: I change the port # on the proxy server, then I add a new entry in the Connection Manager with the new port to make JD2 think I have a new proxy server. It immediately retries when I do that.

[raztoki]

are you inferring that the WAN IP on the proxy is actually the same?

[Jiaz]

Is the proxy your only Connection in Connection Manager. There is no proper "reconnect" detection for proxies yet, because normally proxies don't change their outgoing ip's
Can you provide more information about the setup?

raztoki:

The proxy's WAN IP changes (I can force it to change), and is different from my usual WAN IP.


Jiaz:

I use "no proxy" and socks5 proxy. The socks5 proxy is basically just a computer/VM running a simple socks5 proxy called 3proxy. The WAN IP for the "no proxy" and proxy are different. The "no proxy" doesn't change WAN IP, but the proxy does.

Screenshot of JD2's Connection Manager and gateway status... The multiple 192.168.27.138 with different ports are my attempts to force a retry.


The retry doesn't have to be automatic. I would be happy with something like a right-click "retry this proxy" in Connection Manager.


Thanks guys!

[Jiaz]

Why not simply enable all of them and Let JDownloader handle it. Then it does not reconnect but i can use the different outgoing ip's at the same time, till all have reached their waiting time limits.

Sorry, maybe I'm reading your reply incorrectly... I actually only have 1 proxy with 1 extra WAN IP address (randomly assigned).

I guess I could just leave entries with many different ports enabled in JD2, and just change the port in the proxy. It just seems wrong to have all of it probing and waiting at nothing in the background.

[Jiaz]

So why add it several times in JDownloader? Just simply add the proxy once and wait till this feature is implemented

Will try to fix it as soon as possible

I'm doing exactly the same thing as tuktuk, but I'm using tinyproxy as an HTTP proxy. (in stealth mode, tinyproxy config option to not add proxy headers.) Does SOCKS work better for JD2 than an HTTP proxy? I prob. got the config wrong with my SOCKS proxy, because I tried that first without success.

I had to enable settings -> advanced -> use proxy for IP check, or else it will use direct for checking the IP of both connections. (When is that ever useful? HTTP proxies don't add a header to tell the server the original IP of the request, do they? If the server is going to check things based on the proxy's IP, JD2 needs to do IP checks through the connection that it's checking. I think JD2 still uses Direct for checking the IP of my Direct connection, so it's not like that option forces all IP checks to avoid the direct connection.)

(See https://board.jdownloader.org/showth...230#post329230 for more about the poor IP checking.)

When I get a new IP on my proxy (which I do manually), I've usually clicked "reset" on a link to get JD2 to try it again. At that point, it usually notices the IP of the proxy connection has changed, since it does an http request to ipcheck<number>.jdownloader.org.

I tried using reconnect once, with method = script, and the script body

true  # unix command that just exits right away, with a successful exit status

That was before I found the ip check via proxy option, so it didn't even notice the changed IP. Even worse, it aborted running downloads on the direct connection. (Is it helpful on some routers to close TCP connections before asking it to get a new IP? As a workaround for buggy routers that leak memory or get their connection table clogged up? Or do some hosters treat a closed connection differently from a timed-out connection?) Anyway, that was annoying.

I think the nicest way to implement external reconnects would be to add a new reconnect method "External". Clicking reconnect would just trigger an IP check on all available connections. Either disallow the user from enabling auto-reconnects with external, or warn the user that it requires manual intervention, and pop up a dialog to tell them that JD2 is ready for a reconnect.

It would be more tricky to allow the "don't start new downloads when one is waiting for a reconnect" to operate per-connection, right? From the behaviour of the GUI, I have the impression that not all of JD2 as designed for octopus-mode controlling multiple IPs. (e.g. reconnect waittime for one connection doesn't always show if the other is downloading.)

[Jiaz]

Socks5 always work better because a socks proxy is "dumb" It simply opens a TCP tunnel while HTTP Proxies forward/parses/interacts on traffic. HTTP Proxies also often only allow opening port 443 for tcp forward.

The current reconnect is implemented to reconnect the direct connection because normally you cannot reconnect proxies This is all on todo list to have individual reconnect/ipcheck for each connection.

A reconnect in JDownloader stops all ongoing downloads.

[yelador]

It seems that it still does not work. After changing the IP in the proxy service, the IP is not recognized by JDownloader.