Re: [Openvpn-devel] MTU auto-discovery

> I am developing this patch on the 2.3 branch, as that is what I use for > my networking needs, but the files I am touching have not changed in > incompatible ways on the master. At the moment, the "Great > Reformatting" commit is the biggest stumbling block to rebasing this > patch to the

Re: [Openvpn-devel] MTU auto-discovery

I'm thinking that this feature would need to be able to be toggled on/off, because it will be noisy on networks that are trying to circumvent censorship systems, making for easy discovery of openvpn tunnels in Egypt / China / India / etc. It does look like a significant improvement for normal

[Openvpn-devel] MTU auto-discovery

Hello, I would like to gauge interest in including my upcoming MTU patch into the 2.5 release, and also to notify you that I am working on this patch, to avoid effort duplication, if any. Description of the "MTU auto-negotiation" patch: MTU settings will be fully auto-negotiated between

[Openvpn-devel] MTU handling on Windows

On Windows 7 at least you can set the MTU with netsh: netsh interface $PROTO set subinterface $TUNDEV mtu=$MTU store=active Where PROTO is 'ipv4' or 'ipv6' and the others are even more obvious. OpenVPN doesn't appear to do this; it seems to leave the MTU untouched and instead query the TAP

Re: [Openvpn-devel] MTU

Jan Johansson said: > On Sun, 2003-02-23 at 17:10, James Yonan wrote: > > Russ, > > > > Have you tried the tracepath utility to attempt to measure the Path MTU? > > > > Are the routers in the path properly forwarding ICMP code 3 (destination > > unreachable), and

Re: [Openvpn-devel] MTU

On Sun, 2003-02-23 at 17:10, James Yonan wrote: > Russ, > > Have you tried the tracepath utility to attempt to measure the Path MTU? > > Are the routers in the path properly forwarding ICMP code 3 (destination > unreachable), and ICMP code 4 (fragmentation needed but don't-fragment bit > set)?

Re: [Openvpn-devel] MTU

Aaron Sethman said: > > 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

Re: [Openvpn-devel] MTU

Russ, Have you tried the tracepath utility to attempt to measure the Path MTU? Are the routers in the path properly forwarding ICMP code 3 (destination unreachable), and ICMP code 4 (fragmentation needed but don't-fragment bit set)? Most MTU problems are caused by routers and firewalls which do

Re: [Openvpn-devel] MTU

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