openvpn-devel Mailing List for OpenVPN

OpenVPN-devel is intended for those who are actively involved in working on OpenVPN's source code. Your issue is more appropriate for OpenVPN-users, as it discusses usage rather than development of OpenVPN. That said -- try disabling the tap-win32 adapter. If you still see the issue, you'll have ruled out OpenVPN as its cause. 

SSBzZXQgdXAgYSBWUE4gZm9yIGEgY2xpZW50IHdpdGggYSBzbWFsbCBvZmZpY2UgYmV0d2VlbiBh IGNvbXB1dGVyIGluIHRoZWlyCm9mZmljZSBhbmQgYSByb2FtaW5nIGxhcHRvcCwgYm90aCBydW5u aW5nIFhQLiBJbiB0aGUgcHJvY2VzcyBJIHdhcyB0cnlpbmcgdG8KcG9ydC1mb3J3YXJkIGEgaG9s ZSB0aHJvdWdoIHRoZWlyIGxpbmtzeXMgcm91dGVyIGZpcmV3YWxsLCBhbmQga2VwdCBnZXR0aW5n CjQwNCBlcnJvcnMuIFNvIEkgdXBncmFkZWQgdGhlIGxpbmtzeXMgdG8gdGhlIGxhdGVzdCBmaXJt d2FyZS4gKEkgd2lzaCBJCmNvdWxkIHNheSBwcmVjaXNlbHkgd2hhdCBtb2RlbCBpdCB3YXMsIGJ1 dCBJIGRvbid0IHJlY2FsbC4gSSB0aGluayBpdCB3YXMKbm90IGEgd3J0NTRnIGFsdGhvdWdoIHRo ZSBtZW51cyBsb29rIHRoZSBzYW1lIGFzIGEgd3J0NTRnKQogVGhlIDQwNCBlcnJvcnMgd2VudCBh d2F5LCBidXQgdGhlIG5leHQgZGF5IHRoZSBYUCBib3ggaW4gdGhlIG9mZmljZSBkaWRuJ3QKZ2V0 IGEgREhDUCBhZGRyZXNzLiBUaGVuIHRoZSBsYXB0b3Agd2FzIGJyb3VnaHQgaW4gYSBmZXcgZGF5 cyBsYXRlciBhbmQgYWxzbwp3b3VsZCBub3QgZ2V0IGEgREhDUCBhZGRyZXNzLiBPdGhlciBYUCBi b3hlcyBpbiB0aGUgb2ZmaWNlIHN0aWxsIGdldCBESENQCmZyb20gdGhlIGxpbmtzeXMganVzdCBm aW5lLiBTdGF0aWMgYWRkcmVzc2VzIHdvcmsgZmluZSwgc28gY29ubmVjdGl2aXR5Cmlzbid0IGFu IGlzc3VlIC0gdGhleSBqdXN0IHdvbid0IGdldCBhIGRoY3AgYWRkcmVzcyBmcm9tIHRoZSBsaW5r c3lzLiBUaGlzCmlzIHJlZ3VsYXIgd2lyZWQgZXRoZXJuZXQsIHRoZSB3b3Jrc3RhdGlvbi9zZXJ2 ZXIgaXMgYSBEZWxsIGFuZCBJIHRoaW5rIHRoZQpsYXB0b3AgaXMgYW4gSFAuCiBJcyB0aGVyZSBh bnkgcmVhc29uIHdoeSB0aGlzIG1pZ2h0IGJlIGhhcHBlbmluZyB0aGF0IGNvdWxkIGJlIHJlbGF0 ZWQgdG8KT3BlblZQTj8gVGhhdCBpcyB0aGUgb25seSB0aGluZyBfSV8gY2FuIHRoaW5rIG9mIChh c2lkZSBmcm9tIGhhcHB5CmNvaW5jaWRlbmNlKSB0aGF0IHRob3NlIHR3byBjb21wdXRlcnMgaGF2 ZSBpbiBjb21tb24gdGhhdCB0aGUgb3RoZXIgWFAKY29tcHV0ZXJzIGluIHRoZSBvZmZpY2UgZG9u J3QuCgotLQpIYW5zIEZ1Z2FsCkZ1Z2FsIENvbXB1dGluZwo=

Hi all, I've been trying to compile openvpn 2.0.2 with lzo-1.08, and openssl-0.9.7d installed (corresponding dev-packages also). While compiling I get the following error: gcc -O2 -g -march=i586 -mcpu=i686 -fmessage-length=0 -o openvpn base64.o buffer.o crypto.o error.o event.o fdmisc.o forward.o fragment.o gremlin.o helper.o init.o interval.o list.o lzo.o manage.o mbuf.o misc.o mroute.o mss.o mtcp.o mtu.o mudp.o multi.o ntlm.o occ.o openvpn.o options.o otime.o packet_id.o perf.o ping.o plugin.o pool.o proto.o proxy.o push.o reliable.o route.o schedule.o session_id.o shaper.o sig.o socket.o socks.o ssl.o status.o thread.o tun.o -lssl -lcrypto -llzo -ldl lzo.o(.text+0x7cd): In function `lzo_compress_init': /usr/src/packages/BUILD/openvpn-2.0.2/lzo.c:112: undefined reference to `__lzo_init_v2' collect2: ld returned 1 exit status make[1]: *** [openvpn] Fehler 1 make[1]: Leaving directory `/usr/src/packages/BUILD/openvpn-2.0.2' make: *** [all] Fehler 2 error: Bad exit status from /var/tmp/rpm-tmp.10360 (%build) Any hints THX in advance 

On Wed, 28 Sep 2005, Matthias Andree wrote: > I have worked quite a bit with Berkeley DB (which SVN set off with as > its database backend) in bogofilter, and while lots of things are to be > said about BDB robustness and corruptions, the most important point of > criticism is that one needs to take BDB by the hand and guide it, and it > doesn't tolerate application bugs that cause BDB to be used improperly. > If used properly, it's fast and solid - but then you've entered the > realm of transactions, and they're as awful to hack as GTK+ or assembly > language - it's all raw and low-level. True, but SVN supports different repository formats, and BDB is just one option (and rather deprecated at this point). I'm using an FSFS repository, which gets away from nearly all of the disadvantages of BDB. James 

On 9/27/05, Marcelo Toledo <ma...@ma...> wrote: > I have one OpenVPN server version 2.0.2 using TCP port 1194 with TLS > with about 400 clients connected to it. From time to time it's > impossible to ping the client from the server, but if you log into the > client and ping the server, the server now became able to ping the > client. I made a lot of tests removing the bridge and trying a older > versions of openvpn and the problem still hapenning with about 20% of > the clients connected to the vpn. > > here is the config of the client and server: > > # SERVER CONFIG > mode server > port 1194 > proto tcp-server > dev tap [snip] Observations: 1. 400 clients... 1 server only? 2. TAP means additional overhead full ethernet packet encapsulated in TCP/IP packet. Broadcasts, fragmented ethernet datagrams and for 400 clients.... 3. TCP over TCP is not recommended. The internal congestion control can conflict with the external congestion control. 4. What is your full bandwidth and usable bandwidth at the server? Troubleshooting: Do packet captures on the real interfaces that the VPN tunnel is using (there the TCP 1194 traffic is), the TAP interfaces. Look for TCP issues. Recommendations: 1. switch to UDP 2. switch to TUN even if this requires additional configuration. to rely on broadcasts over a VPN is problematic. 3. Bandwidth may be a major bottleneck. suggestions 1 & 2 will help, but it may not be enough. 4. Server look for bottlenecks, may require upgrade(s). Removing one bottleneck may reveal the next bottleneck... -- Leonard Isham, CISSP Ostendo non ostento.