Opened 4 years ago

Closed 4 years ago

#805 closed Bug / Defect (notabug)

Could not determine IPv4/IPv6 protocol. Using AF_INET

Reported by: Antonio Owned by:
Priority: minor Milestone:
Component: Networking Version: OpenVPN 2.4.0 (Community Ed)
Severity: Not set (select this one, unless your'e a OpenVPN developer) Keywords:
Cc: Arne, Schwabe, <arne@…>

Description

Every time I run OpenVPN server on linux I get the message "Could not determine IPv4/IPv6 protocol. Using AF_INET" in the log. The message was introduced by commit 45184804c477aed2ae91ce23d6606da1bfccbaa7 ("Fix for server selecting address family").

Bisecting this issue was not needed, because the message is printed since its introduction.

I couldn't find any runtime problem after reading this message. However, I am not sure what happens if I set the server to listen on IPv6.

Change History (3)

comment:1 Changed 4 years ago by Antonio

When listening on an IPv6 socket (by means of "proto udp6") no warning is printed and IPv6 clients can properly connect.

comment:2 Changed 4 years ago by Antonio

After digging deeper and deeper and after discussing with cron2 on IRC, the conclusion is that this message is printed when no IPv4/v6 preference is given in the config (i.e. proto udp/tcp is used) and OpenVPN is running as a server. In this case OpenVPN falls back on what the OS prefers (based on getaddrinfo() result) - in my case AF_INET - and the message is printed to show the decision.

When using udp4/udp6 (or tcp4/tcp6) no message is printed because the socket family to use has been provided by the user.

I think this ticket can be classified as noise and closed :)

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

Resolution: notabug
Status: newclosed

Oh, indeed. *Now* I understand that "error" message, finally :-) - I knew what was happening behind the scenes, but it did not "click" yet.

Now it did - it's informational, and we inform the user what the outcome of "ask getaddrinfo() what we'll get?" was.

But it's useful to have in here in case someone else is searching for it.

Note: See TracTickets for help on using tickets.