Adds IPv6 support for HTTP requests

[miyurusankalpa]

The FSock.PreferIP4 setting is set to True which forces IPv4 only requests.

Setting it to true makes it use IPv6 but in IPv4 only clients this breaks the connectivity.

Therefore some type of IPv6 connectivity check is needed, ~which I used pinging to a the Cloudflare DNS IPv6 address with a timeout to set the setting.~

~In Linux this will only work with a sudo user as ping check needs sudo privileges on Linux.~

Best option to solve this is to implement Happy Eyeballs.

related: #1362 may be related: #1353, #485

[miyurusankalpa]

When having a checkbox, if the user moves to IPv4 only network, it will break the app. for the optimal scenario app should detect the connectivity and change accordingly. This is the how even chrome works. https://bugs.chromium.org/p/chromium/issues/detail?id=530482 https://github.com/ungoogled-software/ungoogled-chromium/blob/master/patches/extra/ungoogled-chromium/add-ipv6-probing-option.patch

As mentioned this not the best solution, Implementing Happy eyeballs is the correct way forward. I am working on implementing it, but it will take sometime.

@PeterDaveHello Let me know if you think adding HEB support later is the correct way forward instead of adding this now.

any other ideas are also welcome.

[PeterDaveHello]

@miyurusankalpa not sure if I fully understand your reference, do you mean that the patch you referred to, caused some problem? Looks like it didn't provide proper information, but the behavior doesn't look like just broken because of the feature.

[PeterDaveHello]

@miyurusankalpa Not sure if this will be too complex to you, but maybe we can only try to detect IPv6 when the target seems to be unreachable?

[miyurusankalpa]

@miyurusankalpa Not sure if this will be too complex to you, but maybe we can only try to detect IPv6 when the target seems to be unreachable?

Yes, that's a good idea. I'll try to implement that one.

[miyurusankalpa]

@PeterDaveHello I updated the code to use IPv6 first and fail-over to IPv4 if, there are any errors.

I tested on Linux and Windows are it works without errors.

For IPv4 only testing, I disabled the IPv6 stack in OS and It worked fine.

I would like if someone with IPv4 only internet(& IPv6 stack enabled) can further test this and confirm.

[fredo-47]

With the transgui versions built since last week, I get "Network is unreachable" when hitting the "Check for Updates" or the "Update Geo IP database" functions. I am on a IP4-only system.

And when I build transgui with the 3 lines of this commit reverted (I put "//" at beginning of those lines), then the two functions "Check or Updates" and "Update Geo IP database" work without any error.

[PeterDaveHello]

@fredo-47 thanks for reporting this issue, what's your OS version?

[fredo-47]

I am on Linux Mint 21

[PeterDaveHello]

@fredo-47 okay, I'll test on it later.

[miyurusankalpa]

@fredo-47 did you try multiple times in a single session? it should fallback on the second try if there are any errors. thanks for testing and reporting, btw.

[fredo-47]

Yes, I started transgui and then tried several times clicking on "Check or Updates" or "Update Geo IP database". Each time, there is "Network unreachable".

[PeterDaveHello]

@fredo-47 Can you manually revert the change locally, then rebuild and test again? I just tested on Linux Mint 21 with IPv4 environment, and it works just fine.

[fredo-47]

@PeterDaveHello , that's exactly what I did yesterday.

I am doing it again right now: Start with empty directory and do a git clone --recurse-submodules https://github.com/transmission-remote-gui/transgui . Then ./setup/unix/build.sh Now I run the built executable (7f95174). I click several times the function "Update GeoIP database" and "Check for updates". Each time I get "Network is unreachable".

Now I go into ~/transgui/synapse/source/lib and edit the file httpsend.pas and revert the changes made in this PR by deleting lines 371, 375, 376. Then I save the modified file locally, and build again ./setup/unix/build.sh When I now run the built transgui, there is no error with the two features mentioned, i.e. it normally downloads the GeoIP database and reports that there are now program updates.

[PeterDaveHello]

@fredo-47 Thanks for the details, I think we'll need to think about how to gather more debug info now to find out the problem 🙈

[PeterDaveHello]

Tested on different IPv4 network environment but everything works fine for me on LinuxMint v21 though 😱

[fredo-47]

What can I do to have transgui produces more verbose messages so that we can get more hints on what is wrong on my system?

Is there an option for building it in some kind of debugging mode or similar? Does it log its (error) messages somewhere?

[PeterDaveHello]

Unfortunately, no idea yet 🙈

[fredo-47]

I am still trying to understand for myself what the modifcations actually do :-)

I am no programming expert, but looking at these lines 369 function THTTPSend.InternalConnect(needssl: Boolean): Boolean; 370 begin 371 FSock.PreferIP4 := False; //try to use IPv6 372 if FSock.Socket = INVALID_SOCKET then 373Result := InternalDoConnect(needssl) 374 else 375 if FSock.LastError <> 0 then 376 FSock.PreferIP4 := True; //fallback to IPv4

It looks to me as follows: In 371, it defaults to IPv6 In 372, the IF-command tries the socket (I think), and I assume it would result to "invalid" for IPv4 So it executes the THEN part in 373 (Here, I am not sure what "InternalDoConnect(needssl)" is or does). Afterwards it finds ELSE-command and therefore will exit the whole IF-structure, won't it? Meaning for IPv4-environment, the ELSE-part is never executed, and thus FSock.PreferIP4 is never set to True?

(Please correct me, I may be wrong because I'm no programing expert. Any remark is appreciated)