unable to keep traffic private

[GoogleCodeExporter]

I am trying to make it so all traffic from a qbittorrent goes through VPN. I am 
aware of Issue 244 regarding outgoing traffic, but still, I'd like to correctly 
bind to a user-selected interface to properly respond to incoming traffic. The 
problem can reduced to a couple lines of python below:

rrrr@rrrr ~ $ cat test.py
# as per http://www.rasterbar.com/products/libtorrent/manual.html#session:
# (...) The constructor that only takes a fingerprint will not open a listen 
port for the session, to get it running you'll have to call 
session::listen_on(). 

# but:

import libtorrent
s = libtorrent.session()
if s.is_listening():
    print 'session.is_listening() == %s!' % (s.is_listening(),)
import subprocess
print subprocess.call('sudo netstat -nlp | fgrep python', shell=True)
rrrr@rrrr ~ $ python test.py 
session.is_listening() == True!
tcp        0      0 0.0.0.0:53626           0.0.0.0:*               LISTEN      
2729/python     
tcp        0      0 0.0.0.0:4433            0.0.0.0:*               LISTEN      
2729/python     
tcp6       0      0 :::53626                :::*                    LISTEN      
2729/python     
tcp6       0      0 :::4434                 :::*                    LISTEN      
2729/python     
udp        0      0 192.168.0.4:57917       0.0.0.0:*                           
2729/python     
udp        0      0 192.168.0.4:6771        0.0.0.0:*                           
2729/python     
udp        0      0 10.0.2.15:6771          0.0.0.0:*                           
2729/python     
udp        0      0 127.0.0.1:6771          0.0.0.0:*                           
2729/python     
udp        0      0 0.0.0.0:6771            0.0.0.0:*                           
2729/python     
udp        0      0 10.0.2.15:52853         0.0.0.0:*                           
2729/python     
udp        0      0 127.0.0.1:37704         0.0.0.0:*                           
2729/python     
udp        0      0 192.168.0.4:1900        0.0.0.0:*                           
2729/python     
udp        0      0 10.0.2.15:1900          0.0.0.0:*                           
2729/python     
udp        0      0 127.0.0.1:1900          0.0.0.0:*                           
2729/python     
udp        0      0 0.0.0.0:1900            0.0.0.0:*                           
2729/python     
udp        0      0 127.0.0.1:37894         0.0.0.0:*                           
2729/python     
udp        0      0 0.0.0.0:60462           0.0.0.0:*                           
2729/python     
udp        0      0 192.168.0.4:41127       0.0.0.0:*                           
2729/python     
udp        0      0 10.0.2.15:46394         0.0.0.0:*                           
2729/python     
udp        0      0 0.0.0.0:53626           0.0.0.0:*                           
2729/python     
udp6       0      0 :::53626                :::*                                
2729/python     
0
rrrr@rrrr ~ $ 

I would expect that libtorrent behaves as documented, so that it does not 
listen on a socket (nor it performs any network activity whatsoever), until 
listen_on() is called. Alternatively, I'd expect that there should be some 
other way to make sure no sensitive traffic whatsoever leaks over the insecure 
connection before things are bound properly (like an option to make the session 
initially paused, so that it can be properly set up before leaking traffic).

This has been tested on Ubuntu 14, but from what I found in the session() 
constructor in the newest tarball available for download on sourceforge 
(libtorrent-rasterbar-1.0.4.tar.gz), the issue is with default argument of 
'0.0.0.0' IP passed from the session constructor to session_impl constructor 
and what follows it, so every system should be affected. From what I can see, 
1.0.5 does exactly the same.

Original issue reported on code.google.com by reefiasty on 20 May 2015 at 11:19

[GoogleCodeExporter]

it appears this discrepancy has been in there for a while. (it looks like it 
was introduced somewhere in 0.10).

I'm inclined to consider this a documentation bug though. For these reasons:

1. ever since this was introduced, there's been a way to make the session 
listen on the interface and port you want at construction time.
2. It's a cleaner API to avoid having the possibility of a half-constructed 
session (i.e. one that hasn't had listen_on() called on it yet).
3. listen_on() will be deprecated in the next major release, and the only 
(non-deprecated) way to construct a session is by passing in settings to the 
constructor (which is a more flexible way of solving all race conditions 
between starting the session and setting the settings).

I have updated the documentation for the next stable 1.0.x release.

Original comment by arvid.no...@gmail.com on 31 May 2015 at 9:32

• Changed state: Fixed