Libcurl does not seem to send user agent reliably

[Flameborn]

Transmission does not always send a user agent string when announcing to a torrent tracker.

Even when specified in its config file, the sent user agent string is empty.

This is after upgrading to Curl (libcurl) 7.71.0 and above, using Transmission 2.94 and 3.0. Older Curl versions work as expected.

See a forum thread here: https://forum.transmissionbt.com/viewtopic.php?f=2&t=20449&sid=5ab5f6c305ead5a64dbd72b0608cf729

I expected the following

User agent sent when announcing.

curl/libcurl version

Curl 7.71.0 and above.

operating system

Arch Linux ARM (Linux idris 5.4.81-1-ARCH #1 SMP PREEMPT Mon Dec 7 20:38:46 UTC 2020 armv7l GNU/Linux)

[bagder]

Please tell us how to reproduce this. And if any of the details in that forum thread is important for the issue, I would appreciate if you would include them in the issue here.

[Flameborn]

I am unfortunately unable to specify exact steps to reproduce, as the tracker specifics are not known to me. As a result,I can only assume that this is a common issue with any tracker, possibly with HTTPS enabled. I am aware that this makes debugging and possibly fixing the issue a lot harder than it should be.

In general:

• Install the transmission-cli package, along with core/curl (currently 7.74.0).
• Set up a torrent tracker, such as https://github.com/skipperbent/easy-torrent-tracker. (Requires a web server, PHP and possibly a certificate for HTTPS).
• Use transmission-create to create a torrent file, specifying the locally installed tracker.
• Start transmission via systemctl.
• Add the previously created torrent file via transmission-remote -a torrent-file-name.torrent

[bagder]

I can only assume that this is a common issue with any tracker,

That seems like a very far-going assumption that I can't see any evidence for.

We need a recipe for this issue in order to conclude that this is in fact a libcurl problem and not just a side effect of something in the application code. libcurl is after all used by a large number of applications and we've had no others report an issue like this during the half year 7.71.0 has been out.

The fact that no user-agent appears when you run the application is not a sure sign of a libcurl issue...

[Flameborn]

That seems like a very far-going assumption that I can't see any evidence for.

You are right, it is not guaranteed, but the fact that a Curl upgrade specifically causes this issue makes it likely that it was indeed a change in libcurl in 7.71.0. Transmission 2.94 was released on the 1st of May, 2018. This release and the subsequent 3.0 version (released on the 22nd of May 2020) work with Arch Linux's core/curl 7.70.0 and do not have issues when announcing.

Supposing that there were some API changes for lib curl in 7.71.0 and above, and Transmission is not using the lib curl API as expected, so the user agent is not set properly and it is indeed an application side effect as suggested, I believe that this is something that should be handled as it might break backward compatibility.

[bagder]

The sending of and setting user-agent has not changed in many years (maybe 15?), which is partly why I have a hard time to suspect thhat this is a libcurl regression. But I've been wrong before.

[jay]

I can't think of any other report like this. You could bisect.

[bagder]

I don't think we can do anything about this issue without either a way to reproduce ourselves, or a very detailed description of exactly what the app does (libcurl-wise) when it fails.

[Flameborn]

I have raised an issue for the Transmission client to request more information, as I believe they can provide details on how libcurl is used in the background.

[sveiki1]

Can confirm that I'm experiencing the same issue on Arch Linux ARM and Transmission.

Issue seems to be present in:

• curl-7.73.0-1-armv7h.pkg.tar.xz (SHA-1: 49069eb3d5c1ffa84a15d958f2bd13a1f3598626)
• curl-7.74.0-1-armv7h.pkg.tar.xz (SHA-1: 1fa01e39f2bfea3f70f69d50438dce478bce9026)

Downgrading to curl-7.67.0-3-armv7h.pkg.tar.xz (SHA-1: cc5d4f89e05a945a74bfce36f84786eb9e68e64d) seems to be a workaround. I was unable to test other versions as those were the only ones present in the pacman cache in my machine.

[DontWorryScro]

+1 to confirm this is an issue. I'm getting intermittent "banned client" errors due to this.

Edit: Using rTorrent:0.9.6/0.13.6