Sidebar Sidebar
Become a MacRumors Supporter for $50/year with no ads, ability to filter front page stories, and private forums.

Missing Binaries for Apple realtek8153patcher KEXT

P

percyc

macrumors newbie
Original poster
Aug 23, 2017
6
3
I am trying to get a USB-based Realtek 8153 ethernet interfacing working, which is embedded in a TB4 Dell WD22TB4 dock (tested working under Windows). It is attached to a MBPro M2 (13", 2022) running Sonoma 14.4.1.

To my knowledge, what needs to be enabled is the Apple USB Realtek8153 patcher kext. But on Sonoma, the binary file for this kext is missing. I've checked my Intel Sonoma 14.4.1 system from my work, and the binary is missing from it, too.

MBPro:
Code: 
% > ls  /System/Library/Extensions/AppleUSBRealtek8153Patcher.kext/Contents
Info.plist      _CodeSignature/ version.plist


The binary does exist on my Intel MacPro running Big Sur (11.7.10) and it is a "fat" binary supporting ARM:
Code: 
% > ls /System/Library/Extensions/AppleUSBRealtek8153Patcher.kext/Contents/MacOS
AppleUSBRealtek8153Patcher*
% > file /System/Library/Extensions/AppleUSBRealtek8153Patcher.kext/Contents/MacOS/AppleUSBRealtek8153Patcher
/System/Library/Extensions/AppleUSBRealtek8153Patcher.kext/Contents/MacOS/AppleUSBRealtek8153Patcher: Mach-O universal binary with 2 architectures: [x86_64:Mach-O 64-bit kext bundle x86_64] [arm64e:Mach-O 64-bit kext bundle arm64e]
/System/Library/Extensions/AppleUSBRealtek8153Patcher.kext/Contents/MacOS/AppleUSBRealtek8153Patcher (for architecture x86_64):    Mach-O 64-bit kext bundle x86_64
/System/Library/Extensions/AppleUSBRealtek8153Patcher.kext/Contents/MacOS/AppleUSBRealtek8153Patcher (for architecture arm64e):    Mach-O 64-bit kext bundle arm64e

I'd like to get this binary over to the M2 machine, as it may solve the problem.

Unfortunately, it's been a long while since I've had to manually manipulate kexts (my last hack a core 2 quad). My Intel MacPro is a 2009 flashed to 2012--I used OpenCore Legacy to get Big Sur on it which required no CLI interactions. The kmutil man page doesn't go into sufficient detail. Searching for a step-by-step has led me in circles, since most of the info out there is pre-Catalina or oriented towards hackintoshes with EFI content manipulation via OpenCore.

Is it as easy as zipping the directory and then using 'kmutil load' of the zip file? I've turned off SIP for 3rd party kexts, though I guess that might be unneeded given it's from Apple? 🤷‍♂️

If not, please clue-bat me with a more step-by-step link?

(More clues on M2 bootstrapping process would also be welcome.)

Thanks in advance, I appreciate the deep knowledge on this forum. People here have saved me many times in the past between the C2Q hack and running an nVidia card in the MacPro.
 
I will warn you that you can spend a lot of time trying to get it to work. But I’ve had bad luck with USB Ethernet interfaces with that chipset. They just aren’t reliable especially coming out of sleep. I wound up buying a 2.5 gig USB Ethernet interface and use that from my TB docking station. That chipset and driver are solid in MacOS. Never had an issue with it. My advice is to forget the built in 8153 Ethernet and get a reliable 2.5 G adapter.
 
  • Like
Reactions: Bigwaff
mfram said:
I will warn you that you can spend a lot of time trying to get it to work. But I’ve had bad luck with USB Ethernet interfaces with that chipset. They just aren’t reliable especially coming out of sleep. I wound up buying a 2.5 gig USB Ethernet interface and use that from my TB docking station. That chipset and driver are solid in MacOS. Never had an issue with it. My advice is to forget the built in 8153 Ethernet and get a reliable 2.5 G adapter.
Click to expand...
I have another USB-A v3 hub based ethernet adapter I'm using at the moment, not sure of the chipset but it has the sleep issue.

Could you please share the chipset of your 2.5gb adaptor? I'd like to move my 3 main systems to use 2.5gb as my ISP just started offering it.
Bigwaff said:
You may find this gist interesting
Click to expand...
Thanks, Bigwaff. I should have mentioned that gist, apologies. I read the entire thing which is why I thought trying to sneak the binary from Big Sur (or perhaps later, have checked Monterey or Ventura yet) into the kext would be the best move.

As a long-time UNIX veteran, the loss of control on MacOS is making me seriously consider abandoning the platform. It's a kind of infantilization of the end user of the system. At least show me how and where to turn the whole mess off. And this comes from a person whose very first serious deep dive into computers was Classic Mac OS 3.0 or 3.1 on MacPlus.
 
Apple has created a total mess in /System/Library/Extensions. Kexts that are incomplete, not signed, notarized – Unknown, not Loadable.

While I could take AppleUSBRealtek8153Patcher.kext from Monterey Intel and install it in Sonoma 14.4.1 Apple Silicon, it can’t be loaded as dependencies are missing.

“Dependency Resolution Failures:
Indirect dependencies can't be resolved: com.apple.iokit.IOUSBHostFamily”

Installation

copy AppleUSBRealtek8153Patcher.kext into /Library/Extensions/

fix permissions

Code: 
sudo chown -R root:wheel /Library/Extensions/AppleUSBRealtek8153Patcher.kext

diagnostic

Code: 
sudo kmutil print-diagnostics -p -D /Library/Extensions/AppleUSBRealtek8153Patcher.kext

load

Code: 
sudo kmutil load -p /Library/Extensions/AppleUSBRealtek8153Patcher.kext

check status

Code: 
system_profiler SPExtensionsDataType | grep -A 15 "realtek8153patcher"

AppleUSBRealtek8153Patcher.jpg
 
Last edited:
Jazzzny said:
Kexts "being incomplete" in Ventura and newer is intentional behaviour. Nothing in System/Library/Extensions is supposed to be signed or notarized, as the binaries themselves were removed, and are instead provided as part of the Kernel Debug Kit. See https://github.com/dortania/OpenCore-Legacy-Patcher/issues/998#:~:text=for end users-,Removal of on-disk binaries for kexts in /System/Library/Extensions,-Similar to how
Click to expand...
Are we now going to pretend that every dumb thing Apple does is “as it should be”? Apple set the rules for software signing and notarization. It should respect them. If Apple doesn’t want to continue to provide support for some hardware on Apple silicon, Apple should remove the kext, not leave a broken one in the system volume. It’s not rocket science, it’s basic logic :)
 
  • Like
Reactions: platinumaqua and percyc
Have you tried loading it by reference to bundle identifier instead of the bundle path?
Code: 
sudo kmutil load -b com.apple.driver.usb.realtek8153patcher

bogdanw said:
Are we now going to pretend that every dumb thing Apple does is “as it should be”? Apple set the rules for software signing and notarization. It should respect them. If Apple doesn’t want to continue to provide support for some hardware on Apple silicon, Apple should remove the kext, not leave a broken one in the system volume. It’s not rocket science, it’s basic logic :)
Click to expand...
The kexts are still present, the Mach-O executables/binaries are elsewhere, compiled into a "kext collection". I suppose the kext bundles themselves are still necessary for the corresponding loaded kexts in the kext collection.
 
KALLT said:
Have you tried loading it by reference to bundle identifier instead of the bundle path?
Code: 
sudo kmutil load -b com.apple.driver.usb.realtek8153patcher
Click to expand...
"Bundle ID: com.apple.driver.usb.realtek8153patcher
Notarized: Unknown
Loaded: No
Obtained from: Not Signed
Location: /System/Library/Extensions/AppleUSBRealtek8153Patcher.kext
Kext Version: 5.0.0
Loadable: No
Validity Errors:
Validation Failures:
Kext has a CFBundleExecutable property but the executable can't be found: AppleUSBRealtek8153Patcher
Signature Validation Errors: Not Signed
Dependencies: Incomplete
Signed by: Not Signed"
realtek8153patcher.jpg
 
I am not sure if system_profiler provides reliable output here. When I cross-reference it with kmutil showloaded, it provides different results.

Can you query the result with kmutil? e.g.

Code: 
sudo kmutil load -v -b com.apple.driver.usb.realtek8153patcher
kmutil showloaded -b com.apple.driver.usb.realtek8153patcher

Maybe -v outputs whether loading was successful. It should show up with showloaded.
 
KALLT said:
I am not sure if system_profiler provides reliable output here. When I cross-reference it with kmutil showloaded, it provides different results.

Can you query the result with kmutil? e.g.

Code: 
sudo kmutil load -v -b com.apple.driver.usb.realtek8153patcher
kmutil showloaded -b com.apple.driver.usb.realtek8153patcher

Maybe -v outputs whether loading was successful. It should show up with showloaded.
Click to expand...

Adding -v -b when attempting to load also shows the same problem with this kext -- no binary.
Code: 
sudo kmutil load -v -b com.apple.driver.usb.realtek8153patcher.kext
Error Domain=KMErrorDomain Code=71 "Could not find: Extension with identifier 'com.apple.driver.usb.realtek8153patcher.kext' not found" UserInfo={NSLocalizedDescription=Could not find: Extension with identifier 'com.apple.driver.usb.realtek8153patcher.kext' not found}

I suspect the problem with loading from /Library/Extensions comes from this snippet from Big Sur's Info.plist file:
Code: 
    <key>LSMinimumSystemVersion</key>
    <string>11.7</string>
    <key>OSBundleLibraries</key>
    <dict>
        <key>com.apple.iokit.IOUSBHostFamily</key>
        <string>1.0.1</string>
        <key>com.apple.kpi.bsd</key>
        <string>14.0.0</string>
        <key>com.apple.kpi.iokit</key>
        <string>14.0.0</string>
        <key>com.apple.kpi.libkern</key>
        <string>14.0.0</string>
        <key>com.apple.kpi.mach</key>
        <string>14.0.0</string>
    </dict>
    <key>OSBundleRequired</key>
    <string>Root</string>
otool -L reports no linked libraries in the binary. This Info.plist reminds me of the plain text driver_aliases file on a Solaris box, listing all the vendor ID & model numbers mapping to a unique driver name. Progress 🤦‍♂️: "modern" OSes scatter XML around the file system instead of centralizing key system information in one place in a human readable format.
Running kmutil <keyword> help has more complete explanations of commands than the kmutil man page, so I tried the following:

Code: 
sudo kmutil libraries -p /System/Library/Extensions/AppleUSBRealtek8153Patcher.kext
No variant specified, falling back to release
Error Domain=KMErrorDomain Code=71 "Invalid argument: Kext at path /System/Library/Extensions/AppleUSBRealtek8153Patcher.kext has no executable?" UserInfo={NSLocalizedDescription=Invalid argument: Kext at path /System/Library/Extensions/AppleUSBRealtek8153Patcher.kext has no executable?}
On Big Sur, it returns 297 lines, all referencing services or registry entries in com.apple.kpi.iokit or com.apple.kpi.libkern except for
Code: 
__ZN15IOUSBHostDevice9metaClassE in /System/Library/KernelCollections/BootKernelExtensions.kc: com.apple.iokit.IOUSBHostFamily (1.2)

I'll poke at this some more on the weekend to see if I can modify the Info.plist to align with Sonoma and get it to load.
bogdanw said:
Are we now going to pretend that every dumb thing Apple does is “as it should be”? Apple set the rules for software signing and notarization. It should respect them. If Apple doesn’t want to continue to provide support for some hardware on Apple silicon, Apple should remove the kext, not leave a broken one in the system volume. It’s not rocket science, it’s basic logic
Click to expand...
I have to agree with bogdanw on this point.

I work at a large enterprise software company. Our customers would rampage if we left remnants for "debugging" but the feature itself did not work. We warn our customers for multiple releases about deprecation, remove the thing deprecated, and they are still upset. But at least we can point to: "We told you two years ago this would be removed."

I also get that Apple is trying to make computers safer for the vast majority of people out there who will never bother to learn anything about information security--there's a reason my parent's only "computers" are an iPad and iPhone.

But the experience for people like myself who have touched systems for decades has become a rat hole of figuring out how to do simple things--like automounting NFS volumes or adding a network driver. Why can't there be a middle ground?

I'm not a Linux fan for a number of reasons, but it is looking more and more like the handfull of non-systemd Linux distros, FreeBSD, or OpenIndiana are the only options left if you want full control of your desktop OS. You either get on the "supported hardware only" Apple spend money treadmill or you give up your privacy to the "telemetry vacuum" of Microsoft. Or, I suppose, embrace the pain and go back to building Hackintoshes.

In any case, thanks for everyone's advice thus far, and for reading my grumpy, over-the-hill, birthday rant. 🤣
 
  • Like
Reactions: bzgnyc2
percyc said:
Adding -v -b when attempting to load also shows the same problem with this kext -- no binary.
Code: 
sudo kmutil load -v -b com.apple.driver.usb.realtek8153patcher.kext
Error Domain=KMErrorDomain Code=71 "Could not find: Extension with identifier 'com.apple.driver.usb.realtek8153patcher.kext' not found" UserInfo={NSLocalizedDescription=Could not find: Extension with identifier 'com.apple.driver.usb.realtek8153patcher.kext' not found}
Click to expand...

Remove the .kext. The -b argument expects a bundle identifier, not a file name.
 
percyc said:
I am trying to get a USB-based Realtek 8153 ethernet interfacing working, which is embedded in a TB4 Dell WD22TB4 dock (tested working under Windows). It is attached to a MBPro M2 (13", 2022) running Sonoma 14.4.1.

To my knowledge, what needs to be enabled is the Apple USB Realtek8153 patcher kext. But on Sonoma, the binary file for this kext is missing. I've checked my Intel Sonoma 14.4.1 system from my work, and the binary is missing from it, too.
Click to expand...
I'm curious why do you need the kext. I have exactly the same Dell dock and it had been working fine for me since early 2021 after I bought the MBP 16 with M1 Pro. I always use wired ethernet in the office.

A few weeks ago, I stopped using the dock as I'm using Dell U3224KB monitor which has a builtin 2.5Gbps ethernet port (also USB based with Realtek 8156 chipset). But before that, the dock worked great for me without any extra configuration.
 
vanc said:
I'm curious why do you need the kext. I have exactly the same Dell dock and it had been working fine for me since early 2021 after I bought the MBP 16 with M1 Pro. I always use wired ethernet in the office.
Click to expand...
I feel clueness now. I ASSumed that since I was able to update the firmware on the WD22TB4 via Windows 10, including the Realtek ethernet update "fix" published on the Dell website, the port was working. But using USBView on the Windows side, the ethernet port isn't showing up, nor does it show in Device Manager.

This might be due to connecting it through a USB 3 Super Speed port on Windows rather than a TBolt port, but unfortunately I don't have a non-Mac with TBolt for testing. So at this point I can only assume the ethernet port is bad. Ultimately the plan is to move to 10gb on my LAN in the next year so the 8153 port would be obsolete then.

Apologies for wasting everyone's time, I very much appreciate the attempts to help and the discussion.
 
mfram said:
I will warn you that you can spend a lot of time trying to get it to work. But I’ve had bad luck with USB Ethernet interfaces with that chipset. They just aren’t reliable especially coming out of sleep. I wound up buying a 2.5 gig USB Ethernet interface and use that from my TB docking station. That chipset and driver are solid in MacOS. Never had an issue with it. My advice is to forget the built in 8153 Ethernet and get a reliable 2.5 G adapter.
Click to expand...
which one did you end up buying?
 
You must log in or register to reply here.
Register on MacRumors! This sidebar will go away, and you'll see fewer ads.
Top Bottom
Back