[Openvpn-devel] OpenVPN 1.6-rc1 released

[James Yonan]

This is a release candidate for 1.6.0.

The main change from 1.6-beta7 is that the Windows version now uses --ip-win32
dynamic by default.

Change Log:

2004.03.02 -- Version 1.6-rc1

* For Windows, make "--ip-win32 dynamic" the default.
* For Windows, make "--route-delay 10" the default
  unless --ip-win32 dynamic is not used or --route-delay
  is explicitly specified.
* L_TLS mutex could have been left in a locked state
  for certain kinds of TLS errors.


James

Re: [Openvpn-devel] Files missing from BETA20 CVS

[James Yonan]

Matthias Andree  said:

> Hi,
> 
> the files list.c, mroute.c and multi.c appear to be missing from the
> BETA20 branch in CVS:
> 
> ma@merlin:~/cvs-3rdparty/openvpn> LANG=C make -ks 2>&1 | grep ^make
> make[1]: *** No rule to make target `list.c', needed by `list.o'.
> make[1]: *** No rule to make target `mroute.c', needed by `mroute.o'.
> make[1]: *** No rule to make target `multi.c', needed by `multi.o'.
> make[1]: *** [openvpn.o] Error 1
> make[1]: Target `all-am' not remade because of errors.
> make: *** [all] Error 2

Ooops, it looks like I forgot to do a cvs add on some new files.

It's fixed now, and the BETA20 branch has been updated to reflect my current
development sources (I also updated the ChangeLog).

The current source should build and run a point-to-point tunnel correctly
using all the refactored code.  Grep for JYFIXME to see a bunch of gotchas in
the source -- mostly stuff that's there for debugging purposes.

The point-to-multipoint code is taking shape in multi.[ch] but is not finished
yet.

James

Re: [Openvpn-devel] OpenVPN multi instancing

[James Yonan]

Christian Lademann  said:

> Hello, James hello, Christian,
> 
> is it also going to be supported in 2.0 to have multiple tup/tap interfaces
> but only a single TCP-port on the server side waiting for incoming 
> connections?

The ultimate goal is to have all connection options open in either
point-to-point or point-to-multipoint mode.  The initial 2.0 beta will
specialize in serving multiple clients on a single UDP port, single tun/tap
interface, and single config file.

Actually if you want single TCP-port, one tun/tap interface per client, that
sounds like the inetd-based forking server model which is already functional
(in a limited sense) in the 1.6 beta series.  The limitation is that you use
SSL/TLS + bridging.  See the FAQ for more info.

James

Re: [Openvpn-devel] OpenVPN multi instancing

[James Yonan]

Matthias Andree  said:

> On Mon, 01 Mar 2004, James Yonan wrote:
> 
> > Christian Daniel  said:
> > 
> > > Hello everybody!
> > > 
> > > For a student research project I'm trying to add multi instance
capability to 
> > > OpenVPN. The basic idea is to rip the main openvpn()-function apart, put
all 
> > > variables in a struct and then have only one select()-call for all open 
> > > tunnels at once.
> > 
> > It's already been done :)
> > 
> > See the BETA20 branch in the CVS.
> 
> Is there a document that mentions the development tags so the daring
> know what to check out? Or a mailing list I should subscribe to?

It's not too complicated.  The HEAD branch is stable, or a beta series which
is leading to a stable release, i.e. 1.6-betaX.  The BETA20 branch at this
point mostly contains a lot of refactorization.  All the stuff that used to be
on the stack in the openvpn() function is now kept in a struct context. 
openvpn.c and the main() function is clean and minimalistic once again.

Every major or beta release gets a tag that is constructed from the version
number.  When I do a cvs commit I use this simple script:

cvs commit -m "version $OPENVPN_VER" && cvs tag `echo openvpn-$OPENVPN_VER |
tr . -`

where $OPENVPN_VER is something like "1.6-beta7" or "1.5.0".

> May I suggest to post the pointer to the document or add one to
> openvpn.sourceforge.net?

There's not a lot of people actually working on the code right now, so it's
easier to just ask questions on the list or search the archives.

James

Re: [Openvpn-devel] OpenVPN multi instancing

[Christian Lademann]

Hello, James hello, Christian,

is it also going to be supported in 2.0 to have multiple tup/tap interfaces
but only a single TCP-port on the server side waiting for incoming connections?

Regards,

Christian Lademann

[Openvpn-devel] Files missing from BETA20 CVS

[Matthias Andree]

Hi,

the files list.c, mroute.c and multi.c appear to be missing from the
BETA20 branch in CVS:

ma@merlin:~/cvs-3rdparty/openvpn> LANG=C make -ks 2>&1 | grep ^make
make[1]: *** No rule to make target `list.c', needed by `list.o'.
make[1]: *** No rule to make target `mroute.c', needed by `mroute.o'.
make[1]: *** No rule to make target `multi.c', needed by `multi.o'.
make[1]: *** [openvpn.o] Error 1
make[1]: Target `all-am' not remade because of errors.
make: *** [all] Error 2

Best wishes,
Matthias

Re: [Openvpn-devel] OpenVPN multi instancing

[Matthias Andree]

On Mon, 01 Mar 2004, James Yonan wrote:

> Christian Daniel  said:
> 
> > Hello everybody!
> > 
> > For a student research project I'm trying to add multi instance capability 
> > to 
> > OpenVPN. The basic idea is to rip the main openvpn()-function apart, put 
> > all 
> > variables in a struct and then have only one select()-call for all open 
> > tunnels at once.
> 
> It's already been done :)
> 
> See the BETA20 branch in the CVS.

Is there a document that mentions the development tags so the daring
know what to check out? Or a mailing list I should subscribe to?

May I suggest to post the pointer to the document or add one to
openvpn.sourceforge.net?

Thanks. (It's incredible how much room for improvement OpenVPN still
has, while having been stable and production-ready for so long already.)

-- 
Matthias Andree

Encrypt your mail: my GnuPG key ID is 0x052E7D95

Re: [Openvpn-devel] OpenVPN multi instancing

[Matthias Andree]

On Sun, 29 Feb 2004, Christian Daniel wrote:

> Hello everybody!
> 
> For a student research project I'm trying to add multi instance capability to 
> OpenVPN. The basic idea is to rip the main openvpn()-function apart, put all 
> variables in a struct and then have only one select()-call for all open 
> tunnels at once.

Oh. You're in for plentiful fun with the various select()
"features"^Wbugs across the various operating system kernels.

Better check out poll() and epoll() where available. These happen to
(usually) be more scalable as the number of fds increases.

> Each tunnel should have it's own tun/tap-device open - the linux kernel has 
> no 
> problem to cope with so many interfaces... I don't think, that it's a good 
> idea, to create only one tun-device and then have some kind of internal 
> routing-engine...

It cannot work. The interfaces have distinct addresses and netmasks, for
some kind of internal routing-engine, you'd have to re-implement the
stack on top of raw sockets. Not easy, not portable, not desirable.

> - how to handle the garbage collection? Is it really necessary or is the code 
> leak-free?

go figure as a side project, going to fill your thesis or
homework or whatever other paper or PDF you're going to turn in. :-)

-- 
Matthias Andree

Encrypt your mail: my GnuPG key ID is 0x052E7D95