IPV6-Bug

[nlog]

IPV6-Bug

[304NotModified]

proposed fix from link:

Add

public bool IsIPv6Supported { get { return false; } }

replace host.AddressList[0] with

foreach (IPAddress address in host.AddressList)
{
    if ((address.AddressFamily ==
        System.Net.Sockets.AddressFamily.InterNetworkV6) &&
        !IsIPv6Supported) 
        continue;

    return address;
}

current code NetworkSender.cs

        /// <summary>
        /// Parses the URI into an endpoint address.
        /// </summary>
        /// <param name="uri">The URI to parse.</param>
        /// <param name="addressFamily">The address family.</param>
        /// <returns>Parsed endpoint.</returns>
        protected virtual EndPoint ParseEndpointAddress(Uri uri, AddressFamily addressFamily)
        {
#if SILVERLIGHT
            return new DnsEndPoint(uri.Host, uri.Port, addressFamily);
#else
            switch (uri.HostNameType)
            {
                case UriHostNameType.IPv4:
                case UriHostNameType.IPv6:
                    return new IPEndPoint(IPAddress.Parse(uri.Host), uri.Port);

                default:
                    {
                        var addresses = Dns.GetHostEntry(uri.Host).AddressList;
                        foreach (var addr in addresses)
                        {
                            if (addr.AddressFamily == addressFamily || addressFamily == AddressFamily.Unspecified)
                            {
                                return new IPEndPoint(addr, uri.Port);
                            }
                        }

                        throw new IOException("Cannot resolve '" + uri.Host + "' to an address in '" + addressFamily + "'");
                    }
            }
#endif
        }

Not sure if we should use AddressFamily instead of IsIPv6Supported

[304NotModified]

@mikhail-barg can you help us in closing this one?

[mikhail-barg]

I don't think I have any IPv6 setups within reach, but I'll check tomorrow.

Also I'm not sure what exact configuration is causing the problem. I'm not convenient with IPv6 addressing, but I assume ::1 is a localhost, so both sender and receiver should be on a same machine, or I'm missing something in the original post?

[304NotModified]

@mikhail-barg Is this something you could test? Testing with ::1 seems OK to me.

[mikhail-barg]

I will see if I could check this. I don't have any IPv6 setup at my work, and at home I don't have any network message receivers, so I'll have to write something myself.

[304NotModified]

@mikhail-barg any change to test this?

Everyone has ::1 (localhost) on his machine?

[mikhail-barg]

Sorry, I'm overloaded with work and literally have no free time currently. I'll do what I can when I have some time, but not sure if I could make it in time to get into 4.3

[mikhail-barg]

I finally found time to check the issue. The original post does not contain too much info on reproducing the problem (here are working links to original post:
http://nlog-forum.1685105.n2.nabble.com/IPV6-Bug-tt1685313.html#none
https://sourceforge.net/p/nlog/mailman/message/1603760/ )

I assumed that the Network target was used with TCP protocol. And also I decided to not try installing Chainsaw or nlog-viewer, but to write some simple TCP-listener.

Here are the results:

when listening to 127.0.0.1:

• logging to tcp://127.0.0.1 -> OK;
• logging to tcp4://localhost -> OK;
• logging to tcp://localhost -> fails with System.IO.IOException: Error: ConnectionRefused;

when listening to ::1:

• logging to tcp://[::1] -> OK;
• logging to tcp6://localhost -> OK;
• logging to tcp://localhost -> OK;

So the issue happens when listener listens to IPv4, and logger logs to localhost without explicitly specifying protocol version and system decides to use IPv6 address for it. I'm not sure if this is an original problem though.

I'm also not sure that this problem is related to NLog. If I issue ping localhost on my machine I get
it resolved to [::1] as well. Specifying explicit usage of tcp4 solves the problem.

As far as I understand the proposed solution, it just forces using IPv4 in case the protocol is not specified explicitly, so it would just result in a symmetrical problem (logging to localhost while listening to [::1] would fail). Considering that IPv6 is "the future", I don't think it's a good idea.

For now I'm attaching the code I've used to test things.
NLogIssue39.zip

[304NotModified]

Thanks, will close this as we don't have anything to do here.