I fixed all of my issues like this by using load -w and unload -w`
Post
Replies
Boosts
Views
Activity
From what we can tell this started happening in 13.4.1(c) on intel only.
Screenshots attached
iCloud login inside of Anka VMs work great if they are Silicon/arm. On Intel, we see
This is on 15.1 host and 15.1 VM.
I can reproduce it by:
Block all internet traffic to my MBP but allow all LAN
Set up squid proxy on another machine on the LAN
Set my http/s_proxy envs in the shell, set System Preferences > Network > ETH Proxy settings to the proper IP and port of the squid proxy.
This allows me to tunnel through the squid proxy and reproduce the issue easily without a corporate proxy setup.
Lots of different requests to apple urls from the squid proxy logs and I'm not sure if they're even related or not...
1730834097.486 610093 192.168.1.79 TCP_TUNNEL/200 4681 CONNECT o22381.ingest.sentry.io:443 - HIER_DIRECT/34.120.195.249 -
1730834054.010 120115 192.168.1.79 TCP_TUNNEL/200 8605 CONNECT swdist.apple.com:443 - HIER_DIRECT/23.213.44.215 -
1730834272.626 1387 192.168.1.79 TCP_TUNNEL_ABORTED/200 14481 CONNECT weatherkit.apple.com:443 - HIER_DIRECT/23.47.52.133 -
1730834267.351 67 192.168.1.79 TCP_TUNNEL/200 22175 CONNECT init-p01md.apple.com:443 - HIER_DIRECT/23.220.102.59 -
1730834267.381 97 192.168.1.79 TCP_TUNNEL/200 16394 CONNECT init.ess.apple.com:443 - HIER_DIRECT/17.253.7.133 -
1730834309.963 42 192.168.1.79 TCP_MISS/200 256 GET http://netcts.cdn-apple.com/ - HIER_DIRECT/23.38.189.98 text/html
1730834310.772 17 192.168.1.79 TCP_MISS/200 256 GET http://netcts.cdn-apple.com/ - HIER_DIRECT/23.38.189.98 text/html
1730834344.022 117504 192.168.1.79 TCP_TUNNEL/200 49043 CONNECT developer.apple.com:443 - HIER_DIRECT/17.253.23.201 -
1730834346.178 443467 192.168.1.79 TCP_TUNNEL/200 4645 CONNECT github-partners.slack.com:443 - HIER_DIRECT/3.134.44.134 -
OK, after 15 minutes it finally allows me to go to the siri screen. Here are the logs from that time:
Very odd...
Another quick note: It looks as if the length it takes to eventually timeout/proceed differs between networks. In a corporate network behind a different proxy, it cannot be worked around by waiting for 15/19minutes like I can locally. Sometimes it's double that.