Authentication error

IIRC, ::1 is the IPV6 loopback address (127.0.0.1 is for IPV4).

[jay (support)]

I suspect it's the broadcast line - you don't need that line to do broadcasts and I suspect a recent macOS revision caused those lines to be a problem. But that's just a guess.

It is, however, in my /etc/hosts file but I'm not running Ventura so I don't know if that's the issue or not.

Isn't the broadcast host entry just part of traditionally defined IP protocol that addresses all local network physical addresses while remaining non-routable (to isolate local broadcast traffic patterns from the router routing tables)? This goes well beyond apple / OS X.

https://en.m.wikipedia.org/wiki/Broadca ... networking

" A special definition exists for the IP address 255.255.255.255. It is the broadcast address of the zero network or 0.0.0.0, which in Internet Protocol standards stands for this network, i.e. the local network. Transmission to this address is limited by definition, in that it is never forwarded by the routers connecting the local network to other networks."

Not disputing your suspicion on possible impacts to this issue, but at face value this is a pretty standard host entry and has a specific function as defined in the IP Protocol Specification Standards.

[jay (support)]

My point is that it doesn't need to be in the hosts file since it is just used for name lookups. In general, when you create a broadcast connection, you specify the appropriate address (such as 192.168.255.255 or 255.255.255.255, etc.) rather than a host name that has to be looked up. As I said, that might not be the issue, but a bug in how macOS deals with multiple localhost entries could conceivably be the issue.

I do notice that with your hosts file you have an entry that might be responsible:

Code: Select all

fe80::1%lo0   localhost

If things seem to be working with everything else commented out, you might want to leave that one out but uncomment the rest to see if your problem comes back or not.

[jay (support)]

Here's another thought for you:

[code]
27.0.0.1 kubernetes.docker.internal

I'm fairly certain that should be 127.0.0.1. I don't know if that would be causing the issue or not.

For what it is worth, in my case the host file was provided for comparison to the others. I never commented any of these out so all of the definitions have remained active and in use throughout the events (both during the failures from last week and the current operating state).

I also reverted my DNS back to "PiHole only" and have not seen the issue recur (in the last couple of days now).

Am beginning to think that the DNS and Host config stuff is not related at all.

If this was an OS host config or DNS related issue related to these configurations, (nothing has changed on my end between the failures and the working configs), I would expect to see a failure recur but have not.

Perhaps this is simply a coincidence of timing , in which case, I have now jinxed things by my statements above and will expect another failure at any moment now ...

At any rate, I will chime in if the issue resurfaces again, but for now, all is stable for several days now with no changes on my end to account for the blip in licensing services last week.

[jay (support)]

This is the common root of the issue:

Code: Select all

File "/Library/Frameworks/Python.framework/Versions/3.10/lib/python3.10/socket.py", line 955, in getaddrinfo
for res in _socket.getaddrinfo(host, port, family, type, proto, flags):
socket.gaierror: [Errno 8] nodename nor servname provided, or not known


The python socket library attempts to get the information for a host and it's failing. It could be a problem with the /etc/hosts file, could be some transient issue with the network stack on your Mac, some unexpected DNS failure, etc. The only concrete thing that's fixed it for a couple of other users was to make sure that the /etc/hosts file correctly identifies localhost. Anything else is speculation given the very small pool of reported issues.

In the next Indigo release, we've beefed up the exception handling to catch this error and report something a little clearer (and remove the redundant exceptions that follow) but there is honestly nothing more we can do. It's a low-level network failure of some kind that we can't work around (if we or any other library/caller can't resolve a hostname into an IP address there's nothing else to do but log the problem and attempt to continue to function as best we can).

Yes ... Understand what you are describing in the python code error being triggered without a specific pointer to the absolute error on why it cannot retrieve the proper host information. Sounds like your vision for more robust error coding in the future will yield the needed insights in the future releases.

The part I still question is whether or not those particular host file definitions would create any issues. Although they could be debated as superfluous in intent, they also appear to be quite common in the wild and are valid host file definitions. Agree that one can eliminate them here to rule out confusion factor, but in my case the error or issues came and went without changing these in any way. When the issue was occurring, it persisted across reboots of the host and the network which tends to rule out transient machine state conditions of localized host IP stack, network routing tables, etc.

Just out of curiosity, it seems that these kind of python related errors (where python gets confused between local host names and defined loopback / host IP addresses assigned to them) are pretty common and in some cases there are described work arounds within the python coding itself by simply hardcoding a static loopback address (127.0.0.1) directly in the python code.

Here is one example describing something similar along these lines.

https://www.delftstack.com/howto/python ... not-known/

Is this thread describing something similar to what you referenced in the python error above? Any chance that something like this technique could be applied in the python in our error condition to circumvent the issue?

Thanks again for the insights and focus in this area.