I've done some work on getting openvpn to tunnel ipv6 without having to
use TAP tunnels. I think to get ipv6 tunneling to work on other platforms
it may require changes in the tunnel driver. But I figure I'll post this
here as it might be of use to somebody.
Regards,
Aaron
Index: Makefile.in
On Sat, 28 Sep 2002, James Yonan wrote:
> Aaron,
>
> Thanks for the patch, however I was not able to get it to work with IPv4
> while talking between a 2.4.9 and 2.4.17 kernel, where both peers are running
> the patch. The code compiles and runs, but pings don't go through. Perhaps
> there i
On Fri, 4 Oct 2002, James Yonan wrote:
> Hi Aaron,
>
> I've incorporated your IPv6 over tun patch for Linux into the latest OpenVPN
> beta, and added some basic infrastructure code and a --tun-ipv6 option which
> enables the IPv6 over tun support. The option makes a placeholder for all
> OSes
On 28 Oct 2002, Craig Knox wrote:
> Hi there,
>I use QoS routing and it works great except over openvpn/tun device.
>
>Correct me if I am wrong but I think this is because the packets are
> encapsulated within a UDP packet with no regard to what the original
> packets TOS field was, so onc
On Wed, 30 Oct 2002, James Yonan wrote:
>
> Some caveats that immediately come to mind:
>
> * Since OpenVPN does not assume a particular TUN encoding of IP traffic, this
> patch requires OpenVPN to assume an offset of the TOS bits.
Well if you end up looking at the ip header by using struct iphdr
Here is a simple little replacement for system() that does close file
descriptors. The main issue with it is though, it ends up picking an
arbitrary number of fds to close. I picked closing 0 to 99.
Aaron
int s_system(const char *string)
{
pid_t pid;
int x;
pid = fork()
On Mon, 10 Feb 2003, Alberto Gonzalez Iniesta wrote:
>
> Hi,
>
> Again, I'm no C hacker, but I think this should be better:
>
> for(x = 3; x < 100; x++)
>
> Since the first 3 fds (stdin, stdout and stderr) should be kept open.
>
Wasn't sure if stdin, stdout and stderr needed to be left open or not
On Tue, 11 Feb 2003, James Yonan wrote:
> /* Set a file descriptor to not be passed across execs */
> void
> set_cloexec (int fd)
> {
> if (fcntl (fd, F_SETFD, FD_CLOEXEC) < 0)
> msg (M_ERR, "Set file descriptor to FD_CLOEXEC failed");
> }
>
> Just set the FD_CLOEXEC flag on the fd and it won
On Mon, 10 Feb 2003, Christoph Pfisterer wrote:
>
>fcntl(fd, F_SETFD, FD_CLOEXEC);
>
> Ideally, one would do this for each file descriptor as it is opened.
>
Yeah I hadn't thought about that, James already added this to the CVS
tree.
Aaron
On Sat, 22 Feb 2003, James Yonan wrote:
> This might be handled in a way similar to --ping-restart or SIGHUP/SIGUSR1,
> where the openvpn daemon would essentially restart if the MTU size changed.
> This would be effective if path MTU changes are infrequent but still creates
> problems when --user/
On Fri, 18 Apr 2003, James Yonan wrote:
> I'm forwarding this discussion of an interesting feature request. Namely,
> could (and should) OpenVPN have a channel bonding capability, where more than
> one UDP connection over different paths is used to connect two peers, and
> OpenVPN does channel bo
On Wed, 23 Apr 2003, Matthias Andree wrote:
> On Wed, 23 Apr 2003, James Yonan wrote:
>
> > I wonder if one could build a better tcp-over-tcp by doing some intelligent
> > packet filtering on the higher level tcp connection, such as filtering out
> > retransmits and fudging return ACKs -- essenti
On Thu, 24 Apr 2003, James Yonan wrote:
> Actually, I was thinking more about the situation where people are forced to
> tunnel IP over TCP, for whatever reason, when UDP is not an option. Since IP
> is designed to transit over an unreliable physical layer, when you tunnel it
> over TCP (a la vpnd
On Mon, 28 Apr 2003, Alberto Gonzalez Iniesta wrote:
> Hi all,
>
> Sorry for the huge forward, but everything needed to understand this
> problem should be there :)
>
> GPL software does not mix well with OpenSSL, and that's giving me some
> headaches lately. As you me see in my mail to Markus (li
On Mon, 28 Apr 2003, bishop wrote:
> >> Of course another option here is to consider getting OpenVPN to play nice
> >> with gnutls, though I am not familiary with the maturity of that piece of
> >> software.
>
> Does anyone else here consider this to be entirely the wrong way to go?
I'm not sayin
One of the things that I just thought about is, that we can probably have
openvpn call sched_setscheduler() using something like SCHED_RR. This
might be of more use than just renicing the process. Considering we are
in a fairly performance critical path for a userspace process this would
seem to
I was considering writing a patch for openvpn that would apply to work
using raw ethernet frames as for my current network situation the overhead
of using udp/ip is mostly pointless. Are there any gotchas I should
consider before coding this up?
Regards,
Aaron
On Tue, 10 Jun 2008, Andrzej Chmielowiec wrote:
Hi All,
I send two patches to OpenVPN which gives Elliptic Curve support.
These patches work fairly well for me in the bit of use I gave them. I
was actually in the process of coding up a patch for this myself, but you
beat me to the punch.
18 matches
Mail list logo
