10.6 Snow Leopard PowerPC Development

[barracuda156]

those errors should be fixed if you copy them from 10.5.8 or 10A96 but if you don't care deleting is not a problem.

Not sure now if these or different, but I have certainly seen some cases when ppc versions never existed [publicly]: 10.5.8 do not have those components, and when they appear, they are x86-only. I think it was related to either fastfetch or albafetch fixing.

 

[jkchr1s]

Turns out I was wrong, scutil is getting the information you put in System Preferences and I was using scutil incorrectly.

If you launch scutil with no arguments, you get an interactive console. Run "list" to see the keys in SystemConfiguration. Then type "get <keyname>" to load the key, then "d.show" to show the configuration.

That was a rabbit hole for sure.

But now I know for sure that SystemConfiguration is configuring the interface properly, so at least I've confirmed that much.

 

[jkchr1s]

I'm starting to think this might be a problem with the firewall. Potentially alf (/usr/libexec/ApplicationFirewall/socketfilterfw)?

As someone else mentioned, it appears the udp traffic is being blocked entirely. I confirmed the same thing, and here's how you can reproduce it yourself:

To start listening on port 6111, run:

nc -ul 6111

You can then connect to this port via localhost:

nc -u 127.0.0.1 6111
Type something here and press enter. You will see the message in the first terminal.

But if you connect with the static IP you assign in system preferences, the message isn't delivered.

nc -u 192.168.1.200 6111
Type something here and press Enter. This message is not received.

If I do these steps on my MacBook Pro, it works on both localhost and IP address. You can even communicate to other machines -- but not the 10.6.8 machine. My MacBook Pro should be able to send and receive UDP to my G4 iMac, but udp traffic is simply not delievered.

I tried stopping both com.apple.alf.agent.plist and com.apple.alf.helper.plist, but neither of these made a difference. Is there another firewall somewhere else? Since TCP works and UDP doesn't, it makes sense that maybe it's a firewall issue. Copying /usr/libexec/ApplicationFirewall from 10.5.8 does not make a difference.

---

Edit: Found some info here: https://www.peachpit.com/articles/article.aspx?p=1573022&seqNum=2

Running this should disable the kernel-level ipfw (which is enabled by default on client and server, does not persist through a reboot):

sysctl -w net.inet.ip.fw.enable=0

However, still no udp traffic.

Also tried disabling alf:

defaults write /Library/Preferences/com.apple.alf globalstate -int 0

and rebooting, still no udp traffic.

 

[ChrisCharman]

In addition to Application Firewall there is also ipfw which may be causing issues. I’ve been suspecting security related components for a while so if the firewalls are not causing the problem then it could also be Kerberos/PAM/SSL or some other authorising agent blocking the connection? Great work so far investigating this @jkchr1s

 

[jkchr1s]

In addition to Application Firewall there is also ipfw which may be causing issues. I’ve been suspecting security related components for a while so if the firewalls are not causing the problem then it could also be Kerberos/PAM/SSL or some other authorising agent blocking the connection? Great work so far investigating this @jkchr1s

Yeah, there's definitely some Kerberos issues, but PAM seems to be working for me.

If I start up sshd, I cannot connect to it by IP with a static IP address from another host. However, you can ssh to user@127.0.0.1 or user@staticip from the local machine. It takes a while waiting for Kerberos to time out, but then PAM picks it up and I can authenticate just fine.

This really, really feels like a firewall issue. But even with ipfw disabled it's not allowing traffic from external hosts, or any udp traffic. Since ipfw is just an interface to managing the firewall in the kernel, I'm wondering if maybe something from one of the server beta builds was copied in with some more secure defaults than the typical client... but you would think that disabling ipfw with the command above would allow it to work. There's only one rule listed by default when you run "ipfw list", so idk.

 

[FBSD_Mac]

Great work so far investigating this @jkchr1s

Agreed!

What I found when playing with nc (which you can see in the other thread) is that UDP messages sent from this version of the software to another machine is received instantly (on the remote machine) but the reverse isn’t actually completely blocked. It does arrive but 61 to 62s late to the listener set up on the PPC machine.

SOMETHING is receiving but holding onto the traffic for a long time. I was able to verify by watching for DNS response traffic after running a query. Even though the tool used (and I tried more than one) times out I do see the expected responses from the resolver host show up in the listener session on the PPC side (using nc) after the long delay I mentioned above.

It appears to me that this is due to reverse lookup of ip addresses for any incoming traffic timing out. This does not get ameliorated by adding entries to the hosts file because it seems to be UDP based resolution which is hanging.

Even though DNS resolution over IP works perfectly (and rapidly!) there is no way to force all the software to use it. SSH completely ignored the flag in its config file when I tried to disable host resolution there, too.

I think there is some problem with ARP. I tried to set up some static addressing to get around the issue but either I don’t completely understand what is required for that (quite likely!) or the system is ignoring the configuration I set up.

Regardless, this seems to be a low level implementation issue of some sort.

 

[jkchr1s]

SOMETHING is receiving but holding onto the traffic for a long time. I was able to verify by watching for DNS response traffic after running a query. Even though the tool used (and I tried more than one) times out I do see the expected responses from the resolver host show up in the listener session on the PPC side (using nc) after the long delay I mentioned above.

It appears to me that this is due to reverse lookup of ip addresses for any incoming traffic timing out. This does not get ameliorated by adding entries to the hosts file because it seems to be UDP based resolution which is hanging.

Even though DNS resolution over IP works perfectly (and rapidly!) there is no way to force all the software to use it. SSH completely ignored the flag in its config file when I tried to disable host resolution there, too.

I think there is some problem with ARP. I tried to set up some static addressing to get around the issue but either I don’t completely understand what is required for that (quite likely!) or the system is ignoring the configuration I set up.

That's interesting.

I pulled up the kernel sources for arp table handling and have been trying to read comments and such to see if any other services might be involved.

xnu/bsd/netinet/in_arp.c at rel/xnu-1504 · apple-oss-distributions/xnu

Contribute to apple-oss-distributions/xnu development by creating an account on GitHub.

github.com

---

Edit: You can kinda get an idea of some of the sysctl values referenced various places by running:

sysctl -a

and also play around with changing some of those values using "sysctl -w name=value" if you suspect that something's hanging it up. If we find that changing something actually fixes things, you can write a LaunchDaemon to automatically set it at boot time.

 

[jkchr1s]

What I found when playing with nc (which you can see in the other thread) is that UDP messages sent from this version of the software to another machine is received instantly (on the remote machine) but the reverse isn’t actually completely blocked. It does arrive but 61 to 62s late to the listener set up on the PPC machine.

I found several pages I had missed with your troubleshooting.

I also played with changing a bunch of sysctl settings, but still no change. configd and SystemConfiguration are all loading what they seemingly should be, the firewall isn't dropping the traffic.

I think that leaves us with a bug in the xnu kernel that we're using -- it's handling tcp, udp, dhcp, ipv4, ipv6, ipfw. Have you had any luck building it, @FBSD_Mac ? I saw @educovas built it from source, but got kernel panics on boot.

If I'm understanding the prior threads correctly, the mach_kernel in the 10.6.8 image is from the GM release? By that, are we saying it came from an Intel Mac installation of 10.6.8, and mach_kernel is "universal"?

If so, I wonder about trying the Kernel Debug kit: https://developer.apple.com/download/all/?q=Kernel Debug Kit

Edit: Nope. The debug kernel they distribute is only for x86 and x86_64.

 

[educovas]

I found several pages I had missed with your troubleshooting.

I also played with changing a bunch of sysctl settings, but still no change. configd and SystemConfiguration are all loading what they seemingly should be, the firewall isn't dropping the traffic.

I think that leaves us with a bug in the xnu kernel that we're using -- it's handling tcp, udp, dhcp, ipv4, ipv6, ipfw. Have you had any luck building it, @FBSD_Mac ? I saw @educovas built it from source, but got kernel panics on boot.

If I'm understanding the prior threads correctly, the mach_kernel in the 10.6.8 image is from the GM release? By that, are we saying it came from an Intel Mac installation of 10.6.8, and mach_kernel is "universal"?

If so, I wonder about trying the Kernel Debug kit: https://developer.apple.com/download/all/?q=Kernel Debug Kit

Edit: Nope. The debug kernel they distribute is only for x86 and x86_64.

It's possible to build the 10.6.8 kernel from source using the same instructions I uploaded in the other thread. The negative side is that it's not as stable as the stock kernel provided by Apple.

The kernel used in the 10.6.8 image is the stock kernel but with soma binary patches to resolve a problem that was preventing it from loading kexts. Yes, it came from an Intel Mac installation of 10.6.8. Snow Leopard kept the ppc kernel and the whole core of the OS compiled for ppc because of Rosetta.

 

[jkchr1s]

I'm trying to build the kernel, but I've run in an issue.

I am loosely following this, using the same versions and tweaking the commands:

Compiling XNU kernel 2050

I'm a bit confused on the best way to compile the latest version of the XNU kernel. I've seen lots of instructions for older kernels that came with Mac OS X 10.4 but the newer sources lack a lot of...

stackoverflow.com

I've successfully compiled and installed bootstrap-cmds 72, cctools 806, cxxfilt-9, dtrace-90, kext_tools 180.2.1 on my Intel MacBook running 10.6.8 and added arch ppc to each compile.

However, when I go to compile xnu, I get an error right after dtrace.o. Here's a snippet:

CC dtrace.o
LDFILELIST bsd
make: *** [all] Error 2

This is my bash history for doing the compiles:

    1  cd /build/
    2  ls -l
    3  cd cctools-cctools-806
    4  ls -l
    5  sudo cp -a include/mach-o /usr/include/
    6  ls -l include/mach-o/
    7  cd ..
   14  cd cxxfilt-cxxfilt-9
   15  mkdir -p obj sym dst
   16  make install RC_ARCHS="ppc i386 x86_64" RC_CFLAGS="-arch ppc -arch i386 -arch x86_64 -pipe" RC_OS=macos RC_RELEASE=SnowLeopard SRCROOT=$PWD OBJROOT=$PWD/obj SYMROOT=$PWD/sym DSTROOT=$PWD/dst
   17  sudo ditto $PWD/dst/usr/local /usr/local
   19  cd ..
   20  cd dtrace-dtrace-90
   21  mkdir -p obj sym dst
   22  xcodebuild install -target ctfconvert -target ctfdump -target ctfmerge ARCHS="ppc i386 x86_64" SRCROOT=$PWD OBJROOT=$PWD/obj SYMROOT=$PWD/sym DSTROOT=$PWD/dst
   23  sudo ditto $PWD/dst/usr/local /usr/local
   25  cd ..
   26  cd kext_tools-kext_tools-180.2.1
   27  mkdir -p obj sym dst
   28  xcodebuild install -target kextsymboltool -target setsegname ARCHS="ppc i386 x86_64" SRCROOT=$PWD OBJROOT=$PWD/obj SYMROOT=$PWD/sym DSTROOT=$PWD/dst
   29  sudo ditto $PWD/dst/usr/local /usr/local
   31  cd ..
   32  cd bootstrap_cmds-bootstrap_cmds-72
   33  mkdir -p obj sym dst
   34  make install RC_ARCHS="ppc i386" RC_CFLAGS="-arch ppc -arch i386 -pipe" RC_OS=macos RC_RELEASE=SnowLeopard SRCROOT=$PWD OBJROOT=$PWD/obj SYMROOT=$PWD/sym DSTROOT=$PWD/dst
   35  sudo ditto $PWD/dst/usr/local /usr/local
   37  cd ..
   38  ls -l
   39  cd xnu-xnu-1504.15.3
   40  sed -i -e '1s/.*/#define CPUFAMILY_INTEL_SANDYBRIDGE 0x5490b78c \/*/' osfmk/mach/machine.h
   41  make ARCH_CONFIGS="PPC I386 X86_64" KERNEL_CONFIGS="RELEASE"

Does anyone have any hints as to why it bombs out at LDFILELIST bsd? Attached is the full log from the kernel build.

 

[educovas]

I'm trying to build the kernel, but I've run in an issue.

I am loosely following this, using the same versions and tweaking the commands:

Compiling XNU kernel 2050

I'm a bit confused on the best way to compile the latest version of the XNU kernel. I've seen lots of instructions for older kernels that came with Mac OS X 10.4 but the newer sources lack a lot of...

stackoverflow.com

I've successfully compiled and installed bootstrap-cmds 72, cctools 806, cxxfilt-9, dtrace-90, kext_tools 180.2.1 on my Intel MacBook running 10.6.8 and added arch ppc to each compile.

However, when I go to compile xnu, I get an error right after dtrace.o. Here's a snippet:

CC dtrace.o
LDFILELIST bsd
make: *** [all] Error 2

This is my bash history for doing the compiles:

    1  cd /build/
    2  ls -l
    3  cd cctools-cctools-806
    4  ls -l
    5  sudo cp -a include/mach-o /usr/include/
    6  ls -l include/mach-o/
    7  cd ..
   14  cd cxxfilt-cxxfilt-9
   15  mkdir -p obj sym dst
   16  make install RC_ARCHS="ppc i386 x86_64" RC_CFLAGS="-arch ppc -arch i386 -arch x86_64 -pipe" RC_OS=macos RC_RELEASE=SnowLeopard SRCROOT=$PWD OBJROOT=$PWD/obj SYMROOT=$PWD/sym DSTROOT=$PWD/dst
   17  sudo ditto $PWD/dst/usr/local /usr/local
   19  cd ..
   20  cd dtrace-dtrace-90
   21  mkdir -p obj sym dst
   22  xcodebuild install -target ctfconvert -target ctfdump -target ctfmerge ARCHS="ppc i386 x86_64" SRCROOT=$PWD OBJROOT=$PWD/obj SYMROOT=$PWD/sym DSTROOT=$PWD/dst
   23  sudo ditto $PWD/dst/usr/local /usr/local
   25  cd ..
   26  cd kext_tools-kext_tools-180.2.1
   27  mkdir -p obj sym dst
   28  xcodebuild install -target kextsymboltool -target setsegname ARCHS="ppc i386 x86_64" SRCROOT=$PWD OBJROOT=$PWD/obj SYMROOT=$PWD/sym DSTROOT=$PWD/dst
   29  sudo ditto $PWD/dst/usr/local /usr/local
   31  cd ..
   32  cd bootstrap_cmds-bootstrap_cmds-72
   33  mkdir -p obj sym dst
   34  make install RC_ARCHS="ppc i386" RC_CFLAGS="-arch ppc -arch i386 -pipe" RC_OS=macos RC_RELEASE=SnowLeopard SRCROOT=$PWD OBJROOT=$PWD/obj SYMROOT=$PWD/sym DSTROOT=$PWD/dst
   35  sudo ditto $PWD/dst/usr/local /usr/local
   37  cd ..
   38  ls -l
   39  cd xnu-xnu-1504.15.3
   40  sed -i -e '1s/.*/#define CPUFAMILY_INTEL_SANDYBRIDGE 0x5490b78c \/*/' osfmk/mach/machine.h
   41  make ARCH_CONFIGS="PPC I386 X86_64" KERNEL_CONFIGS="RELEASE"

Does anyone have any hints as to why it bombs out at LDFILELIST bsd? Attached is the full log from the kernel build.

10.6 XNU won't build for ppc without some changes. Follow my notes in this post and you should be able to get it to compile properly.

https://forums.macrumors.com/threads/snow-leopard-on-unsupported-powerpc-macs.2232031/post-33130810

 

[jkchr1s]

10.6 XNU won't build for ppc without some changes. Follow my notes in this post and you should be able to get it to compile properly.

https://forums.macrumors.com/threads/snow-leopard-on-unsupported-powerpc-macs.2232031/post-33130810

Thank you!!! I was able to get it compiled. There's no way I could have figured that out without your help!

Now that it builds, I can look in to my next suspicion... It looks like there were some networking changes between xnu 1504.9.37 and 1456.1.26. Interestingly, the difference is the introduction of packet priority (pkt_priority) and if_bridge (x86 only), which could potentially explain delayed udp traffic.

I'm currently in the process of trying revert xnu 1509's packet priority bits to xnu 1456 to give us a "hybrid" kernel (mostly based on 1509, but with low level networking stack from 1456). Looks like these changed:

bsd/kern/kpi_mbuf
bsd/kern/kpi_socket
bsd/kern/uipc_socket
bsd/kern/uipc_socket2
bsd/net/if_mib
bsd/net/if_var
bsd/netinet
bsd/netinet6
bsd/sys/mbuf
bsd/sys/socketvar

But this also gives me the thought - what if SystemConfiguration isn't setting the packet priority? It seems to have changed towards the end of snow leopard's life.

 

[Jazzzny]

Not even 10.6.0 has working DNS. The most ideal thing to do is to diff the 10.5.8 kernel with 10.6.0, although this is already a monumental task.

 

[jkchr1s]

While I was able to successfully compile, my kernel does not boot. I can't get it to start up in verbose, single user, or anything... it just sits idle on the gray Apple screen.

@educovas in your notes, the very last step says to "copy System.kext from GM and replace", but I'm not sure what exactly to replace. Are you talking about this section in config/Makefile?

xnu/config/Makefile at rel/xnu-1504 · apple-oss-distributions/xnu

Contribute to apple-oss-distributions/xnu development by creating an account on GitHub.

github.com

 

[barracuda156]

A friend of mine did some debugging for 10.6.8, here is the conclusion:

UDP packets/responses are not seen by the userland applications when communicating through external interface. Firewall is disabled. Ipfw has rule allow any to any. UDP communication over loop back works, but DNS responses are not being seen. However the responses arrive and we can see the packets with tcpdump. The packet structure is valid. Mac addresses in l2 header match the mac address of the interface and the checksum of the packets is correct.

For a temporary solution the idea is to do DNS via TCP instead.

 

[jkchr1s]

A friend of mine did some debugging for 10.6.8, here is the conclusion:

Nice work! That's confirming what @FBSD_Mac and I experienced as well. My suspicion is that this is related to something in the kernel as it seems to be at a lower layer in the OS.

Have you successfully built and booted the xnu 1504 kernel from source? I'd really like to log some output in there to confirm, but my compiled kernels won't seem to boot even after applying things from educoda's amazing notes (thank you again so much for your help!)

 

[Jazzzny]

You need to assemble System.kext using the files listed in that makefile and replace it in /S/L/E. Additionally, the AOSP kernel won't boot on Power Mac G5 systems because some of the G5-specific init code is missing.

 

[barracuda156]

I have internet working on 10.6.8 (UDP still broken as it was, and therefore no DHCP, but DNS is working over TCP, so browsing works, curl works etc.).

P. S. Pre-compiled utility: http://macos-powerpc.org/packages/utdns (you do not need MacPorts for this, it has 0 dependencies).
Or compile from source from: https://github.com/rahra/utdns

 

[Jazzzny]

delete

 

[barracuda156]

10.6 XNU won't build for ppc without some changes. Follow my notes in this post and you should be able to get it to compile properly.

https://forums.macrumors.com/threads/snow-leopard-on-unsupported-powerpc-macs.2232031/post-33130810

Looks like we have internet, so the only factor preventing me from switching to 10.6.8 is gone.

So now the important question: are there any reasons (well, besides a slight inconvenience of manual network config) to hold to 10a190 or we can just drop it for good?

While perhaps most of software will be compatible, regardless of being built on 10a190 or 10.6.8 (and of course I will not rebuild literally all 13k ports for the new SDK), some will not – at least if built optimally for 10.6.8.
You know the OS itself far better, so I need your opinion here. If we consider 10.6.8 kinda-production-ready, then I just build everything on 10.6.8 from today and, provided everything works as expected, start dropping 10a190 hacks from defaults (I will keep those in variants, so 10a190 is still supported if needed).

P. S. I understand that you may not personally be using my PowerPC Ports (and TBH I have no idea if anyone is LOL), but at least potentially this will impact some people.

 

[barracuda156]

delete

Did it work for you? See also a reply of the developer here.

@educovas @ChrisCharman @jkchr1s
On a general note: until either UPD is actually fixed in 10.6.8 or someone comes up with a solution not relying on any external components, what is a better way to have `utdns` provided to potential users of 10.6.8, which will be straightforward (i.e. with minimal manual tweaks – we do not benefit from limiting user-base, it is already tiny)?
There are a lot of software doing something to this end, i.e. DNS over TCP, but other stuff which I saw pulls in a lot of dependencies (like newer pythons and/or newer gcc), and that is undesirable in this case.
Also, while I added `utdns` to MacPorts, for the system usage it should not depend on MacPorts (or my PowerPC Ports, w/e).
P. S. I think it will be nice to have an “expected default” way of installing rather than leaving it to an end-user, since it is easier for debugging, be it needed.

 

[Jazzzny]

Did it work for you? See also a reply of the developer here.

Yes, it worked

 

[educovas]

Looks like we have internet, so the only factor preventing me from switching to 10.6.8 is gone.

So now the important question: are there any reasons (well, besides a slight inconvenience of manual network config) to hold to 10a190 or we can just drop it for good?

While perhaps most of software will be compatible, regardless of being built on 10a190 or 10.6.8 (and of course I will not rebuild literally all 13k ports for the new SDK), some will not – at least if built optimally for 10.6.8.
You know the OS itself far better, so I need your opinion here. If we consider 10.6.8 kinda-production-ready, then I just build everything on 10.6.8 from today and, provided everything works as expected, start dropping 10a190 hacks from defaults (I will keep those in variants, so 10a190 is still supported if needed).

P. S. I understand that you may not personally be using my PowerPC Ports (and TBH I have no idea if anyone is LOL), but at least potentially this will impact some people.

10.6.8 is usable but ofc course you might see problems that don't exist in 10A190 but this is my opinion. I don't know if anyone else used this OS enough to know if it's close to "kinda-production-ready" but we might see more people trying it for more than 5 minutes now that we have internet.

Did it work for you? See also a reply of the developer here.

@educovas @ChrisCharman @jkchr1s
On a general note: until either UPD is actually fixed in 10.6.8 or someone comes up with a solution not relying on any external components, what is a better way to have `utdns` provided to potential users of 10.6.8, which will be straightforward (i.e. with minimal manual tweaks – we do not benefit from limiting user-base, it is already tiny)?
There are a lot of software doing something to this end, i.e. DNS over TCP, but other stuff which I saw pulls in a lot of dependencies (like newer pythons and/or newer gcc), and that is undesirable in this case.
Also, while I added `utdns` to MacPorts, for the system usage it should not depend on MacPorts (or my PowerPC Ports, w/e).
P. S. I think it will be nice to have an “expected default” way of installing rather than leaving it to an end-user, since it is easier for debugging, be it needed.

it's probably a good idea to add a small guide for this on the first post as the current workaround for the lack of internet connection and maybe now that 10.6.8 might me more used, we could collect bugs and workarounds like disabling sleep to reduce kernel panics and include on the first post.

 

[barracuda156]

By the way, there are no sources for Xcode itself (not Unix tools), right? So the only way to get IDE working is to pull needed components from some earlier builds where those are still universal?

Standard 3.2.6 GUI is unusable, since some required plugins lack ppc slices.

If someone happened to already track some components (which Xcode had the latest universal ones), it would be helpful to know. Only relevant for the stuff which we cannot rebuild from source, of course.

 

[barracuda156]

A quick check confirmed that:

a) software built on 10a190 works on 10.6.8 (this is expected generally, but my concern was graphics-related ports);
b) jabber and youtube work fine with DNS-over-TCP via `utdns`.

(Horribly low quality of YT video has nothing to do with 10.6.8 or powerpc, it is a result of YT breaking its API for streaming. Hopefully this will be fixed for QMPlay2 in a while.)

P. S. It also revealed some relatively minor issues with my PowerPC Ports setup, which will be addressed shortly. (Everything works generally and does save a lot of time, but it is not as smooth as it can be.)