Tries to connect to the same interface/port twice and fails.

[GoogleCodeExporter]

This is reported by users of qbittorrent.

When the user chooses for the app to listen on "any interface" 
(libtorrent::session::listen_on(ports, ex, 0) )

We get this on the log:
01/10/2013 16:52:30 - qBittorrent is trying to listen on any interface port: 
TCP/31181
01/10/2013 16:52:31 - qBittorrent is successfully listening on interface 
0.0.0.0 port: TCP/31181
01/10/2013 16:52:31 - qBittorrent is successfully listening on interface :: 
port: TCP/31181
01/10/2013 16:52:31 - qBittorrent failed listening on interface 0.0.0.0 port: 
TCP/31181. Reason: Only one usage of each socket address (protocol/network 
address/port) is normally permitted

The first message is outputed when doing the listen_on()
The other 3 are outputted inside the listen_succeeded_alert/listen_failed_alert 
handlers.

I don't know why libtorrent is trying twice 0.0.0.0/31181 and not ::/31181
(it should try once every interface anyway)

When I told the user to specifically choose a network interface from the 
settings this is what he gets:
Log if I select "Local Area Connection":
01/10/2013 18:13:29 - qBittorrent failed listening on interface 
fe80::1e1:8d0f:XXXX:XXXX%11 port: TCP/31181. Reason: The file handle supplied 
is not valid
01/10/2013 18:13:29 - qBittorrent is successfully listening on interface 
fe80::1e1:8d0f:XXXX:XXXX%11 port: TCP/31181

Log if I select "isatap...":
01/10/2013 18:17:04 - qBittorrent failed listening on interface 
fe80::5efe:192.168.1.100%12 port: TCP/31181. Reason: The file handle supplied 
is not valid
01/10/2013 18:17:04 - qBittorrent is successfully listening on interface 
fe80::5efe:192.168.1.100%12 port: TCP/31181

Log if I select "Teredo Tunneling...":
01/10/2013 18:18:31 - qBittorrent failed listening on interface 
2001:0:5ef5:79fb:34e4:XXX:XXXX:2506 port: TCP/31181. Reason: The file handle 
supplied is not valid
01/10/2013 18:18:31 - qBittorrent is successfully listening on interface 
2001:0:5ef5:79fb:34e4:XXX:XXXX:2506 port: TCP/31181

Same problem. The port is tried twice. And it fails in the second time(well 
duh).

Using latest RC_0_16 on Windows XP sp2, but this might affect linux too because 
we get quite a few "our torrents stay stalled and not downloading."

Original issue reported on code.google.com by hammered...@gmail.com on 1 Oct 2013 at 8:10

[GoogleCodeExporter]

Link to qbt bug: https://github.com/qbittorrent/qBittorrent/issues/947

Original comment by hammered...@gmail.com on 1 Oct 2013 at 8:11

[GoogleCodeExporter]

is it possible that the main listen port is set to the same as ssl_listen?

if ssl_listen is != 0, another listen socket is opened (one for IPv4 and one 
for IPv6) to accept SSL connections. If the ports are the same, the ssl socket 
would fail with that error.

Original comment by arvid.no...@gmail.com on 2 Oct 2013 at 5:58

[GoogleCodeExporter]

Nope, ssl_listen is set to 0, when setting up the session and it never gets 
touched again.

Original comment by hammered...@gmail.com on 2 Oct 2013 at 6:17

[GoogleCodeExporter]

I also have a user on Xubuntu 13.04 who gets this:

21/09/2013 06:05:54 - qBittorrent failed listening on interface 0.0.0.0 port: 
TCP/0. Reason: Mauvais descripteur de fichier
21/09/2013 06:05:54 - qBittorrent failed listening on interface 0.0.0.0 port: 
TCP/0. Reason: Mauvais descripteur de fichier
21/09/2013 06:05:54 - qBittorrent failed listening on interface 0.0.0.0 port: 
TCP/0. Reason: Permission non accordée
21/09/2013 06:05:54 - qBittorrent failed listening on interface 0.0.0.0 port: 
TCP/0. Reason: Mauvais descripteur de fichier
21/09/2013 06:05:54 - qBittorrent failed listening on interface 0.0.0.0 port: 
TCP/0. Reason: Mauvais descripteur de fichier
21/09/2013 06:05:54 - qBittorrent failed listening on interface 0.0.0.0 port: 
TCP/0. Reason: Mauvais descripteur de fichier
21/09/2013 06:05:54 - qBittorrent failed listening on interface 0.0.0.0 port: 
TCP/0. Reason: Mauvais descripteur de fichier
21/09/2013 06:05:54 - qBittorrent failed listening on interface 0.0.0.0 port: 
TCP/0. Reason: Permission non accordée
21/09/2013 06:05:53 - Options were saved successfully.
21/09/2013 06:05:53 - Embedded Tracker [OFF]
21/09/2013 06:05:53 - Encryption support [ON]
21/09/2013 06:05:53 - Local Peer Discovery support [OFF]
21/09/2013 06:05:53 - PeX support [ON]
21/09/2013 06:05:53 - DHT support [ON], port: UDP/6881
21/09/2013 06:05:53 - Anonymous mode [OFF]
21/09/2013 06:05:53 - HTTP user agent is qBittorrent v3.1.0alpha
21/09/2013 06:05:53 - UPnP / NAT-PMP support [OFF]
21/09/2013 06:05:53 - qBittorrent is trying to listen on any interface port: 
TCP/16923
21/09/2013 06:05:53 - Peer ID: -qB3100-

Note: That qbt when it set ups the listen port it tells libtorrent to never use 
port 0 via the special flag. However, libtorrent ends trying to bind to port 0 
and fails.
PS: I think Xubuntu 13.04 uses libtorrent 0.15.x though :s

A clarification: From what I understand from the docs listen_succeeded_alert is 
emitted only for the listen port and not for the DHT port. Is that correct? The 
DHT binding success/failure doesn't have it's own alert, right?

Also for my first post the user uses Windows 7 not XP. On my XP, these double 
tries don't exist.

Original comment by hammered...@gmail.com on 2 Oct 2013 at 4:59

[GoogleCodeExporter]

looking at the qBitTorrent source, it looks like you're looping over all 
interfaces, calling listen_on() multiple times.  Each subsequent call will 
close the sockets opened by the previous call, and re-open them with the new 
arguments. Since the previous sockets are supposed to be closed first, it's 
never supposed to fail with the error you describe, and that certainly indicate 
a bug somewhere.

However, the loop in qBitTorrent is also redundant. If you want to listen on 
all interfaces, just pass in INADDR_ANY (or "0.0.0.0" in string form).

My intention is to make it possible to specify a list of IPs to listen on in 
future versions of libtorrent, but this is not possible yet. Right now you can 
either listen on a single interface or all of them.

I will try to reproduce and fix the issue you highlight, but I'm inclined to 
believe that it's not a very serious issue, since the expected use of 
listen_on() probably won't have this problem. (it may be that I should improve 
the documentation as well, suggestions or patches to the documentation are more 
than welcome).

Original comment by arvid.no...@gmail.com on 6 Oct 2013 at 9:45

[GoogleCodeExporter]

I can't reproduce re-opening the socket when the port and interface stays the 
same.

Original comment by arvid.no...@gmail.com on 6 Oct 2013 at 10:34

[GoogleCodeExporter]

You are almost right. Just to be sure this is the relevant code: 
https://github.com/qbittorrent/qBittorrent/blob/master/src/qtlibtorrent/qbtsessi
on.cpp#L1921

The for loop is only tried only when the user has set a specific interface AND 
that interface exposes more than one IPs.

Each time an ip/port combo is tried there is an appropriate line outputted in 
the log in the form of:
"qBittorrent is trying to listen on any interface port: TCP/%1"

when the user hasn't set an interface so we tell libtorrent to listen to all 
via listen_on(ports, ec, 0, session::listen_no_system_port);

and
"qBittorrent is trying to listen on interface %1 port: TCP/%2"

in the for loop where the user has set an interface.

However, as you can from my previous log excerpts  this messages only appear 
once. So the relevant IP is only listened_on() once.

PS: As you mentioned, the for loop is meaningless since listen_on() will 
override previous listen_on(). I'll remove it, but I doubt that it will fix the 
current problem.

Original comment by hammered...@gmail.com on 7 Oct 2013 at 5:44

[GoogleCodeExporter]

Is it possible that the second attempt is caused by loading session state? i.e. 
session::load_state()?

Original comment by arvid.no...@gmail.com on 10 Oct 2013 at 5:56

[GoogleCodeExporter]

>Is it possible that the second attempt is caused by loading session state? 
i.e. session::load_state()?

Forgot about. And I didn't check. In the meantime, another user has these 
reported on Arch Linux with 0.16.10/boost 1.55

"qBittorrent failed listening on interface 0.0.0.0 port: TCP/0. Reason: Bad 
file descriptor"
"qBittorrent failed listening on interface 0.0.0.0 port: TCP/45398. Reason: 
Address family not supported by protocol"

Original comment by hammered...@gmail.com on 28 Dec 2013 at 6:57

[GoogleCodeExporter]

21/09/2014 00:12:13 - UPnP/NAT-PMP: Port mapping successful, message: 
successfully mapped port using UPnP. external port: 6881
21/09/2014 00:12:13 - UPnP/NAT-PMP: Port mapping successful, message: 
successfully mapped port using UPnP. external port: 6881
21/09/2014 00:12:13 - qBittorrent failed listening on interface 0.0.0.0 port: 
TCP/6881. Reason: Connection refused
21/09/2014 00:12:13 - UPnP/NAT-PMP: Port mapping successful, message: 
successfully mapped port using NAT-PMP. external port: 6881
21/09/2014 00:12:13 - UPnP/NAT-PMP: Port mapping successful, message: 
successfully mapped port using NAT-PMP. external port: 6881
21/09/2014 00:12:13 - External IP: 
21/09/2014 00:12:13 - qBittorrent failed listening on interface 0.0.0.0 port: 
TCP/6881. Reason: Connection refused
21/09/2014 00:12:13 - qBittorrent is successfully listening on interface :: 
port: TCP/6881
21/09/2014 00:12:13 - qBittorrent is successfully listening on interface 
0.0.0.0 port: TCP/6881
21/09/2014 00:12:13 - qBittorrent failed listening on interface 0.0.0.0 port: 
TCP/42272. Reason: Connection refused
21/09/2014 00:12:12 - 
'/home/denis/.local/share/data/qBittorrent/BT_backup/6064bf5a2e2a1eefbc38c8e3528
acf0a4b34cd01.torrent' resumed. (fast resume)
21/09/2014 00:12:12 - 
'/home/denis/.local/share/data/qBittorrent/BT_backup/b61d2e4b8dd073b7340e8d3d8bf
fd27cdace3f18.torrent' resumed. (fast resume)
21/09/2014 00:12:12 - 
'/home/denis/.local/share/data/qBittorrent/BT_backup/ab01f3ca8089c83eb4ca18a33ae
6c9a6203afc7a.torrent' resumed. (fast resume)
21/09/2014 00:12:12 - 
'/home/denis/.local/share/data/qBittorrent/BT_backup/9b171b1070cb39d63c7d5dc3c21
06b86411ad0f5.torrent' resumed. (fast resume)
21/09/2014 00:12:12 - 
'/home/denis/.local/share/data/qBittorrent/BT_backup/43c396a30ed6abb323a7587401c
8a3cde35d5a38.torrent' resumed. (fast resume)
21/09/2014 00:12:12 - Options were saved successfully.
21/09/2014 00:12:12 - Embedded Tracker [OFF]
21/09/2014 00:12:12 - Encryption support [ON]
21/09/2014 00:12:12 - Local Peer Discovery support [ON]
21/09/2014 00:12:12 - PeX support [ON]
21/09/2014 00:12:12 - DHT support [ON], port: UDP/6881
21/09/2014 00:12:12 - Anonymous mode [OFF]
21/09/2014 00:12:12 - HTTP user agent is qBittorrent v3.1.9.2
21/09/2014 00:12:12 - UPnP / NAT-PMP support [ON]
21/09/2014 00:12:12 - qBittorrent is trying to listen on any interface port: 
TCP/6881
21/09/2014 00:12:12 - Peer ID: -qB3192-
Qbittorent branch=v3_1_x commit e4df5572088c4b7c3601cf31aaf3ec0b2fdb33f2
libtorrent tags/libtorrent-0_16_18
All trackers have "not working" status

Original comment by detana...@gmail.com on 20 Sep 2014 at 8:19

[GoogleCodeExporter]

Some updates: http trackers does not working but getting peers from udp trackers

Original comment by detana...@gmail.com on 20 Sep 2014 at 8:46

[GoogleCodeExporter]

the "connection refused" suggests that you set up a socks5 proxy that you fail 
to connect to. is that the case?

Original comment by arvid.no...@gmail.com on 20 Sep 2014 at 9:47

[GoogleCodeExporter]

Yes, sock4 0.0.0.0:8080 has been enable. I'm definitely didn't choose proxy, 
maybe accidental mouse wheel move to scroll main scrollbar in preferences when 
cursor has been over combo box.
After disabling proxy all have gone fine. Thanks a lot

Original comment by detana...@gmail.com on 21 Sep 2014 at 7:05