i know macports is a volunteer effort, but i find it strange not to release a minor patch version with a temporary fix while the dust settles around the other software involved: macos, little snitch, etc. Yes, it's not directly macports' fault per se, but it triggers it, and it makes running macports akin to playing russian roulette. although it causes no kernel panic at the moment ("only" full networking loss until reboot), the going advice is "use master" and/or with some undocumented option overrides. it has been widely reported by many people. My grand total time invested in this issue is in days already. Nevertheless, if you encounter the problem, it's worth reporting it, removing any network filter interfaces, and/or trying the max ping workaround.įundamentally, useful sysdiagnose dumps and feedback reports are going to be the way to get this to the right people at Apple. My guess is that network filters exacerbate some kind of race condition or deadlock in the network stack, but the problem probably isn't directly related. If you mention this thread and the feedback ID I used, it might help this get elevated up the chain at Apple so that someone can solve it. If you encounter the problem, it's worth running sudo sysdiagnose as the problem happens, then attach the CLI generated tar.gz that starts with sysdiagnose to a feedback report using applefeedback://. I sent Apple Feedback a ticket with ID FB9031599. While I couldn't get around the problem by disabling the network filter from the Little Snitch menu, completely removing the network filter interface in the Network prefpane worked. The interesting attributes I have are that I'm on an M1 system, so I figured it was a Rosetta issue or Apple Silicon issue. ![]() I'm on macOS 11.2.2 with Little Snitch 5.1.1. I had the same problem, found after googling in resignation and landing at #62360.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |