Hi,
the following patch was posted to trac#261, and I intend to ACK it
(patches to track are a bit complicated regarding our standard policy
and --author :-/ - but it's simple enough, and while a very esoteric
corner case, fixing a real bug :-) - namely, --redirect-private in
combination with --de
Your patch has been applied to the master branch.
Apologies for overlooking patch and ACK on the list - dunno what happened,
I just saved both mails to my "done!" folder, without actually merging...
(which might explain my somewhat confused replies later, sorry again)
commit 7d30696ac51aa9649f229
A non-working nameserver in /etc/resolv.conf could lead to endless
loops inside openvpn_getaddrinfo(), because many systems will only
pick up changes to resolv.conf if res_init() is called again.
To reproduce, run openvpn with --resolv-retry infinite (2.3) or
--resolv-retry "a high number" (master
A signal (except SIGUSR1) received while waiting for getaddrinfo() is
considered fatal, so openvpn_getaddrinfo() is destroying the returned
information with freeaddrinfo(), but still signalled "success" (0)
to the caller - so if the caller accessed *res before checking
*signal_received, it would ac
Hi,
On Sun, May 31, 2015 at 10:41:58PM +0200, Gert Doering wrote:
> A signal (except SIGUSR1) received while waiting for getaddrinfo() is
> considered fatal, so openvpn_getaddrinfo() is destroying the returned
> information with freeaddrinfo(), but still signalled "success" (0)
> to the caller - s
