transmission module - json payload marshall error: io: read/write on closed pipe

[tolga-balci]

Hi Sean,

I have the following configuration in my config.yml:

   transmission:
      enabled: true
      host: "192.168.1.1"
      username: "MyUserName"
      password: "MyPassword"
      position:
        top: 3
        left: 0
        height: 2
        width: 2
      refreshInterval: 10s

The transmission module displays the following error:

'torrent-get' rpc method failed: request error: Post "http://192.168.1.1:9091/transmission/rpc": dial tcp 192.168.1.1:9091: connect: connection refused | json payload marshall error: io: read/write on closed pipe.

Before writing this post, I checked a couple of things:

1. Port: My default Transmission setup uses the port 8090 by default. That means, rpc calls on 9091 return "Connection refused" error:

transmission-get.json*:

{
    "username": "MyUserName",
    "password": "MyPassword",
    "arguments": {"fields": ["id", "name", "totalSize"], "ids": [1, 2]},
    "method": "torrent-get",
    "tag": 39000
}

$ curl -v -X POST 192.168.1.1:9091/transmission/rpc -H "Content-Type: application/json" -d @transmission-get.json

Note: Unnecessary use of -X or --request, POST is already inferred.
*   Trying 192.168.1.1:9091...
* connect to 192.168.1.1 port 9091 failed: Connection refused
* Failed to connect to 192.168.1.1 port 9091 after 1 ms: Connection refused
* Closing connection 0
curl: (7) Failed to connect to 192.168.1.1 port 9091 after 1 ms: Connection refused

However, the same curl request over port 8090 returns HTTP 200 OK:

$ curl -v -X POST 192.168.1.1:8090/transmission/rpc -H "Content-Type: application/json" -d @transmission-get.json --user MyUserName:MyPassword

Note: Unnecessary use of -X or --request, POST is already inferred.
*   Trying 192.168.1.1:8090...
* Connected to 192.168.1.1 (192.168.1.1) port 8090 (#0)
* Server auth using Basic with user 'MyUserName'
> POST /transmission/rpc HTTP/1.1
> Host: 192.168.1.1:8090
> Authorization: Basic dG9sZ2E6MTEwNDE5NzY=
> User-Agent: curl/7.81.0
> Accept: */*
> Content-Type: application/json
> Content-Length: 188
>
* Mark bundle as not supporting multiuse
< HTTP/1.1 200 OK
< Server: Transmission
< Content-Type: application/json; charset=UTF-8
< Date: Sun, 26 Feb 2023 09:24:21 GMT
< Content-Length: 61
<
{"arguments":{"torrents":[]},"result":"success","tag":39000}
* Connection #0 to host 192.168.1.1 left intact

I think the config file needs a port parameter as well. Not because my setup uses a different port number, but because Transmission's settings.json has the "rpc-port" setting. I believe wtf's Transmission module has to match this setting.

2. Authentication: I also have a question mark on the authentication side as well. I could not find any trace of authentication parameters in Transmission's rpc documents (it might be me, who was not able to see) but I tried authentication using a JSON** file. This attempt failed:

$  curl -X POST 192.168.1.1:8090/transmission/rpc  -H "Content-Type: application/json" -d @transmission-get.json --trace-ascii transmission-trace.log

transmission-trace-json.log

== Info:   Trying 192.168.1.1:8090...
== Info: Connected to 192.168.1.1 (192.168.1.1) port 8090 (#0)
=> Send header, 150 bytes (0x96)
0000: POST /transmission/rpc HTTP/1.1
0021: Host: 192.168.1.1:8090
0039: User-Agent: curl/7.81.0
0052: Accept: */*
005f: Content-Type: application/json
007f: Content-Length: 188
0094: 
=> Send data, 188 bytes (0xbc)
0000: {    "username": "MyUserName", "password": "MyPassword",    "argumen
0040: ts": {        "fields": ["id", "name", "totalSize"],        "ids
0080: ": [1, 2]    },    "method": "torrent-get",    "tag": 39000}
== Info: Mark bundle as not supporting multiuse
<= Recv header, 27 bytes (0x1b)
0000: HTTP/1.1 401 Unauthorized
<= Recv header, 22 bytes (0x16)
0000: Server: Transmission
<= Recv header, 46 bytes (0x2e)
0000: WWW-Authenticate: Basic realm="Transmission"
<= Recv header, 37 bytes (0x25)
0000: Date: Sun, 26 Feb 2023 09:01:06 GMT
<= Recv header, 20 bytes (0x14)
0000: Content-Length: 82
<= Recv header, 45 bytes (0x2d)
0000: Content-Type: text/html; charset=ISO-8859-1
<= Recv header, 2 bytes (0x2)
0000: 
<= Recv data, 82 bytes (0x52)
0000: <h1>401: Unauthorized</h1><p>Unauthorized User. 1 unsuccessful l
0040: ogin attempts.</p>
== Info: Connection #0 to host 192.168.1.1 left intact

However, passing the credentials explicitly to the same curl command succeeds:

$ curl -X POST 192.168.1.1:8090/transmission/rpc  -H "Content-Type: application/json" --user MyUserName:MyPassword -d @transmission-get.json --trace-ascii transmission-trace-curl-json-file.log

transmission-trace-curl-json-file.log

== Info:   Trying 192.168.1.1:8090...
== Info: Connected to 192.168.1.1 (192.168.1.1) port 8090 (#0)
== Info: Server auth using Basic with user 'MyUserName'
=> Send header, 193 bytes (0xc1)
0000: POST /transmission/rpc HTTP/1.1
0021: Host: 192.168.1.1:8090
0039: Authorization: Basic dG9sZ2E6MTEwNDE5NzY=
0064: User-Agent: curl/7.81.0
007d: Accept: */*
008a: Content-Type: application/json
00aa: Content-Length: 188
00bf: 
=> Send data, 188 bytes (0xbc)
0000: {    "username": "MyUserName",    "password": "MyPassword",    "argumen
0040: ts": {        "fields": ["id", "name", "totalSize"],        "ids
0080: ": [1, 2]    },    "method": "torrent-get",    "tag": 39000}
== Info: Mark bundle as not supporting multiuse
<= Recv header, 17 bytes (0x11)
0000: HTTP/1.1 200 OK
<= Recv header, 22 bytes (0x16)
0000: Server: Transmission
<= Recv header, 47 bytes (0x2f)
0000: Content-Type: application/json; charset=UTF-8
<= Recv header, 37 bytes (0x25)
0000: Date: Sun, 26 Feb 2023 09:04:44 GMT
<= Recv header, 20 bytes (0x14)
0000: Content-Length: 61
<= Recv header, 2 bytes (0x2)
0000: 
<= Recv data, 61 bytes (0x3d)
0000: {"arguments":{"torrents":[]},"result":"success","tag":39000}.
== Info: Connection #0 to host 192.168.1.1 left intact

Having everything the same, but receving an HTTP 200 message makes me think that there is a glitch when credentials are supplied in the JSON file.

With all these, my point is that the credentials we are passing to wtfutil within the Transmission module through YML** might be causing the issues I am seeing.

* My JSON file might be wrong, which might be why it is failing.
** I did not see references to YML files in Transmission's RPC documentation. The documentation uses JSON format. That's why I used JSON instead of YML with my calls with curl.

Apologies for my annoyances over the weekend and many thanks for your patience!

Cheers!
Tolga

[Seanstoppable]

There is actually a port param in the transmission module config that works as of the latest release.
The transmission module uses the username and password to set up auth very similar to how you ended up doing so in curl. Config params are not a representation of the json requests that services might need.

[senorprogrammer]

Hi @tolga-balci you can explicitly set a port by adding a port setting to your config. See the source code implementation here https://github.com/wtfutil/wtf/blob/master/modules/transmission/settings.go#L20

That the port setting is not documented is a doc bug, thanks for finding that.

[tolga-balci]

Hi @senorprogrammer - Many thanks for the replies, but unfortunately there is something missing still.

Here is my transmission configuration that matches my settings.json:

    transmission:
      enabled: true
      host: "192.168.1.1"
      user: "MyUserName"
      password: "MyPassword"
      port: "8090"
      url: "/transmission/rpc"
      position:
        top: 3
        left: 0
        height: 2
        width: 2
      refreshInterval: 10s

I started wtfutil with this configuration and I got "No data" in the dashboard.

I added one torrent for testing and I got the following error:

'torrent-get' rpc method failed: can't unmarshall request answer body: json: cannot unmarshal bool into Go struct field torrentGetResults.arguments.torrents of type int64

I can continue troubleshooting with you continuing from Wednesday onwards.

Cheers!