Re: [Openvpn-devel] Openvpn 2.1.1 bad tcp performance but good pingwhen -l 1472 (with packet size = MTU)
On Fri, 2010-03-05 at 09:42 -0500, Michael H. Warfield wrote: > On Fri, 2010-03-05 at 09:01 +0100, Gert Doering wrote: > > Hi, > > > > On Thu, Mar 04, 2010 at 05:21:43PM -0600, open...@rkmorris.us wrote: > > > I did this in the client configuration file ... is this right? > > > I checked the OpenVPN web site, and it may be that I need this on > > > the server side instead. Please clarify and I'll try it again (if > > > I need to). > > > > "socket-flags TCP_NODELAY" > > that would need to go into both(!) config files - it changes the way the > > operating system handles write() calls into a socket, that is, whether > > the OS waits for "more data" to eventually generate a full sized packet, > > or whether it will send the data immediately (generating a small packet). > > (This is a fundamental problem with TCP - the stacks are optimized for > > certain patterns, either "bulk data, make full size packets" or > > "interactive traffic, send single bytes of keystrokes, where a few ms > > delay don't hurt", but not for VPN-like traffic) > Oh WOW... I hadn't even thought of that. That's got to be the A #1 > reason right there for avoiding the use of tcp like the plague for > things like these. > > That means that OpenVPN is (to use the older terminology - I'm old > school) not using the PUSH OOB method to push packets out and to get > them received immediately at the other end. Looking that the > socket_write calls, that would seem to be the MSG_OOB option. I use to > remember in days ancient using TCP_URGENT and TCP_PUSH flags for things > like that (TCP_URGENT was used by ftp clients to abort interrupted data > streams). All I see in socket.h is "MSG_NOSIGNAL". Yeah, that would > probably do it. TCP_NODELAY is going to disable the naggle algorithm > and disable the send buffering but I don't think it's going to set the > TH_PUSH flag in the tcp header so what the received side does with it is > up to the received side, isn't it? Yeah, I know, PUSH is an optional > feature in tcp implementations but it's been in every one I've worked > with and I see the comments about it having it's own problems. But how > in the world would anyone expect a user space packet handler to work > efficiently over tcp STREAMS without it? You've got to work around > tcp's design to treat everything as a continuous stream and to optimize > it as a stream and not a series of packets. Looking at the man page on tcp is appears that MSG_OOB applies the TCP_URGENT semantic to the stream, not the TCP_PUSH. That would also entail a SIGURG signal on each packet on the receiver side. Maybe not such a good thing on every packet after all, even if you set that to SIG_IGNORE. :-P > If nothing else, I would always expect tcp vpn's the suck royally > without at least having TCP_NODELAY. Why isn't that the default. > > http://www.unixguide.net/network/socketfaq/2.11.shtml > > > gert > Mike Mike -- Michael H. Warfield (AI4NB) | (770) 985-6132 | m...@wittsend.com /\/\|=mhw=|\/\/ | (678) 463-0932 | http://www.wittsend.com/mhw/ NIC whois: MHW9 | An optimist believes we live in the best of all PGP Key: 0x674627FF| possible worlds. A pessimist is sure of it! signature.asc Description: This is a digitally signed message part
Re: [Openvpn-devel] Openvpn 2.1.1 bad tcp performance but good pingwhen -l 1472 (with packet size = MTU)
On Fri, 2010-03-05 at 09:01 +0100, Gert Doering wrote: > Hi, > > On Thu, Mar 04, 2010 at 05:21:43PM -0600, open...@rkmorris.us wrote: > > I did this in the client configuration file ... is this right? > > I checked the OpenVPN web site, and it may be that I need this on > > the server side instead. Please clarify and I'll try it again (if > > I need to). > > "socket-flags TCP_NODELAY" > that would need to go into both(!) config files - it changes the way the > operating system handles write() calls into a socket, that is, whether > the OS waits for "more data" to eventually generate a full sized packet, > or whether it will send the data immediately (generating a small packet). > (This is a fundamental problem with TCP - the stacks are optimized for > certain patterns, either "bulk data, make full size packets" or > "interactive traffic, send single bytes of keystrokes, where a few ms > delay don't hurt", but not for VPN-like traffic) Oh WOW... I hadn't even thought of that. That's got to be the A #1 reason right there for avoiding the use of tcp like the plague for things like these. That means that OpenVPN is (to use the older terminology - I'm old school) not using the PUSH OOB method to push packets out and to get them received immediately at the other end. Looking that the socket_write calls, that would seem to be the MSG_OOB option. I use to remember in days ancient using TCP_URGENT and TCP_PUSH flags for things like that (TCP_URGENT was used by ftp clients to abort interrupted data streams). All I see in socket.h is "MSG_NOSIGNAL". Yeah, that would probably do it. TCP_NODELAY is going to disable the naggle algorithm and disable the send buffering but I don't think it's going to set the TH_PUSH flag in the tcp header so what the received side does with it is up to the received side, isn't it? Yeah, I know, PUSH is an optional feature in tcp implementations but it's been in every one I've worked with and I see the comments about it having it's own problems. But how in the world would anyone expect a user space packet handler to work efficiently over tcp STREAMS without it? You've got to work around tcp's design to treat everything as a continuous stream and to optimize it as a stream and not a series of packets. If nothing else, I would always expect tcp vpn's the suck royally without at least having TCP_NODELAY. Why isn't that the default. http://www.unixguide.net/network/socketfaq/2.11.shtml > gert Mike -- Michael H. Warfield (AI4NB) | (770) 985-6132 | m...@wittsend.com /\/\|=mhw=|\/\/ | (678) 463-0932 | http://www.wittsend.com/mhw/ NIC whois: MHW9 | An optimist believes we live in the best of all PGP Key: 0x674627FF| possible worlds. A pessimist is sure of it! signature.asc Description: This is a digitally signed message part
Re: [Openvpn-devel] OpenVPN 2.1_rc19 released
On Wed, 2009-07-29 at 07:47 +0300, Alon Bar-Lev wrote: > Well, > I do not understand you guys. > If you think SELinux is so great, why do you need chroot? > It is like you put some money in safe, and then put the safe into > another safe, it never ends... Why only two safe, let's put another > safe... > I know that this is the approach many of security advisors use, but I > never could have found the logic. > If you want to keep your money safe use a single safe and select the > strongest one. Security professionals refer to is as "defense in depth". Look it up. The opposite of which is "all your eggs in one basket". Not good. With defense in depth, if an attacker finds a hole in one defensive layer, he should get caught in another. That way, he has to be perfect and get through all your defenses without getting caught while you only have to stop him at one. The other way (single defense), your defense must always be perfect and reliable while he only needs a single hole through that single layer. Your choice. > And final note regarding the iproute wrapper. > It is a *WRAPPER*, if I needed top secured implementation I would have > created a daemon listening to network change requests using unix > domain sockets, wrap this up in SELinux profile, and implementing a > logic that allows only changes to tap/tun interface with specific > attributes, and allowing routing table update with specific details. > Then add a wrapper that uses the unix domain socket in order to access > the daemon. OpenVPN will use the wrapper so it needs no special > privilege. The daemon validates what SELinux or any other security > product cannot validate: Network configuration changes. All done > within a valid and separate context. > > As I wrote earlier, most of OpenVPN configurations need to execute > iproute also during session. For example, if you like to connect two > sites, your super SELinux secured solution will work only at one site. > > No need to discuss this further. I get your point. > > Alon. > > -- > Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day > trial. Simplify your report design, integration and deployment - and focus on > what you do best, core application coding. Discover what's new with > Crystal Reports now. http://p.sf.net/sfu/bobj-july > ___ > Openvpn-devel mailing list > Openvpn-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/openvpn-devel -- Michael H. Warfield (AI4NB) | (770) 985-6132 | m...@wittsend.com /\/\|=mhw=|\/\/ | (678) 463-0932 | http://www.wittsend.com/mhw/ NIC whois: MHW9 | An optimist believes we live in the best of all PGP Key: 0xDF1DD471| possible worlds. A pessimist is sure of it! signature.asc Description: This is a digitally signed message part
