simple as possible.
So to put it short, I do agree with you.
SaBe
> Hi Sampo,
>
> See comments inline...
>
> Sampo Nurmentaus said:
>
> >
> > Hi James,
> >
> > The original reason for the new option for me was the
> > ability to move the de
Hi James,
The original reason for the new option for me was the
ability to move the device file away from /dev.
This was of cource a really special need to
help me porting openvpn to an embedded platform.
How about if --dev would check if the given
device name begins with / and if so it would
u
ematic, mostly
> for efficiency reasons (since packets must be dispatched, it increases the
> number of context switches per packet).
>
> James
>
> Sampo Nurmentaus said:
>
> >
> >
> > Hello,
> >
> > Sorry it took so long to reply, but I haven&#
Hello,
Sorry it took so long to reply, but I haven't read my work
mail for a while due to all the exams.
We have been using openvpn with this multiple connection
hack of mine for a while with our embedded linux systems
and it has been running fine. Still there is a lot of
testing to do and it ai
> > > Hi Sampo,
> > >
> > > > I have been busy writing a forking server
> > > > addon to openvpn.
>
> Will forking server only work for TLS mode?
No, It works also with shared secret or without
security.
For prefork security I could use either the key used
for tls-auth or preshared secret.
Any e
hi,
> Hi Sampo,
>
> > I have been busy writing a forking server
> > addon to openvpn.
>
> Cool... Does each potential connecting client need a separate config file,
> or does the server use a common client template and then keep track of
> things like dynamic ports, dynamic endpoint addresses, etc
Hello James and Michael,
I have been busy writing a forking server
addon to openvpn.
In openvpn.c I have separated the processing of
parameters from main() to a new function and
moved main to another file to allow me to
link against different main() functions.
One that implements normal peer2pee
I agree,
I think that allowing the usage of multiple,
possibly old, protocols adds complexity and
may couse some vulnerabilities.
A cracker could force the daemon to use
some old protocol with security holes
fixed in later versions.
Sampo
> > I'd like to hear your opinions on how the OpenVPN
would instantiate OpenVPN's core peer-to-peer code for each
> new session. It would also be nice if we could do it without changing the
> protocol or making too many changes to the core peer-to-peer code which is
> nicely stable and robust right now.
>
> >
> > > Scalability is another issue. There are some good ideas in the open
> > > source
> > > world for reducing the number of tunnels in an n-way network. tinc for
> > > example will use broadcasts and MAC address discovery over a tap (virtual
> > > ethernet) tunnel to deduce the destination of the packets, and allow one
> > > tap
> > > tunnel to connect to n peers.
> >
> > What stops servers from connecting to another servers forming a
> > hierarcy of nodes? This makes it possible to reduce number of
> > clients per server. Of course this also requires the servers to
> > be able to exchange routing information, but that does not have
> > to be taken care by openvpn.
>
> It's nice if the OS can take care of routing. But if we leave routing up
> to the OS (as we do now), then the VPN must deal with potentially a
> large number of tun or tap devices in an n-way network, and scalability
> could become an issue.
>
> > Best regards,
> > Sampo Nurmentaus
> >
>
> Thanks,
> James
>
>
>
roadcasts and MAC address discovery over a tap (virtual
> ethernet) tunnel to deduce the destination of the packets, and allow one tap
> tunnel to connect to n peers.
What stops servers from connecting to another servers forming a
hierarcy of nodes? This makes it possible to reduce number of
clients per server. Of course this also requires the servers to
be able to exchange routing information, but that does not have
to be taken care by openvpn.
Best regards,
Sampo Nurmentaus
am it was mutch more
easy to port than freeswan, since kernel hackin'
would have required a million reflashings and
a great deal of serial debugging, since our
device has no display.
Sampo Nurmentaus
>
> Thanks James,
>
> It really helped. Simple recrosscompiling first kernel
>
tun.h which is identical to one in the kernel
source tree.
Any ideas?
Sampo Nurmentaus
> From: "Sampo Nurmentaus"
> To:
> Sent: Wednesday, June 12, 2002 8:31 AM
> Subject: [Openvpn-devel] Porting to an embedded linux
>
>
> > Hello folks,
> >
> >
>
eturns with the very same
error text.
I compiled support to kernel (not as a module)
so it should always be there.
Any ideas?
Thanx in advange,
Sampo Nurmentaus
13 matches
Mail list logo
