On 02/03/2021 04:22, tincanteksup wrote:
On 28/02/2021 21:13, Gert Doering wrote:
Hi,
On Sun, Feb 28, 2021 at 08:02:54PM +0000, tincanteksup wrote:
Clearly, this is no longer the place to ask.
thanks .....................................
Ask, always.
Claim "this is a bug", only if you can back this by more than "oh,
this log line is confusing me".
The context of that log line is complex - socket.c,
link_socket_init_phase2(),
and it basically means "local bind, no address family specified, no
--remote known yet, need to choose a protocol for the actual bind()
call".
Since IPv6 sockets can handle dual-stack connections, this is what we
do if we do not know yet if the other end is IPv4 or IPv6, and no
protocol
is forced ("udp4" or "udp6").
I resubmit this as a genuine bug:
* Openvpn should error out on the rare occasions that it cannot select
the correct protocol, with an error directing the use of v4 or v6.
Openvpn should not proceed to fail.. without error.
So the crux of the discussion here is from this log line:
On 28/02/2021 18:09, tincanteksup wrote:
2021-02-28 08:00:36 Could not determine IPv4/IPv6 protocol. Using AF_INET6
(Selected IPv6 when IPv4 is required ?)
This is related to (which Gert rightfully says) the use of the bind()
call. Simply said, it ties together ("binds") a file descriptor socket
with a remote end. The remote end is defined with a protocol using
AF_INET or AF_INET6 for addressing in TCP/IP stack.
What might be quite unknown, confusing or surprising, is that many OSes
are capable of binding to an IPv4 address using an AF_INET6 (IPv6)
socket. Linux can do that, and we use that the be able to listen to
both IPv4 and IPv6 addresses at the same time. OSes not capable of that
need an independent socket per protocol (which is the behaviour you seem
to expect).
So, while this log line is surprising, it is not necessarily wrong or a
bug by itself.
What is more interesting in your log extracts are these lines:
2021-02-28 08:00:26 ROUTE_GATEWAY 192.168.0.254/255.255.255.0 I=11
HWADDR=dc:f4:01:e4:f4:10
[....]
2021-02-28 08:00:26 Notified TAP-Windows driver to set a DHCP IP/netmask
of 10.8.0.1/255.255.255.252 on interface
{27C77640-C538-4BDA-A9ED-B7A480CAF22D} [DHCP-serv: 10.8.0.2, lease-time:
31536000]
[...]
2021-02-28 08:00:36 Warning: route gateway is not reachable on any
active network adapters: 10.8.0.2
I am no Windows person, so I do not fully grasp the finer details here.
But it seems like the the TAP-windows6 interface did not manage to get
properly configured. Since it uses the DHCP protocol in this case to
configure the IP address, that seems not to have been picked up in time.
Perhaps it just was a bit slow to react, so you need to use the
--route-delay option?
The last log line above just says that "OpenVPN was not able to find any
device configured with 10.8.0.2". The two last log lines you refer to:
2021-02-28 08:06:47 C:\Windows\system32\route.exe DELETE 10.8.0.0 MASK
255.255.255.0 10.8.0.2
2021-02-28 08:06:47 ROUTE: route deletion failed using
DeleteIpForwardEntry: Impossibile trovare elemento
They are also a natural result of the prior errors. The TAP-Windows6
based interface was not configured properly, thus it failed to remove a
route which does not exist.
So, the conclusion is that this isn't an OpenVPN bug by itself as it
stands now.
Error messages should ideally be easier to grasp and relate to each
other, but there is a mixture of error messages reported by the OS
(Windows) directly and some which comes from OpenVPN. We don't want to
add code parsing error codes in details to make the log file look
completely coherent - as that would require quite some code which would
need to far better understand in which situation an error was happening
and interpret and "translate" fairly general OS errors into OpenVPN
specific situation specific errors. While the end-user friendliness
could be improved, the code complexity adding this kind of logic (which
would also have potential for misinterpretations and even more confusing
misrepresentations), it is far better to leave these errors untouched as
far as possible and just pass them on. These errors are also different
on different platforms, so understanding the platform you're debugging
on is required anyhow.
What will be more important for you to figure out is *why* the
TAP-Windows6 driver didn't pick up the DHCP message and configure the
interface? Was it just due to responding late? Or was it due to some
firewall rules blocking DHCP announcements happening on the TAP-Windows6
interface? Was something running with incorrect privileges?
Once that has been figured out, we can more easily see and understand if
something in the OpenVPN code paths was misbehaving. But from what we
see from these log lines so far, everything is as expected.
--
kind regards,
David Sommerseth
OpenVPN Inc
_______________________________________________
Openvpn-users mailing list
Openvpn-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-users
