Re: [Openvpn-devel] Re: New beta available + progress update

On Thu, 17 Apr 2003, James Yonan wrote: > The nice part about a radio link is that it is probably under your control, > meaning that you can ensure that ICMPs get properly passed. This allows path > MTU discovery to work and therefore solves a lot of the harder problems. Well, at least for the

Re: [Openvpn-devel] Re: New beta available + progress update

Matthias Andree said: > On Thu, 17 Apr 2003, James Yonan wrote: > > > A better alternative (orginally suggested by you) is to avoid fragmenting in > > the first place by bouncing back ICMP_DEST_UNREACH/ICMP_FRAG_NEEDED to the > > TUN > > device. This

Re: [Openvpn-devel] Re: New beta available + progress update

Matthias Andree said: > > http://openvpn.sourceforge.net/beta/openvpn-1.3.2.21.tar.gz (or CVS) > > I have a next round of patches to fix prototypes and types to quench > compiler warnings and get a more robust source code against changed > environments, to

[Openvpn-devel] Re: New beta available + progress update

On Thu, 17 Apr 2003, James Yonan wrote: > A better alternative (orginally suggested by you) is to avoid fragmenting in > the first place by bouncing back ICMP_DEST_UNREACH/ICMP_FRAG_NEEDED to the TUN > device. This won't work on TAP devices because the ethernet MTU is fixed at > 1500. > >

[Openvpn-devel] Re: New beta available + progress update

Matthias Andree said: > > What the FRAGMENT_ENABLE code does is to add an extra 4 byte header to each > > datagram that includes, among other things, feedback on the number of > > datagrams received as well as the maximum datagram size received. This > > information can

[Openvpn-devel] Re: New beta available + progress update

> http://openvpn.sourceforge.net/beta/openvpn-1.3.2.21.tar.gz (or CVS) I have a next round of patches to fix prototypes and types to quench compiler warnings and get a more robust source code against changed environments, to aid possible later debugging; it also includes GCC extensions (only used