maemo.org Bugzilla – Bug 9151
Stack trace when attempting to connect to a VPN with a group
Last modified: 2010-02-24 18:20:00 UTC
You need to log in before you can comment on or make changes to this bug.
SOFTWARE VERSION: Latest 1.1.1 update, though it happened on 1.1 as well. EXACT STEPS LEADING TO PROBLEM: Nokia-N900-51-1:~# openconnect -u bill.clinton -w password 111.222.333.444 Attempting to connect to 111.222.333.444 SSL negotiation with 111.222.333.444 Connected to HTTPS on 111.222.333.444 GET 111.222.333.444/ GET 111.222.333.444/+webvpn+/index.html Please enter your username and password. GROUP: [group1|group2|group3]:group2 *** glibc detected *** openconnect: free(): invalid pointer: 0xbeff9813 *** ======= Backtrace: ========= /lib/libc.so.6[0x410901b8] /lib/libc.so.6[0x410914d4] /lib/libc.so.6(cfree+0xb8)[0x41091764] openconnect[0x12150] openconnect[0x12e8c] openconnect[0x115f8] openconnect(vfprintf+0xedc)[0xbd74] /lib/libc.so.6(__libc_start_main+0x108)[0x4103c974] openconnect(getpwnam+0x34)[0xaf80] ======= Memory map: ======== 00008000-00017000 r-xp 00000000 fe:01 39844 /usr/bin/openconnect 0001e000-0001f000 rw-p 0000e000 fe:01 39844 /usr/bin/openconnect 0001f000-00040000 rw-p 0001f000 00:00 0 [heap] 40000000-40002000 rw-p 40000000 00:00 0 4000b000-4000d000 rw-p 4000b000 00:00 0 41000000-4101c000 r-xp 00000000 fe:01 14880 /lib/ld-2.5.so 41023000-41025000 rw-p 0001b000 fe:01 14880 /lib/ld-2.5.so 41028000-4113f000 r-xp 00000000 fe:01 14839 /lib/libc-2.5.so 4113f000-41147000 ---p 00117000 fe:01 14839 /lib/libc-2.5.so 41147000-41148000 r--p 00117000 fe:01 14839 /lib/libc-2.5.so 41148000-4114a000 rw-p 00118000 fe:01 14839 /lib/libc-2.5.so 4114a000-4114d000 rw-p 4114a000 00:00 0 41150000-4115b000 r-xp 00000000 fe:01 14690 /lib/libgcc_s.so.1 4115b000-41162000 ---p 0000b000 fe:01 14690 /lib/libgcc_s.so.1 41162000-41163000 rw-p 0000a000 fe:01 14690 /lib/libgcc_s.so.1 412c8000-412ca000 r-xp 00000000 fe:01 14707 /lib/libdl-2.5.so 412ca000-412d1000 ---p 00002000 fe:01 14707 /lib/libdl-2.5.so 412d1000-412d2000 r--p 00001000 fe:01 14707 /lib/libdl-2.5.so 412d2000-412d3000 rw-p 00002000 fe:01 14707 /lib/libdl-2.5.so 41320000-4138d000 r-xp 00000000 fe:01 14837 /lib/libm-2.5.so 4138d000-41394000 ---p 0006d000 fe:01 14837 /lib/libm-2.5.so 41394000-41395000 r--p 0006c000 fe:01 14837 /lib/libm-2.5.so 41395000-41396000 rw-p 0006d000 fe:01 14837 /lib/libm-2.5.so 413d0000-413e0000 r-xp 00000000 fe:01 14078 /usr/lib/libz.so.1.2.3 413e0000-413e7000 ---p 00010000 fe:01 14078 /usr/lib/libz.so.1.2.3 413e7000-413e8000 rw-p 0000f000 fe:01 14078 /usr/lib/libz.so.1.2.3 41808000-41922000 r-xp 00000000 fe:01 13973 /usr/lib/libxml2.so.2.6.32 41922000-41929000 ---p 0011a000 fe:01 13973 /usr/lib/libxml2.so.2.6.32 41929000-4192f000 rw-p 00119000 fe:01 13973 /usr/lib/libxml2.so.2.6.32 42050000-42171000 r-xp 00000000 fe:01 12699 /usr/lib/libcrypto.so.0.9.8 42171000-42178000 ---p 00121000 fe:01 12699 /usr/lib/libcrypto.so.0.9.8 42178000-4218d000 rw-p 00120000 fe:01 12699 /usr/lib/libcrypto.so.0.9.8 4218d000-42190000 rw-p 4218d000 00:00 0 423e0000-4241b000 r-xp 00000000 fe:01 12702 /usr/lib/libssl.so.0.9.8 4241b000-42423000 ---p 0003b000 fe:01 12702 /usr/lib/libssl.so.0.9.8 42423000-42427000 rw-p 0003b000 fe:01 12702 /usr/lib/libssl.so.0.9.8 bef98000-beffa000 rw-p bef9e000 00:00 0 [stack] Aborted EXPECTED OUTCOME: VPN Connection ACTUAL OUTCOME: Stack trace :) REPRODUCIBILITY: always EXTRA SOFTWARE INSTALLED: OpenSSH, plenty of other things OTHER COMMENTS: Some usernames/passwords/IP addrs were modified to protect the guilty.
Thanks for the report. Could you please try openconnect for Linux (http://www.infradead.org/openconnect.html), first with version 2.12 and then with version 2.21. I'm trying to see if the problem should be reported upstream or if it is specific to openconnect for maemo. thanks
Attempted with 2.12. Wouldn't connect, but no stack trace either. Just kept giving me "Login failed" even with my correct user/pass (as far as I can tell). Moving on to 2.21.
Unfortunately, I'm now apparently having difficulty with my login. I didn't get a stack trace with 2.21 either, but it gave me the same "Login failed" message. So I decided to try logging in with the official Cisco VPN program, and it wouldn't let me log in either, so my user/pass must be expired or something. Unfortunately, I think that means that the two tests I just ran aren't necessarily valid. I'll have to get my login sorted out and then try again.
If the crash happened in 2.11 but not in 2.12, then it was probably http://git.infradead.org/users/dwmw2/openconnect.git/commitdiff/a1e1686b
I attempted to connect with 2.11, 2.12, and 2.21. All of them succeeded in connecting. There was no stack trace for any of them: sudo ./openconnect -u bleh 111.222.333.444 Attempting to connect to 111.222.333.444 SSL negotiation with 111.222.333.444 Connected to HTTPS on 111.222.333.444 GET 111.222.333.444/ GET 111.222.333.444/+webvpn+/index.html Please enter your username and password. GROUP: [group1|group2|group3]:group2 PASSWORD: POST 111.222.333.444/+webvpn+/index.html Got CONNECT response: HTTP/1.1 200 OK CSTP connected. DPD 30, Keepalive 30 SSL_set_session() failed with old protocol version 0x100 Your OpenSSL may lack Cisco compatibility support See http://rt.openssl.org/Ticket/Display.html?id=1751 Use the --no-dtls command line option to avoid this message Set up DTLS failed; using SSL instead Connected tun0 as 111.222.333.444, using SSL + deflate Sorry about that :)
With what version of openconnect was the original backtrace seen? I believe it was caused by a 1-byte buffer overflow, so it's expected that it would behave differently on different architectures and at different times. Was your latest 2.21 test done on the N900 or on another machine?
The three tests that I described in my last update were done with a separate Intel Ubuntu 9.10 box with executables compiled from source. The only version of openconnect that I have available on the N900 is the one downloaded from the repos.
(In reply to comment #7) > The only version > of openconnect that I have available on the N900 is the one downloaded from the > repos. Which is version 2.12...
Hm, in that case I'm very interested in the crash; I'm not aware of anything I fixed since 2.12 which would have caused it. There was some confusion about the handling of group names and other things we got from the XML form, but those were only memory leaks and never (IIRC) a use-after-free or double-free. If you can catch it with GDB and give me a proper backtrace, that would be much appreciated. Just running under valgrind on a PC might suffice, although it'll give you a lot of warnings about OpenSSL code.