On Tue, Mar 3, 2015 at 10:32 AM, Alexander Haensch
<[email protected]> wrote:
> My configuration is very basic with the following :
>
> crl-verify file.pem
> tls-auth ta.key 0
>
> tun-mtu 48000
> is cipher BF-CBC
>
> As you already found, the crash frequency can be adjusted by the amount
> of reconnects / key expires.
>
>
>
>
> On 03.03.2015 16:10, Brent Cook wrote:
>> On Tue, Mar 3, 2015 at 5:58 AM, Alexander Haensch
>> <[email protected]> wrote:
>>> Today is good day for crashes, as i reinstalled one client, the crash
>>> happens very fast.
>> I'm trying to reproduce this by having a client reconnect in a loop
>> with the sample keys:
>>
>> while true; do sudo openvpn --remote 192.168.1.2 --proto tcp-client
>> --dev tun1 --ifconfig 10.0.0.1 10.0.0.2 --tls-client --ca ca.crt
>> --cert client.crt --key client.key --inactive 2; sleep 2; done
>>
>> with a server listening like so:
>>
>> sudo gdb --args openvpn --remote 192.168.1.1 --proto tcp-server --dev
>> tun1 --ifconfig 10.0.0.2 10.0.0.1 --tls-server --dh dh2048.pem --ca
>> ca.crt --cert server.crt --key server.key
>>
>> but haven't seen anything so far. Valgrind did complain a bit about an
>> uninitialized variable in blowfish encrypt, but I think this was a
>> false-postitive. Is there anything I could change above (algorithms,
>> etc.) that would make this simulation closer to your configuration?
I got another random crash in the client:
It looks like resolve_remote always expects at least sizeof(struct
sockaddr_in6) bytes to be returned from getaddrinfo(), rather than
checking the sin_len before copying.
There may be a handful of of OpenVPN bugs to whittle down:
(gdb) p *((struct sockaddr_in*)(ai->ai_addr))
$10 = {sin_len = 16 '\020', sin_family = 2 '\002', sin_port = 0,
sin_addr = {s_addr = 957786304}, sin_zero =
"\000\000\000\000\000\000\000"}
(gdb) p *((struct sockaddr_in6*)(ai->ai_addr))
Cannot access memory at address 0x52caf5f4ff0
#0 0x0000052a10473245 in resolve_remote (sock=0x52c44ae2200, phase=1,
remote_dynamic=0x0, signal_received=0x0) at socket.c:1270
#1 0x0000052a104738fb in link_socket_init_phase1 (sock=0x52c44ae2200,
connection_profiles_defined=false, local_host=0x0, local_port=0,
remote_host=0x7f7ffffcf4b3 "192.168.22.57", remote_port=1194, proto=3,
mode=0, accept_from=0x0,
http_proxy=0x0, socks_proxy=0x0, gremlin=0, bind_local=false,
remote_float=false, inetd=0, lsa=0x7f7ffffcec70, ipchange_command=0x0,
plugins=0x0, resolve_retry_seconds=1000000000,
connect_retry_seconds=5, connect_timeout=10,
connect_retry_max=0, mtu_discover_type=-1, rcvbuf=65536,
sndbuf=65536, mark=0, sockflags=0) at socket.c:1493
#2 0x0000052a10422c87 in do_init_socket_1 (c=0x7f7ffffce620, mode=0)
at init.c:2632
#3 0x0000052a10424336 in init_instance (c=0x7f7ffffce620,
env=0x52c2c851310, flags=4) at init.c:3416
#4 0x0000052a10423e95 in init_instance_handle_signals
(c=0x7f7ffffce620, env=0x52c2c851310, flags=4) at init.c:3245
#5 0x0000052a1044143c in tunnel_point_to_point (c=0x7f7ffffce620) at
openvpn.c:70
#6 0x0000052a10441866 in openvpn_main (argc=21, argv=0x7f7ffffcf2e8)
at openvpn.c:250
#7 0x0000052a104419b6 in main (argc=21, argv=0x7f7ffffcf2e8) at openvpn.c:325
