This seems to occur the first time that vSend is called from an IPsec test. I recall that it would be test number 2 or 3. I will gather more detail in the morning.
It does not occur when vSend is called from Core tests.
If you need additional information, please feel free to request it.
Thank you for your help.
cheers,
Tony
________________________________________
From: Yukiyo Akisada [akisada@tahi.org]
Sent: Monday, June 09, 2008 7:02 PM
To: Anthony Coon
Cc: users@tahi.org
Subject: Re: [users:00753] TAHI Ipsec pktsend getting SEGV
Hi, Anthony.
Wow!
It's really critical...
Could you tell me the test number or test script name?
I want to repeat this situation also in my environment.
Thanks,
On Fri, 6 Jun 2008 14:03:15 -0700
Anthony Coon <acoon@vmware.com> wrote:
>
> Greetings,
>
> I am setting up the TAHI Ipsec suite 1.1.2 with v6eval 3.0.14. The TAHI Core 4.0.1 is also installed. System is freebsd 7.0.
>
> The Core tests seem to run as expected.
>
> The Ipsec test sets the SADs and SPDs on the NUT, then vSend fails with error 139, which is pktsend failing with error 139. There is a pktsend.core in ipsec.p2. Backtrace looks like:
>
> Core was generated by `pktsend'.
> Program terminated with signal 11, Segmentation fault.
> Reading symbols from /lib/libcrypto.so.5...done.
> Loaded symbols for /lib/libcrypto.so.5
> Reading symbols from /usr/lib/libstdc++.so.6...done.
> Loaded symbols for /usr/lib/libstdc++.so.6
> Reading symbols from /lib/libm.so.5...done.
> Loaded symbols for /lib/libm.so.5
> Reading symbols from /lib/libgcc_s.so.1...done.
> Loaded symbols for /lib/libgcc_s.so.1
> Reading symbols from /lib/libc.so.7...done.
> Loaded symbols for /lib/libc.so.7
> Reading symbols from /libexec/ld-elf.so.1...done.
> Loaded symbols for /libexec/ld-elf.so.1
> #0 0x28459887 in calloc () from /lib/libc.so.7
> (gdb) bt
> #0 0x28459887 in calloc () from /lib/libc.so.7
> #1 0x28459b7e in free () from /lib/libc.so.7
> #2 0x282a39ba in CRYPTO_free () from /lib/libcrypto.so.5
> #3 0x282606ea in EVP_MD_CTX_cleanup () from /lib/libcrypto.so.5
> #4 0x28223350 in HMAC_CTX_cleanup () from /lib/libcrypto.so.5
> #5 0x080df031 in MfHMAC::result (this=0x28528c40, cp=0x2852f180 " ¼-(") at MfAlgorithm.cc:455
> #6 0x0805c37b in PfAuth::result (this=0x2855e790) at PAlgorithm.cc:181
> #7 0x0805c41a in PaAH::ICV_Calculate (this=0x28559f00, s=@0xbfbfe4dc) at PAlgorithm.cc:61
> #8 0x080bf7c5 in WmESP_ICV::post_generate (this=0x28536dd0, c=@0xbfbfe9c0, buf=@0x2857c160)
> at McESP.cc:441
> #9 0x080bd292 in MmESP_ICV::geneAuto (this=0x2852dd80, c=@0xbfbfe9c0, w_self=0x28536dd0,
> buf=@0x2857c160) at McESP.cc:334
> #10 0x080ed4bd in MObject::generate (this=0x2852dd80, c=@0xbfbfe9c0, w_self=0x28536dd0,
> buf=@0x2857c160) at McObject.cc:75
> #11 0x080f94f6 in MmElement::generate (this=0x2852dd80, c=@0xbfbfe9c0, w_self=0x28536dd0,
> ... And on and on....
>
> I have a feeling this is something really simple like a configuration that I missed, but it seems to be in the Ipsec test because the Core pktsend works as expected. One helpful hint would be how to debug pktsend from the shell prompt, it doesn't seem to be very straightforward.
>
> Any help or ideas would be greatly appreciated.
>
> Cheers,
> Tony
>
> =================
> Tony Coon
> acoon@vmware.com
>
> "No amount of careful planning will ever replace dumb luck"
>
>
>
--
Yukiyo Akisada <akisada@tahi.org>