Hi bish and all,
Here's the follow up information to my post to vtun-users last week
regarding this issue.
Problem summary: vtun 3.0.2 running in server tunnel mode with lzo:9
compression immediately segfaults when any data attempts to be sent over
the tunnel (the tunnel is created correctly though). Using zlib:9
compression completely mitigates the issue.
Here's a brain dump of everything I think could be pertinent. I don't
have the head space to review the vtun code myself, but I'm more than
happy to help debug the problem and test patches against the vtun 3.0.2
code base.
Ok, here we go...
########################################################################
[EMAIL PROTECTED] uname -a
FreeBSD server.xxx 7.0-STABLE FreeBSD 7.0-STABLE #1: Sat Jun 28 14:06:13
EST 2008 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/SERVER amd64
########################################################################
[EMAIL PROTECTED] pkg_info | grep "vtun\|lzo"
lzo2-2.03_1 Portable speedy, lossless data compression library
vtun-3.0.2 Virtual Tunnels over TCP/IP networks with traffic
shaping
Both were built from source using the FreeBSD ports system.
########################################################################
[EMAIL PROTECTED] which vtund
/usr/local/sbin/vtund
########################################################################
[EMAIL PROTECTED] ldd /usr/local/sbin/vtund
/usr/local/sbin/vtund:
libz.so.4 => /lib/libz.so.4 (0x800640000)
liblzo2.so.2 => /usr/local/lib/liblzo2.so.2 (0x800755000)
libcrypto.so.5 => /lib/libcrypto.so.5 (0x800873000)
libc.so.7 => /lib/libc.so.7 (0x800b05000)
########################################################################
[EMAIL PROTECTED] ifconfig tun0
tun0: flags=8051<UP,POINTOPOINT,RUNNING,MULTICAST> metric 0 mtu 1500
inet xxx.xxx.xxx.13 --> xxx.xxx.xxx.14 netmask 0xffff0000
Opened by PID 82644
This is the tun device opened by vtund with lzo compression in use. It
is identical to the tunnel opened when zlib compression is used i.e.
vtun appears to be functioning correctly up until the point where data
actually attempts to get sent over the tunnel. The second I try and send
a ping over the tunnel, vtund dumps core leaving a message like this in
my syslog:
Jul 7 10:47:03 server kernel: pid 82644 (vtund), uid 0: exited on
signal 11 (core dumped)
########################################################################
My vtund.conf the 100% reliably segfaults vtund:
[EMAIL PROTECTED] cat /usr/local/etc/vtund.conf
options {
port 5000;
syslog daemon;
ifconfig /sbin/ifconfig;
route /sbin/route;
}
conn {
speed 0;
passwd xxx;
type tun;
device tun0;
proto tcp;
compress lzo:9; # Don't use lzo on AMD64 as it's broken and
makes vtund seg fault
encrypt yes;
keepalive yes;
up {
# Connection is Up
ifconfig "%% xxx.xxx.xxx.13 xxx.xxx.xxx.14";
route "add xxx.xxx.xxx.14 -interface %%";
route "add xxx.xxx.xxx.0/16 xxx.xxx.xxx.14";
route "add xxx.xxx.xxx.16 -iface ng0";
route "add xxx.xxx.xxx.144 -iface ng0";
route "add xxx.xxx.xxx.0/16 xxx.xxx.xxx.14";
};
down {
route "delete xxx.xxx.xxx.144";
route "delete xxx.xxx.xxx.16";
};
}
########################################################################
Running truss on the vtun process that owns the tun device produces the
following information:
[EMAIL PROTECTED] truss -faeo /root/vtund302.truss -s 512 -p 82082
<cause vtund to segfault by sending a ping over the tunnel>
[EMAIL PROTECTED] cat /root/vtund302.truss
82082: select(6,{4 5},0x0,0x0,{30.000000}) = 1 (0x1)
82082: read(5," \0",2) = 2 (0x2)
82082: write(5,"@\0",2) = 2 (0x2)
82082: select(6,{4 5},0x0,0x0,{30.000000}) = 1 (0x1)
82082:
read(4,"E\0\0T\^]]\0\0?\^A<\M-g\M-,\^P\a;\M^H\M-:\M-e_\b\0\M-N\M-/\M-h
\^D\0\0Hq_R\0\n\M-.z\b\t\n\v\f\r\^N\^O\^P\^Q\^R\^S\^T\^U\^V\^W\^X\^Y\^Z
\^[\^\\^]\^^\^_ !"#$%&'()*+,-./01234567",2048) = 84 (0x54)
82082: SIGNAL 11 (SIGSEGV)
########################################################################
Running ktrace on the vtun process that owns the tun device produces the
following information:
[EMAIL PROTECTED] ktrace -idp 82204 -f /root/vtund302.ktrace -t +
<cause vtund to segfault by sending a ping over the tunnel>
[EMAIL PROTECTED] ktrace -C
[EMAIL PROTECTED] kdump -f /root/vtund302.ktrace
82204 vtund RET select 1
82204 vtund CALL read(0x4,0x6a5080,0x800)
82204 vtund GIO fd 4 read 84 bytes
0x0000 4500 0054 1fea 0000 3f01 3a5a ac10 |E..T....?.:Z..|
0x000e 073b 88ba e55f 0800 12e7 f604 0000 |.;..._........|
0x001c 4871 60b1 0003 5aeb 0809 0a0b 0c0d |Hq`...Z.......|
0x002a 0e0f 1011 1213 1415 1617 1819 1a1b |..............|
0x0038 1c1d 1e1f 2021 2223 2425 2627 2829 |.... !"#$%&'()|
0x0046 2a2b 2c2d 2e2f 3031 3233 3435 3637 |*+,-./01234567|
82204 vtund RET read 84/0x54
82204 vtund PSIG SIGSEGV SIG_DFL
82204 vtund NAMI "vtund.core"
########################################################################
I have kept one of the vtund.core files, but a cursory inspection of it
using gdb and attempting to get a backtrace produces no useful
information. I'm not a gdb guru though and I've never used in on amd64
FreeBSD so I could be doing something wrong and would welcome
suggestions on how to get useful information from it.
At first glance, the problem looks like a simple read bounds error...
but I'll leave drawing conclusions up to someone else.
Let me know if additional information would be useful or if there are
any particular additional tests I should run.
Cheers,
Lawrence
-------------------------------------------------------------------------
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-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/vtun-devel
