Commit 0f2403f9 authored by Guillaume Bury's avatar Guillaume Bury

Big TODO update

parent 8f1a9bbb
For Ulysse : useful is spelled with only ONE l and not two..... For Ulysse : useful is spelled with only ONE l and not two.....
+ ALL files should now respect a maximum 80 rows convention
Bugs : Bugs :
When no peer is avalaible, the setup crash without the --no-boot option => see below When no peer is avalaible, the setup crash without the --no-boot option
=> see below
To be done : To be done :
Use an algorithm to choose which connections to keep and/or establish instead or pure randomness Use an algorithm to choose which connections to keep and/or establish
Find a name for the project : the projet is ( or should be ) independant from vifib, openvpn, babel, instead of pure randomness
and so should the name; btw we aim to build a distributed, scalable, resilient VPN.... Find a name for the project : the projet is ( or should be ) independant
Replace comments at the beginning of functions with docstrings & give all fn docstrings from vifib, openvpn, babel, and so should the name; btw we aim to build a
Use the server events ( client connection/deconnection ) to do something useful distributed, scalable, resilient VPN.... ( if it helps with the name )
In peers DB, remove some peers when they are too many of them -> remove the dead peers Replace comments at the beginning of functions with docstrings & give all
fn docstrings
Use the server events ( client connection/deconnection ) to do something
useful
In peers DB, remove some peers when they are too many of them -> remove the
dead peers
Use a timeout for the peersDB -> ?, removing the dead peers should be enough Use a timeout for the peersDB -> ?, removing the dead peers should be enough
Specify a lease duration in ForwardViaUPnP Specify a lease duration in ForwardViaUPnP
Handle LAN internally in order not to have catastrophic results ....
To be discussed: To be discussed:
U : Babel seems to be very long to establish the routes : maybe we should tell him thant we are not on a wired network but on a mobile network ? G : To get traffic stats ( bytes in/out ), you can use
G : babel establish routes quickly enough i'd say. There are two new options : hello and wireless, for hello_interval and /sys/class/net/interface/statistics/rx_bytes, etc...
treating all interfaces as wireless. However, treating an interface as wireless doesn't lessen the hello_interval, it only or /proc/net/dev/snmp6/interface ( all in one file ). This can be enough
changes how babel estimates quality link, and cost. if used as follows: get traffic diff from last time we checked in order
to choose which connection is significantly unused compared to others,
and close it. Of course, too recent connections (i.e. those for which we
have no previous stat) would be always kept.
U : Contact the server using vifibnet and not the underlying network when possible U : Babel seems to be very long to establish the routes : maybe we should
G : done by giving the vifibnet address of the server. Anyways, if you give the 'internet' address of the server, tell him thant we are not on a wired network but on a mobile network ?
it CANNOT be reached via vifib, as there isn't yet a border vpn through which the internet traffic would be routed G : babel establish routes quickly enough i'd say. There are two new
options : hello and wireless, for hello_interval and treating all
interfaces as wireless. However, treating an interface as wireless
doesn't lessen the hello_interval, it only changes how babel estimates
quality link, and cost.
U : The peer DB size should depend on the number of connection and the refresh time U : Contact the server using vifibnet and not the underlying network when
G : ?! I don't agree, the db size should be proportional ( with a factor like 0.01 or less ) to the total number of peers in the entire network, with maybe a max size. possible
G : done by giving the vifibnet address of the server. Anyways, if you give
the 'internet' address of the server, it CANNOT be reached via vifib,
as there isn't yet a border vpn through which the internet traffic
would be routed
U : The peer DB size should depend on the number of connection and the
refresh time
G : ?! I don't agree, the db size should be proportional ( with a factor
like 0.01 or less ) to the total number of peers in the entire network,
with maybe a max size.
U : Remove the --no-boot option since we know when no node is avalaible U : Remove the --no-boot option since we know when no node is avalaible
G : the no-boot option is only useful when the server knows no peer, G : the no-boot option is only useful when the server knows no peer,
irl it should never happen, no-boot is a debug option irl it should never happen, no-boot is a debug option
U : Ok, but the server knows when no peers is avalaible, doesn't he ? U : Ok, but the server knows when no peers is avalaible, doesn't he ?
G : Well when no peer is available the SQL request ( + next() method ) raise a StopIteration exception G : Well when no peer is available the SQL request ( + next() method ) raise
a StopIteration exception
G : don't reconnect to server each time we repopulate in peers_db ? G : don't reconnect to server each time we repopulate in peers_db ?
U : From what I've read on the internet, when you create a server object, you don't connect to the server, U : From what I've read on the internet, when you create a server object,
You only connect to the server once you send a request for a methode and then you can automatically use the same connection for 15sec you don't connect to the server, You only connect to the server once you
G : ok, it justs need testing ( for when some requests for the server will require to be plugged in the network ) send a request for a methode and then you can automatically use the same
connection for 15sec
G : ok, it justs need testing ( for when some requests for the server will
require to be plugged in the network )
U : Use more than one boostrap node U : Use more than one boostrap node
G : we'll use the server as a bootstrap node G : we'll use the server as a bootstrap node
...@@ -68,3 +68,11 @@ def router(network, internal_ip, interface_list, ...@@ -68,3 +68,11 @@ def router(network, internal_ip, interface_list,
utils.log(str(args), 5) utils.log(str(args), 5)
return subprocess.Popen(args, **kw) return subprocess.Popen(args, **kw)
def watch(interface):
return ( subprocess.call(['ip6tables', '-I', 'INPUT', '-i', interface]) and
subprocess.call(['ip6tables', '-I', 'OUTPUT', '-o', interface]))
def unwatch(interface):
return ( subprocess.call(['ip6tables', '-D', 'INPUT', '-i', interface]) and
subprocess.call(['ip6tables', '-D', 'OUTPUT', '-o', interface]))
...@@ -54,7 +54,7 @@ class TunnelManager: ...@@ -54,7 +54,7 @@ class TunnelManager:
for peer_id, ip, port, proto in self._peer_db.getUnusedPeers(self._client_count - len(self._connection_dict)): for peer_id, ip, port, proto in self._peer_db.getUnusedPeers(self._client_count - len(self._connection_dict)):
utils.log('Establishing a connection with id %s (%s:%s)' % (peer_id, ip, port), 2) utils.log('Establishing a connection with id %s (%s:%s)' % (peer_id, ip, port), 2)
iface = self.free_interface_set.pop() iface = self.free_interface_set.pop()
self._connection_dict[peer_id] = ( self._connection_dict[peer_id] = (
plib.client( ip, self._write_pipe, self._hello, plib.client( ip, self._write_pipe, self._hello,
'--dev', iface, '--proto', proto, '--rport', str(port), *self._ovpn_args, '--dev', iface, '--proto', proto, '--rport', str(port), *self._ovpn_args,
stdout=os.open(os.path.join(log, 'vifibnet.client.%s.log' % (peer_id,)), stdout=os.open(os.path.join(log, 'vifibnet.client.%s.log' % (peer_id,)),
......
Markdown is supported
0%
or
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment