[Vtun-Users] Vtun 2.6 segfaults with lzo2 on amd64

Discussion:

Lawrence Stewart

2008-07-02 02:40:14 UTC

Hi,

Hey Folks,
I haven't got a machine I can use to confirm this one. Who here's using
an x86_64-built vtund with lzo?

I can confirm that on a FreeBSD 7-STABLE AMD64 server running vtun-3.0.2
and lzo2-2.03_1 installed from ports, use of lzo:9 compression causes
vtund (running in server tunnel mode) to segfault the moment I attempt
to send any data over the tun device it instantiates. Switching to using
zlib compression completely resolves the issue.

I've examined the core file it dumps in gdb and unfortunately it's
completely useless. I'll try have a go at truss'ing or ktracing the
vtund process and report back if that produces anything useful.

Cheers,
Lawrence

- bish

Hi Guys,
I have followed all the instructions bellow and got my vtun 2.6 compiled
with liblzo-2.02 (lib64lzo packages from Mandriva) without errors.
However, when it tries to establish connection it segfaults shortly
vtund: segfault at 40 rip 408abe rsp 7ffff0a3cc40 error 4
My system is 2 AMD64 dual core processors (Madriva 2008.1). With lzo
compression off it works flawlessly. I am using encryption in both
cases. Is there any way to get the old good vtun 2.6 working with both
lzo compression and encryption on the modern 64bit systems?
Thanks for any advice in advance,
Taka
-------- Forwarded Message --------
*Subject*: Re: [Vtun-devel] VTUN 2.6 link failure w/lzo_malloc when
linking against LZO_V2.02 -- SOLVED
*Date*: Thu, 22 Mar 2007 14:09:04 -0400
One more piece, important during the make that I forgot to mention,
relevant to versions > 1 of LZO--
Need to make a symbolic link AFTER lzo is compiled and installed, find
where it's at using "whereis" or "locate".
Using database... -rw-r--r-- 1 root root 522559 2007-03-22
06:40 /var/tmp/updatedb.gz
/usr/local/lib/liblzo2.so.2.0.0
*/usr/local/lib/liblzo2.a*
/usr/local/lib/liblzo2.la <http://liblzo2.la/>
/usr/local/lib/liblzo2.so
/usr/local/lib/liblzo2.so.2
/usr/local/lib/liblzo.a
/usr/local/src/lzo-2.02/src/.libs/liblzo2.so.2.0.0
/usr/local/src/lzo-2.02/src/.libs/liblzo2.lai
/usr/local/src/lzo-2.02/src/.libs/liblzo2.a
/usr/local/src/lzo-2.02/src/.libs/liblzo2.la <http://liblzo2.la/>
/usr/local/src/lzo-2.02/src/.libs/liblzo2.so
/usr/local/src/lzo-2.02/src/.libs/liblzo2.so.2
/usr/local/src/lzo-2.02/src/liblzo2.la <http://liblzo2.la/>
Make sure there is a symbolic link of liblzo.a (the name of the original
*lrwxrwxrwx 1 root root 9 2007-03-20 21:47 liblzo.a ->
liblzo2.a*
-rw-r--r-- 1 root root 771314 2007-03-20 21:40 liblzo2.a
-rwxr-xr-x 1 root root 804 2007-03-20 21:40 liblzo2.la
<http://liblzo2.la/>
lrwxrwxrwx 1 root root 16 2007-03-20 21:40 liblzo2.so
-> liblzo2.so.2.0.0
lrwxrwxrwx 1 root root 16 2007-03-20 21:40 liblzo2.so.2
-> liblzo2.so.2.0.0
-rwxr-xr-x 1 root root 431746 2007-03-20 21:40 liblzo2.so.2.0.0
Otherwise you'll get an error during the make when it's trying to find
the liblzo.a file.
Take care,
David
--
David Beecher
TekOps, Inc.
http://www.tekops.com <http://www.tekops.com/>

bishop

2008-07-02 04:29:17 UTC

Permalink

Hey Lawrence,

Guess what I just noticed. The original question was on vtun 2.6, 64bit
and lzo2. Vtun 26 was never built or tested on 64-bit, to my knowledge,
and pre-dates lzo2 by a goodly long time too. It's probably far out of
the support that's possible, and I think in the case of the original
question vtun 30x should be tested.

Now, the trace/truss of your tests with 302 could tell us quite a bit,
and do send them along as soon as you get them. I'll have a chance to
look at it only this Monday, so don't rush to make a deadline before
then. Feel free to send them along to the devel list, or just to me, if
you don't want to spam the users@ list.

- bish

Post by Lawrence Stewart
Hi,

Hey Folks,
I haven't got a machine I can use to confirm this one. Who here's using
an x86_64-built vtund with lzo?

I can confirm that on a FreeBSD 7-STABLE AMD64 server running vtun-3.0.2
and lzo2-2.03_1 installed from ports, use of lzo:9 compression causes
vtund (running in server tunnel mode) to segfault the moment I attempt
to send any data over the tun device it instantiates. Switching to using
zlib compression completely resolves the issue.
I've examined the core file it dumps in gdb and unfortunately it's
completely useless. I'll try have a go at truss'ing or ktracing the
vtund process and report back if that produces anything useful.
Cheers,
Lawrence

- bish

-------------------------------------------------------------------------
Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW!
Studies have shown that voting for your favorite open source project,
along with a healthy diet, reduces your potential for chronic lameness
and boredom. Vote Now at http://www.sourceforge.net/community/cca08
_______________________________________________
Vtun-Users mailing list
https://lists.sourceforge.net/lists/listinfo/vtun-users

--
People don't know that vi was written for a world that
doesn't exist anymore -- Bill Joy, creator of vi
http://www.theregister.co.uk/2003/09/11/bill_joys_greatest_gift/

Lawrence Stewart

2008-07-02 05:58:33 UTC

Permalink

Post by bishop
Hey Lawrence,
Guess what I just noticed. The original question was on vtun 2.6, 64bit
and lzo2. Vtun 26 was never built or tested on 64-bit, to my knowledge,
and pre-dates lzo2 by a goodly long time too. It's probably far out of
the support that's possible, and I think in the case of the original
question vtun 30x should be tested.

hrrm yes good point, and I agree with your support/testing comment as well.

Post by bishop
Now, the trace/truss of your tests with 302 could tell us quite a bit,
and do send them along as soon as you get them. I'll have a chance to
look at it only this Monday, so don't rush to make a deadline before
then. Feel free to send them along to the devel list, or just to me, if

rgr. Probably makes sense to send the info to the devel list to have it
archived somewhere. I'll subscribe and post the info there sometime
before Monday.

Cheers,
Lawrence

Post by bishop
- bish

Post by Lawrence Stewart
Hi,

Hey Folks,
I haven't got a machine I can use to confirm this one. Who here's using
an x86_64-built vtund with lzo?

I can confirm that on a FreeBSD 7-STABLE AMD64 server running vtun-3.0.2
and lzo2-2.03_1 installed from ports, use of lzo:9 compression causes
vtund (running in server tunnel mode) to segfault the moment I attempt
to send any data over the tun device it instantiates. Switching to
using zlib compression completely resolves the issue.
I've examined the core file it dumps in gdb and unfortunately it's
completely useless. I'll try have a go at truss'ing or ktracing the
vtund process and report back if that produces anything useful.
Cheers,
Lawrence

- bish