tinc - Feb 2007 - Branches (again)

A long long time ago, I asked about the different tinc branches.  
Guus, you said at the time that

* trunk is 1.0, bugfixes only
* 1.0-gnutls, POKEY, and pre4-cube are stagnant
* 2.0 is where new work should happen...at the time, it didn't  
compile, and it appears it still doesn't

This answer discouraged me; I have trouble getting excited about new  
work in a branch that's been around for a long time but still doesn't  
build, much less incorporate all the bugfixes and such that have  
happened in trunk since branching.

Is it possible I can convince you to rethink the approach of 2.0? I  
think your 1.0 code is quite good, and it would be possible to  
refactor it into whatever you want 2.0 to be, never even making a  
checkin that doesn't compile. For example, I see that you want 2.0 to  
use libevent. If it'd make the 1.0 branch live on, I'd be happy to  
convert it to libevent.

I ask because there are four features tinc lacks that I would like to  
see. I'd even be willing to try writing them myself, if there were an  
appropriate branch in which to do so. (You even generously offered to  
create a review branch for me, but I don't know on which branch it  
could be based...)

Anyway, here are the features:

1. A control socket. I find it frustrating to turn on debugging in  
syslog, send tincd a meaningless signal name, and look for results in  
a logfile, then turn off syslog debugging again before my hard drive  
fils. I'd rather have something like bind 9.0's rndc that  
communicates over a UNIX-domain socket:

     $ sudo tincc -n slamb.org show-connections
     Connections:
       scooby at 69.55.229.92 port 655 options 1 socket 8 status 01c2  
outbuf 1553/0/0
       calvin at 216.136.66.56 port 655 options 1 socket 7 status  
00c2 outbuf 1594/0/0
       hobbes at 63.99.9.243 port 655 options 1 socket 9 status 00c2  
outbuf 1566/0/0
     End of connections.

     $ sudo tincc -n slamb.org dump-graph connections.png

     $ sudo tincc -n slamb.org reconnect scooby

2. Continuously updating edge weights. tincd sometimes starts an  
outgoing connection when my link is unusually slow, and it causes it  
to pick the wrong path for packets until I restart the daemon. It  
would be slick to have something like exponentially weighted average  
path weights, based on the pings it already does every so often.

3. Better firewall/NAT support. I'd like it to at least send the  
pings the same way it sends the data, so it can detect that a path is  
no good. It might even fall back to TCP only or (to be really fancy)  
use STUN.

4. Better TCP-only security.

#1 and possibly #2 would not require protocol changes, so they could  
happen in 1.0 if it were to live on. So could work like converting to  
libevent. 2.0 could be rebranched when one of the protocol changes is  
ready, and not be so different that it'd be impossible to merge  
between them.

Oh by the way - thanks for catching that stupid close() bug in my  
last patch. Ironically similar to the sort of bug I was trying to fix...

Best regards,
Scott

-- 
Scott Lamb <http://www.slamb.org/>

On Sat, Feb 24, 2007 at 01:56:24PM -0800, Scott Lamb wrote:

[...]
> Is it possible I can convince you to rethink the approach of 2.0? I  
> think your 1.0 code is quite good, and it would be possible to  
> refactor it into whatever you want 2.0 to be, never even making a  
> checkin that doesn't compile.
Actually, that might be a good idea!
> For example, I see that you want 2.0 to  use libevent. If it'd make
> the 1.0 branch live on, I'd be happy to  convert it to libevent.
>
> I ask because there are four features tinc lacks that I would like to  
> see. I'd even be willing to try writing them myself, if there were an  
> appropriate branch in which to do so. (You even generously offered to  
> create a review branch for me, but I don't know on which branch it  
> could be based...)
Maybe I should create a 1.1 branch where we can work on implementing
libevent support and some of the other things you mention, as long as
they don't break backwards compatibility.
> Anyway, here are the features:
> 
> 1. A control socket. I find it frustrating to turn on debugging in  
> syslog, send tincd a meaningless signal name, and look for results in  
> a logfile, then turn off syslog debugging again before my hard drive  
> fils. I'd rather have something like bind 9.0's rndc that  
> communicates over a UNIX-domain socket:
[...]

That is definitively also on my TODO list.
> 2. Continuously updating edge weights. tincd sometimes starts an  
> outgoing connection when my link is unusually slow, and it causes it  
> to pick the wrong path for packets until I restart the daemon. It  
> would be slick to have something like exponentially weighted average  
> path weights, based on the pings it already does every so often.
That would be nice, but the only way to implement that with the 1.0
protocol is to periodically disconnect and reconnect connections, and
that is probably just as bad as restarting the daemon completely.
> 3. Better firewall/NAT support. I'd like it to at least send the  
> pings the same way it sends the data, so it can detect that a path is  
> no good. It might even fall back to TCP only or (to be really fancy)  
> use STUN.
My own idea for 2.0 would be to use 1.0's "TCPOnly" as the
default, and
to automatically detect if UDP is possible between to hosts or not, and
if so upgrade to UDP on the fly.

Any tinc daemon in a VPN could act as a STUN server for two others if
they have trouble connecting to each other on their own.
> 4. Better TCP-only security.
That would be switching to TLS, and that's something for 2.0 since it
would be incompatible with 1.0.
> 2.0 could be rebranched when one of the protocol changes is  
> ready, and not be so different that it'd be impossible to merge  
> between them.
I agree.
> Oh by the way - thanks for catching that stupid close() bug in my  
> last patch. Ironically similar to the sort of bug I was trying to fix...
Actually, Wessel Dankers noticed it. I guess this is an example of
"given enough eyeballs, all bugs are shallow" :)

-- 
Met vriendelijke groet / with kind regards,
     Guus Sliepen <guus@tinc-vpn.org>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
Url :
http://brouwer.uvt.nl/pipermail/tinc/attachments/20070224/61e3d62f/attachment.pgp