RPC can't bind

[HollowKnight]

Hello,

I am trying to build from source tarball transmission 2.31+ (12501) on TeraStation Pro I Linux 2.4.20_mvl31-ppc_terastation #36 Fri Aug 24 18:20:13 JST 2007 ppc GNU/Linux with all dependencies of latest releases: libevent-2.0.12-stable curl-7.21.6 gettext etc.... Everything ran smoothly until I fired the compiled transmission-daemon, all torrent related functions work perfectly, but only RPC cannot bind to network interface, so all RPC CLI and WEB cant connect to the servers.

I tried downgraded transmission from 2.31 to 2.22 then 2.21, no luck with RPC either. I've check all the logs I could but couldnt find any glue on this symptom. Googling around could not help me either.

My linux box installed with OpenTera firmware and many development packages for PPC, and I have successfully compiled all the software I need like lftp, ncftp, lynx etc. Before I used to compile all nightly build of transmission without any hick up.

The only thing I can try now is to cleanup the box and build all from very beginning, which takes lots of time.

I would very appreciate any advise how can I fix this bug? Thank you.

[rb07]

In short, the only problem is that transmission-daemon can't bind to port 9091?

Did you start the daemon as root?

Have you tried changing the port? And probably related, is anything else using that port? (it could be another instance of transmission-daemon).

[lazybones]

9091 is not a low port so I am guessing you have a conflict, or even better launched more than one instance of transmission at the same time.

[HollowKnight]

Thank you all for looking at this thread.

transmission-deamon successfully binds to it's ports 51413 or whatever I put in the command line parameter -P.

Torrent seeding/leeching still works as I put needed torrents into watch folder.

Yes, I did all the things I know to examine the problems: logging with --log-debug, changing ports with startup command as toot "transmission-daemon -P <high-port> -p <high and low ports>"

The only RPC related logging was:

[20:16:45.144] RPC Server Adding address to whitelist: 127.0.0.1 (rpc-server.c:805)
[20:16:45.144] RPC Server Serving RPC and Web requests on port 127.0.0.1:9093/transmission/ (rpc-server.c:982)

I even recompilled dependencies curl-7.21.6 libevent-2.0.12-stable with various enable disable switches that relevant to tcp.

I still don't know how to monitor tcp binding process and events

[rb07]

[20:16:45.144] RPC Server Serving RPC and Web requests on port 127.0.0.1:9093/transmission/ (rpc-server.c:982)

That right there means it binded fine.

Now test with:

Code: Select all

transmission-remote :9093 -si

the port is only needed if you changed the default (9091).

[HollowKnight]

Thanks rb07

I did the test with many ports as

Code: Select all

transmission-remote 9093 -b -si

and checked LISTENING ports with command netstat -ltpn, you can notice that port 53413 is open, but no 9093

Code: Select all

Active Internet connections (only servers)
Proto Recv-Q Send-Q Local Address           Foreign Address         State       PID/Program name
tcp        0      0 0.0.0.0:49152           0.0.0.0:*               LISTEN      6086/ushare
tcp        0      0 0.0.0.0:548             0.0.0.0:*               LISTEN      23860/afpd
tcp        0      0 0.0.0.0:53413           0.0.0.0:*               LISTEN      6522/transmission-d
tcp        0      0 0.0.0.0:901             0.0.0.0:*               LISTEN      28297/inetd
tcp        0      0 0.0.0.0:8873            0.0.0.0:*               LISTEN      28297/inetd
tcp        0      0 0.0.0.0:873             0.0.0.0:*               LISTEN      28297/inetd
tcp        0      0 0.0.0.0:139             0.0.0.0:*               LISTEN      23836/smbd
tcp        0      0 0.0.0.0:80              0.0.0.0:*               LISTEN      382/httpd
tcp        0      0 0.0.0.0:21              0.0.0.0:*               LISTEN      4463/proftpd: (acce
tcp        0      0 0.0.0.0:22              0.0.0.0:*               LISTEN      8400/sshd
tcp        0      0 0.0.0.0:23              0.0.0.0:*               LISTEN      28297/inetd
tcp        0      0 0.0.0.0:1337            0.0.0.0:*               LISTEN      6086/ushare
tcp        0      0 0.0.0.0:22939           0.0.0.0:*               LISTEN      414/lsprcvd
tcp        0      0 0.0.0.0:445             0.0.0.0:*               LISTEN      23836/smbd

Compilling libpcap, tcpdump and tcptrack for more interrogation

Otherwise, I am about to reinstall the box from very beginning

[rb07]

OK, that is strange.*

Take a good look at the daemon's settings.json, is RPC enabled?

For comparison here's what I have (some of it is garbage from old configurations, the 1st line for instance):

Code: Select all

$ grep -i rpc settings.json 
    "rpc-access-control-list": "+127.0.0.1,+192.168.10.2", 
    "rpc-authentication-required": true, 
    "rpc-bind-address": "0.0.0.0", 
    "rpc-enabled": true, 
    "rpc-password": "not important", 
    "rpc-port": 9091, 
    "rpc-url": "/transmission/", 
    "rpc-username": "also not important", 
    "rpc-whitelist": "127.0.0.1,192.168.10.*", 
    "rpc-whitelist-enabled": true,

I would say the important parts are the -enabled, -bind-address, and -port.

Don't waste time testing many ports, one is enough, or using tcpdump, it won't help with this problem. Re-installing is also not worth the trouble.

* A note: I hope the "port" test you showed is not what you really did because it has a big error, do you see the difference to what I wrote? If it makes things easier just copy the whole address:port that Transmission showed in the log, i.e. 127.0.0.1:9093 . And tell us the exact error you received.

Another note: are you using a firewall? Even if you don't know you are using one, can you check iptables?

[HollowKnight]

Thanks rb07 for your advises.

Sorry for keeping silent as I was busy with some other NAS of newer generation to playwith. I did check all the settings config and know how to enable disable certain ports or allow/deny list. No luck. I just dont have enough debug tool to see where exactly transmission-daemon failed while binding rpc ports. Another optiion to try with is installing transmission from ipkg packages pool and run it, before giving up and reinstall from reflashing firmware, install devel packages and recompile again.

P.S. I guess transmission must share rpc functions with the box's httpd and php daemons and could be the some settings conflicts? Adhoc tweaks and cracks would make my nas box configuration a mess now, so I'd prefer to reinstall all software in there.

[rb07]

httpd and php daemons and could be the some settings conflicts?

No, if there was a conflict you would see a different message, something like "port already in use".

[HollowKnight]

Hello,

Just a short update on transmission on my PPC NAS Box.

I've re-flashed fresh firmware, installed development tools and recompile transmission-daemon of previous releases. The last release worked successfully was 1.93. Anything above 1.93 causes 'cannot bind' symptom as above mentioned. All other depend packages was fresh compiled (e.g curl-7.20.7, libevent-2.0.12-stable etc.)

Still a bit surprised as in the past, I've successfully recompile all transmission packages up to v2.20+

[rb07]

You are probably seeing a different problem, between 1.93 and all the following versions the only thing that stopped working was the libevent and epoll problem: T on a NAS.

[HollowKnight]

Hello,

I was aware of epoll problem and set env EVENT_NOEPOLL=1 when calling transmission-daemon.

When I started I transmission-daemon in the foreground I got the following messages

Code: Select all

root@NAS:~# EVENT_NOEPOLL=1 TR_DEBUG=1 transmission-daemon -f -t -g /mnt/array1/share/.config/transmission-daemon/
getaddrinfo() error : Bad value for ai_flags
getaddrinfo() error : Bad value for ai_flags
getaddrinfo() error : Bad value for ai_flags
getaddrinfo() error : Bad value for ai_flags
getaddrinfo() error : Bad value for ai_flags
getaddrinfo() error : Bad value for ai_flags
[11:23:45.549] Transmission 2.33+ (12606) started (session.c:706)
[11:23:45.550] RPC Server Adding address to whitelist: 127.0.0.1 (rpc-server.c:805)
[11:23:45.550] RPC Server Serving RPC and Web requests on port 127.0.0.1:9091/transmission/ (rpc-server.c:999)

I was able to get more detailed messages, most of them come from event library. The debug log does not help to pin the problem though

Code: Select all

EVENT_NOEPOLL=1 TR_DEBUG=1 TR_DEBUG_FD=1 transmission-daemon -f -t -g /mnt/array1/share/.config/transmission-daemon/

Tried googling for "getaddrinfo() error : Bad value for ai_flags" did not help either.

my NAS box running Kernel 2.4

Thank you

[rb07]

Its difficult to say from what you show, but the getaddrinfo() error is probably caused by your build environment... and you should have seen a message by the compiler (probably one of many so it may be difficult to see it), could be something about alignment (does 'transmission-remote -l' don't show the list of torrents, that's where I've seen alignment problems, but different from what you have).

Technically getaddrinfo() is used in just 3 places: libtransmission/announcer-udp.c, third-party/miniupnp/connecthostport.c, and in libevent several times; you could use the debugger to see which of those is the exact place that is complaining, of course this means rebuilding everything with debug information, and having the debugger, and knowing how to use it. If the problem is really "alignment" then this debugging is not really necessary, its a processor/compiler problem, a newer compiler _might_ fix it, a properly ported compiler shouldn't have the problem.

[HollowKnight]

I am recompiling all depends again to see what happens. I installed Development Tools from http://homepage.ntlworld.com/itimpi/opentera.htm some tools are quite old.

Before recompiling dependable libraries, I used to get pre-compiled optware via ipkg tool. Some packages caused incompatibilities with transmission, especially with RPC modules. Transmission-remote even couldnt launch. I've recompiled the following packages:

curl-7.21.7
libevent-2.0.12-stable
gettext-0.18.1.1
intltool-0.41.1
expat-2.0.1
XML::Parser

Usually we don't need gettext, intltool, expat and XML with option --disable-nls, but this option caused some error during configure phase.

Will post updates.

Thank you

[beber]

I successfully build and install tranmission on my 2.4.20_mvl31-ppc_terastation
All problems come from AI_NUMERICSERV and AI_ADDRCONFIG which contain non null value, making the call to "getaddrinfo" sometimes invalid

1) Modify the libevent library adding inside "./include/event2/util.h" after running "./configure"
#undef AI_NUMERICSERV
#define AI_NUMERICSERV 0
#undef AI_ADDRCONFIG
#define AI_ADDRCONFIG 0

2) Then in tranmission inside "./third-party/miniupnp/connecthostport.c" comment the following lines
//#ifdef AI_NUMERICSERV
// hints.ai_flags = AI_NUMERICSERV;
//#endif