I recall there are some Kerberos related errors on the system also which might need looking into.
Got a tip for us?
Let us know
Become a MacRumors Supporter for $50/year with no ads, ability to filter front page stories, and private forums.
Snow Leopard on Unsupported PowerPC Macs
- Thread starter Larsvonhier
- WikiPost WikiPost
- Start date
- Sort by reaction score
- Status
Were any DNS related libraries changed or just the binaries?
Apple’s Open Source DNS Service Discovery Collection
This is Apple’s Open Source DNS Service Discovery Collection. The collection consists of a set of daemons, tools and libraries which can be used either together or separately when deploying and using DNS Service Discovery. The collection consists of the following subsystems:- Daemons
- mDNS Responder Daemon
- DNSSD Discovery Proxy
- DNSSD Service Registration Protocol Advertising Proxy
- DNSSD Service Registration Protocol Client
- DNSSD Service Registration Protocol Update Proxy
- Systems:
- OpenThread Stub Network Border Router
- Tools:
- DNSSD Command-line tool
- Libraries:
- DNSSD Client Library For more information on the various parts of the collection, see the descriptions below.
mDNS Responder Daemon
The mDNS Responder Daemon (mDNSResponder) serves both as a DNS Stub Resolver, as a resolver for information published using multicast DNS (mDNS), and as a publisher of mDNS information. mDNSResponder monitors multicast traffic on port 5353, the mDNS port, to keep track of services advertised on the local network. mDNSResponder performs DNS resolution for non-local queries, and resolves queries in the special “.local” domain using mDNS. mDNSResponder is used on macOS as the system resolver as well as providing Bonjour service advertising and discovery, and can provide the same services on other platforms, such as Linux and BSD.[Click here to learn how to set up and use mDNSResponder.][1]
OpenThread Stub Network Border Router
The OpenThread Stub Network Border Router can be used to provide stub router service for Thread (802.15.4 mesh) networks using OpenThread. A stub router is a router that serves one or more isolated (stub) networks, and can connect automatically to an infrastructure network, such as a home Wi-Fi network. The purpose of a stub router is to allow:- devices on the stub network to discover and be discovered by devices on the infrastructure network
- devices on the stub network to be reached by devices on the infrastructure network
- devices on the infrastructure network to reach devices on the stub network What makes a stub router different than other routers is that the stub router only provides a way to reach one or more isolated networks. It will never provide a default route (for example to the Internet). It is not possible to reach a network other than the directly-connected stub network through a stub router. Stub routers need not participate in a routing protocol on the infrastructure network, and therefore do not require operator intervention in order to function.
DNSSD Discovery Proxy
The DNSSD Discovery Proxy implements the IETF DNSSD Discovery Proxy ([RFC8766][3]) and DNS Push ([RFC 8765][4]). Together, these provide authoritative DNS service, for the purpose of DNS Service Discovery, using mDNS instead of a stateful DNS database. This allows the network infrastructure to provide DNS service discovery automatically over DNS, which eliminates the common problem on multi-link networks where services can only be discovered by a host when it happens to be connected to the correct link.[Click here to learn how to set up and use a DNSSD Discovery Proxy][5]
DNSSD Service Registration Protocol Advertising Proxy
The DNSSD Service Registration Protocol Advertising Proxy implements acts as a [DNSSD Service Registration Protocol][6] server: it accepts service registrations from SRP clients. Service registrations are then advertised on one or more infrastructure links using multicast DNS.[Click here to learn how to set up and use a DNSSD Service Registration Protocol Advertising Proxy][7]
DNSSD Service Registration Protocol Client
The DNSSD Service Registration Protocol Client implements the client side of the [DNSSD Service Registration Protocol][8]. The core client implementation is implemented in such a way that it can be readily embedded using a small API that must be implemented in the embedded environment. Two example APIs are provided, one for Thread, and another for Posix. The Posix implementation builds a command-line client that can either be used as a daemon to register a service, or used to validate various aspects of Service Registration Protocol implementations.[Click here for more information about the DNSSD Service Registration Protocol Client][9]
DNSSD Service Registration Protocol Update Proxy
The DNSSD Service Registration Protocol Update Proxy acts as a [DNSSD Service Registration Protocol][10] server: it accepts service registrations from SRP clients. The SRP registration is then used to generate a series of DNS Updates ([RFC2136][11]). These updates can be authenticated using TSIG. The SRP server responds to the client after all of the DNS Updates have completed, or responds when one part of the DNS update fails. The effect of running the SRP Protocol Update Proxy is as if the DNS server being updated were itself an SRP server.[Click here to learn how to set up and use a DNSSD Service Registration Protocol Update Proxy][12]
DNSSD command-line tool
The DNSSD command line tool (dns-sd) provides a way to exercise the services provided by mDNSResponder. Services can be advertised, browsed, and resolved. The tool provides a wide variety of different command-line options and is a great way to explore the functionality of DNS-SD.[Click here to learn about the DNSSD command-line tool][13]
DNSSD Client Library
The DNSSD Client Library provides, when used with the mDNS Responder daemon, a fully-featured DNS stub name resolution service, DNSSD advertising service, and DNSSD browsing and resolution service. The library is asynchronous, and can be easily integrated into an existing asynchronous server flow.FWIW, Kerberos framework changes significantly between 10a190 and 10.6.8. No idea if those changes are relevant to the issue, but for example OpenJDK does not build against 10a190 (or possibly 10a222?) Kerberos framework headers, failing on a missing <kim.h> (and it is not just an extra header added in by mistake, the whole structure of framework headers differs). To build OpenJDK I had to swap headers inside the framework (likely there is a neater fix, but apparently not an easy one).
Could someone with 10a190 say if there is a reference to <Kerberos/kim.h> in /System/Library/Frameworks/Kerberos.framework/Headers/KerberosLogin.h or not? Not in the /Developer folder, but in the system.
BTW, there was an opinion expressed earlier than the issue in 10.6.8 may be caused by broken UDP.
And related comment:
> If UDP is completley broken, when you won't have NTP and other way to sync
time. You may enter NTP server IP and check that system sync time. If it
does, well, some UDP is working.
> DNS migth be resolved via TCP or HTTPS, but the last needs quite new browser
(hello, rust!), or local DNS resolver (knot, unbound, powerdns-resolver,
bind, you name it).
> If local DNS resolver works (directly or as proxy to 1.1.1.1), the next
question is: can it be used on system level.
> If you luck enough, editing /etc/resolve.conf and enforcing 127.0.0.1 should
be enough to bring internet back.
> If UDP is completley broken, and here no way to switch system to TCP, well,
the only option is resolve somewhere else all domains and put it into /etc/hosts.
Tried some other stuff like /usr/bin/dns-sd, /usr/sbin/dnsextd, /usr/sbin/dnssec-keygen and /usr/sbin/dnssec-signzone but still nothing. I couldn't find anything else that seems related to DNS.
In the XNU source I see some TCP/UDP stuff in the bsd/netinet folder so maybe it could be the kernel?
Thank you for the pointers @educovas and @ChrisCharman -- excellent data there for more study.
Thanks for checking on the DNS related service and binary swaps, @educovas!
@barracuda156 I checked earlier on usage for resolv.conf but it seems to be deprecated nearly to the point of irrelevance in 10.6.8 -- a big departure from or Unix type systems I use regularly.
I did test out UDP using the following command and it seems functional:
This doesn't seem terribly useful because I've been unable to see a blocked message. I can get the command to show one for TCP (just change the last letter in the switch string from "u" to "t") easily but the without a negative test I can't tell if UDP is fine or just always reports it is fine.
The behavior seems the same on the MacBook Pro I'm comparing to which is also running 10.6.8, unfortunately.
What is a bit different is that the MacBook Pro shows a couple of vnic devices (0 and 1) in the output of ifconfig whereas my PowerBook does not. This might simply be a side effect of manually configuring the interface but I thought I'd mention it. (I have not done anything special to the MacBook Pro configuration but it is an older computer my wife used to use before the keyboard and trackpad failed -- I haven't cleaned off the drive yet but I did repair it last week.)
Thanks for checking on the DNS related service and binary swaps, @educovas!
@barracuda156 I checked earlier on usage for resolv.conf but it seems to be deprecated nearly to the point of irrelevance in 10.6.8 -- a big departure from or Unix type systems I use regularly.
I did test out UDP using the following command and it seems functional:
This doesn't seem terribly useful because I've been unable to see a blocked message. I can get the command to show one for TCP (just change the last letter in the switch string from "u" to "t") easily but the without a negative test I can't tell if UDP is fine or just always reports it is fine.
The behavior seems the same on the MacBook Pro I'm comparing to which is also running 10.6.8, unfortunately.
What is a bit different is that the MacBook Pro shows a couple of vnic devices (0 and 1) in the output of ifconfig whereas my PowerBook does not. This might simply be a side effect of manually configuring the interface but I thought I'd mention it. (I have not done anything special to the MacBook Pro configuration but it is an older computer my wife used to use before the keyboard and trackpad failed -- I haven't cleaned off the drive yet but I did repair it last week.)
I've tried to see which build between 10A222 and GM was the first to show the network problems but unfortunately I couldn't get 10A261 and 10A286 to boot because none of the available DirectoryService binaries work (10A222 and GM). The best I got was build 10A314 with the kernel from 10A354 (10.0.0d8). 10.0.0.d4 to 10.0.0d6 won't boot on PowerPC, even after patching.
Unfortunately this didn't help, the problem also happens with this combination.
Unfortunately this didn't help, the problem also happens with this combination.
Snow Leopard on PPC is a great idea, one Apple should have embraced and released, but they did not. We are left attempting to use early binaries that by their very "youth" are unstable.
I tried Snow Leopard PPC. I gave up after running into too many problems. Sorbet Leopard is a much more stable product. It was based on a released version of Mac OS X... the stability has been baked in by Apple.
I know that this thread is dedicated to Snow Leopard PPC but I honestly believe that embracing Sorbet Leopard will be ultimately much more productive for most people. I have run into one, and only one, technical issue with Sorbet - my iSight camera doesn't work. USB webcams do, so there is a clean workaround.
My recommendation: go Sorbet!
I tried Snow Leopard PPC. I gave up after running into too many problems. Sorbet Leopard is a much more stable product. It was based on a released version of Mac OS X... the stability has been baked in by Apple.
I know that this thread is dedicated to Snow Leopard PPC but I honestly believe that embracing Sorbet Leopard will be ultimately much more productive for most people. I have run into one, and only one, technical issue with Sorbet - my iSight camera doesn't work. USB webcams do, so there is a clean workaround.
My recommendation: go Sorbet!
Sorbet Leopard is a completely different project, it's a tweaked 10.5.8. Here we're currently with an actual Snow Leopard 10.6.8 with the powerpc binaries left for Rosetta and binaries from the 10A190 beta. Obviously it'll never be as stable as a proper PowerPC release like 10.5.8 but should allow building software that's slightly more modern.
Thank you for continuing to look for a working configuration, @educovas!
I've been working my way through some possibilities at the command line level and found at least one thing that prevents proper functionality after comparing to the working Intel 10.6.8 install on my MacBook Pro.
/var/run/mDNSResponder is a broken symlink to /var/run/mdns/mDNSResponder
This should not be a symlink at all. It should be a Unix socket used for communication with the service.
I renamed it (though you can safely delete it) and bounced mDNSResponder to let launchd create the socket with the following commands:
This won't fix DNS resolution but should make Bonjour stuff at least accessible via the socket that is supposed to be there.
Back to digging...
I've been working my way through some possibilities at the command line level and found at least one thing that prevents proper functionality after comparing to the working Intel 10.6.8 install on my MacBook Pro.
/var/run/mDNSResponder is a broken symlink to /var/run/mdns/mDNSResponder
This should not be a symlink at all. It should be a Unix socket used for communication with the service.
I renamed it (though you can safely delete it) and bounced mDNSResponder to let launchd create the socket with the following commands:
This won't fix DNS resolution but should make Bonjour stuff at least accessible via the socket that is supposed to be there.
Back to digging...
@educovas I managed to find a spare hour the other day to compile some of the binaries from the AOSP mDNSResponder project 10.6.8 tree then replaced the binaries on the system. Didn’t break the build so they work as expected, but also didn’t fix the problem. I haven’t yet replaced the main mDNDResponder binary @FBSD_Mac as there are two dependencies that need to be built first (or at least project headers needed). One of those projects is libdispatch @barracuda156.
Last edited:
For libdispatch you could perhaps just build it via MacPorts (as I mentioned above, it does not introduce any dependencies or even use MacPorts tools). You can check what gets installed here: https://ports.macports.org/port/libdispatch-legacy/details
Since it is only headers and static libs, those can be moved wherever needed.
Alternatively, the same build can be done manually without MacPorts being installed. Perhaps portfile recipe is pretty transparent. Only Xcode Unix tools are used.
A note re patches:
1. I think pthread_threadid_np-expose-on-PowerPC.diff is unneeded until Libc gets rebuilt to make pthread_threadid_np available there. Just drop it from the portfile. It is not required to make the build work.
2. Other patches were added to address build issues on 10a190. They may or may not be needed on 10.6.8. (I.e. it works on 10.6.8 with all those patches, but some may not be required.)
Perfect thanks @barracuda156! Will try building manually so headers get put in the correct places etc when i get a chance.
Interesting how something got broken in intermediate builds but fixed (whether on purpose or by accident) in later ones.
As I recall, it took more time to write portfile logic than to make the build itself work. Should be unproblematic.
At least in the earlier image this symlink was also broken (may not apply to the current one):
Excellent. Lots of system components depend on libdispatch so fixing the system version would be extremely desirable
Probably needs libresolv to be rebuilt. I imagine (and have started) rebuilding and replacing all network related AOSP projects will be beneficial.
I'm sure the DirectoryService problem would be fixed if I could compile the correct version from AOSP like I did for GM. The kernel I bet was also affecting Rosetta and the problem was fixed intentionally.
ideally we need to build all AOSP projects to restore all binaries available that are currently from 10A190. I just never did that because I'm terrible at compiling software.
The file itself exits, but symlink was broken. (I cannot check the latest image now.)
Original file is in /private/var/run.
Yeah rebuilding the AOSP sources is basically what i’ve been doing for the last few years, albeit slowly and intermittently due to time constraints. I was also mainly focused on 10A190 so can now shift to 10.6.8 as there is a bootable image to work from. Initial testing has shown that cross-compiled binaries built on intel 10.6.8 work on the modified ppc version so that bodes well for speed of compilation. I still won’t have additional time but at least what i build can be shared with others running the same system down the line as opposed to a few of us running multiple different systems with varying degrees of hybrid slicing
Yes, cross compiling works perfectly, I've built everything I needed on my MacBookPro8,2 running 10.6.8. I should probably start building the AOSP projects since I have no idea of what else I could do to fix bugs.
I wasn't supposed to be working on this anymore but I guess I really want to see 10.6.8 running decently on PowerPC lol
@educovas @ChrisCharman What do you think about Xcode, in a sense what is the preferred way to have 3.2.6 fully usable on powerpc? This is not something urgently required, of course (since cross-compiling is a workable option), but it will be certainly useful, and given that nobody has infinite free time LOL – and there is a lot of stuff to do – makes sense to avoid or at least minimize duplicate work (here I mean “mechanical” work, not debugging).
A poor man’s fix would be to simply replace components of Unix tools and Xcode which lack ppc slices. That seems to work fine. Unfortunately, however, several important tools (ld, as) fall into this group, and these perhaps should be prioritized to be rebuilt from sources. (Thankfully, there is no need to rebuild gcc – it is perfectly functional as is, aside of the linker binary.)
A poor man’s fix would be to simply replace components of Unix tools and Xcode which lack ppc slices. That seems to work fine. Unfortunately, however, several important tools (ld, as) fall into this group, and these perhaps should be prioritized to be rebuilt from sources. (Thankfully, there is no need to rebuild gcc – it is perfectly functional as is, aside of the linker binary.)