Opened 4 years ago

Last modified 4 months ago

#639 assigned Bug / Defect

non-interruptible loop in windows dns resolution failure

Reported by: Gert Döring Owned by: stipa
Priority: major Milestone: release 2.4
Component: Generic / unclassified Version: OpenVPN git master branch (Community Ed)
Severity: Not set (select this one, unless your'e a OpenVPN developer) Keywords: windows signal dns loop
Cc: tincantech

Description

  • win7 VM with no IPv6 (no interface has v6, so win7 disables v6 altogether)
  • git master 6417a6f8a0
  • connecting with "--proto udp6"
  • run from console window

-> result is a "DNS resolution fails, retrying" (because windows will refuse to even lookup a v6 record if "there is no v6 in the system!") endless loop, neither ctrl-c nor f1...f4 work.

Didn't try from GUI, was too annoyed at my VM setup... but should be reproduceable easy enough.

The endless loop happens on Windows as well, but ctrl-c works - here's a linux log:

Mon Dec 14 19:42:29 2015 RESOLVE: Cannot resolve host address: v4only.greenie.net:1194 (Name or service not known)
Mon Dec 14 19:42:29 2015 Could not determine IPv4/IPv6 protocol
Mon Dec 14 19:42:29 2015 SIGUSR1[soft,init_instance] received, process restarting
Mon Dec 14 19:42:29 2015 Restart pause, 5 second(s)
Mon Dec 14 19:42:34 2015 Control Channel Authentication: tls-auth using INLINE static key file
Mon Dec 14 19:42:34 2015 Outgoing Control Channel Authentication: Using 160 bit message hash 'SHA1' for HMAC authentication
Mon Dec 14 19:42:34 2015 Incoming Control Channel Authentication: Using 160 bit message hash 'SHA1' for HMAC authentication
Mon Dec 14 19:42:34 2015 RESOLVE: Cannot resolve host address: v4only.greenie.net:1194 (Name or service not known)
Mon Dec 14 19:42:34 2015 RESOLVE: Cannot resolve host address: v4only.greenie.net:1194 (Name or service not known)
Mon Dec 14 19:42:34 2015 Could not determine IPv4/IPv6 protocol
Mon Dec 14 19:42:34 2015 SIGUSR1[soft,init_instance] received, process restarting
Mon Dec 14 19:42:34 2015 Restart pause, 5 second(s)
^CMon Dec 14 19:42:35 2015 SIGINT[hard,init_instance] received, process exiting

Change History (6)

comment:1 Changed 4 years ago by Gert Döring

Owner: set to stipa
Status: newassigned

comment:2 Changed 4 years ago by Gert Döring

thanks :)

comment:3 in reply to:  description Changed 4 years ago by selvanair

Replying to cron2:

  • win7 VM with no IPv6 (no interface has v6, so win7 disables v6 altogether)
  • git master 6417a6f8a0
  • connecting with "--proto udp6"
  • run from console window

-> result is a "DNS resolution fails, retrying" (because windows will refuse to even lookup a v6 record if "there is no v6 in the system!") endless loop, neither ctrl-c nor f1...f4 work.

Didn't try from GUI, was too annoyed at my VM setup... but should be reproduceable easy enough.

The endless loop happens on Windows as well, but ctrl-c works

A quick question: is this with Xen, KVM, something else? I've seen ctrl-c sometimes ignored on windows 10 even on physical hardware, though a few tries always work.

Please try ctrl-break as well. Although it was added along with ctrl-c, the former is delivered by windows as a signal, the latter as a key-press like f1..f4, while running from console.

comment:4 Changed 4 years ago by selvanair

Failed DNS resolution can loop can become non-interruptible even on Linux: as a test use an unsused ip number as the nameserver in resolv.conf and start a connection. Nearly impossible to break out of it by SIGINT or SIGTERM.

There are a number of places in socket.c where sig_info->signal_received is assigned to SIGUSR1, overwriting previous value which could be SIGTERM or SIGINT (e.g., line socket.c:1919 which appears to be the culprit in this case). Note that sig_info here is a pointer to signinfo_static and its members are volatile. They can change when signals interrupt.

Interestingly its the hard SIGTERM/SIGINT that is easily lost in this case -- a SIGTERM simulated through the management doesn't get noticed until the loop restarts and goes back to init.c. So it survives this blatant over-write of signal_received in socket.c

comment:5 Changed 3 years ago by Gert Döring

see also #311 which is the same issue but got forgotten in the meantime *sigh*

comment:6 Changed 4 months ago by tincantech

Cc: tincantech added
Note: See TracTickets for help on using tickets.