Hi Chris,
With MWServer listening address set to ‘localhost’ and MWClient connecting to ‘localhost’, Client fails to connect.
Changing both addresses to 127.0.0.1 works.
Chris, for supporting this across rig machines, we’d prefer to either use localhost or tell everyone to use 127.0.0.1.
I suspect this is a ipv4 / ipv6 issue. any advice?
best!
Mark
Mac OS Ventura 13.6 (22G120)
MWorks 2023.03.01
Hi Mark,
There’s a known issue, observed by me and at least one other user, where the client occasionally fails to connect. In my experience, this always seems to happen immediately after a macOS restart, but I’m not certain that’s a required precondition. I’ve found that the only solution is to restart the Mac again, after which the client connects normally.
This has been a difficult issue to investigate, because it doesn’t happen very often. I think you may be right that it’s related to IPv6 somehow, but I don’t know if the issue lies in the OS, ZeroMQ, or somewhere else. I don’t think I’ve tried switching from “localhost” to “127.0.0.1” as a workaround, but I will the next time it happens to me.
For now, can you see if restarting your Mac resolves the problem? If it does, then I suspect you’re experiencing the same issue.
Thanks,
Chris
Hi Chris,
Thank you, this helps. I can continue to note when this happens. I have not restarted my Mac since the issue arose, but now I am connecting to localhost just fine. Yesterday I was connecting to 127.0.0.1.
Nina
Hi Nina,
I have not restarted my Mac since the issue arose, but now I am connecting to localhost just fine. Yesterday I was connecting to 127.0.0.1.
That’s interesting. So maybe the issue, whatever it is, can resolve itself given some time? I haven’t ever waited to find out, but I will try to (by using 127.0.0.1 as a workaround) next time it crops up for me.
Thanks,
Chris
It could be related to our VPN software disconnecting and connecting, which appears to rewrite hostnames and local hostname lookups (like /etc/hosts though I’m not sure it uses that mechanism.)
It’s the Cisco AnyConnect VPN.
I guess we can just advise everyone in the lab to use 127.0.0.1 and unless Mac OS X phases out ipv4 localhost lookups, it should work, yes?
Mark
Hi Mark,
It could be related to our VPN software disconnecting and connecting, which appears to rewrite hostnames and local hostname lookups
It does seem like that could cause issues. That said, the connection failures I’ve seen have happened without any VPN software running.
I guess we can just advise everyone in the lab to use 127.0.0.1 and unless Mac OS X phases out ipv4 localhost lookups, it should work, yes?
Yes, 127.0.0.1 should work. If the issue is with resolving the name “localhost”, it’s possible that ::1 (the IPv6 equivalent of 127.0.0.1) would work, too.
Cheers,
Chris
Is there any advantage to connecting via ipv4 or ipv6?
For future proofing?
Is there any advantage to connecting via ipv4 or ipv6?
Well, ::1 is fewer characters 
. Apart from that, probably not, especially since you’re just connecting to the loopback interface. Specifying “localhost” is nice, because the system can figure out whether it should resolve to an IPv4 or IPv6 address. But if that’s going to fail, then 127.0.0.1 or ::1 should be equally good.
Chris
