Title suggestion: macOS CrealityScan can’t find Pika over WiFi — root cause narrowed down
TL;DR: Pika’s WiFi hotspot and the Mac’s WiFi hardware both work fine — proven via USB (works) and via iPhone WiFi (works). Only CrealityScan on macOS over WiFi fails, and I tracked it down to CrealityScan’s own embedded SDK never completing device discovery, while the standalone system service it installs (RPCServer) can discover and connect to the same scanner over the same WiFi. Full technical write-up and log excerpts below.
Environment
- Scanner: Creality Pika, Firmware 1.1.10 (“latest” per in-app update check)
- CrealityScan: version 4.3.1 (“latest” per in-app update check; internal build/engine version logged as
1.12.11) - macOS 26.6.2 (Build 25G83)
- Tested on two different Macs (MacBook Air M4, MacBook Pro) — same result on both
What works / what doesn’t
USB wired connection — works fine on both Macs- WiFi connection from an iPhone to the same Pika — works fine
WiFi connection from either Mac via CrealityScan — never connects (“No Device”), even after connecting to the Pika hotspot correctly and waiting several minutes- The scanner’s own display reacts instantly and correctly when a WiFi client joins/leaves (switches from “connect your device” to “start scanner software”), confirming the WiFi link itself is healthy
This isolates the problem to CrealityScan’s macOS-side network device discovery — not the scanner, not the WiFi hardware/driver, not the router/network environment.
Related documentation
- Official Creality Wiki: Mac not recognizing devices - Restart the RPC service — already followed these exact steps, no success. That’s what led to the deeper RPCServer investigation below.
- Related but distinct: Ferret Pro Wireless Bridge “Set Password” pop-up issue — different root cause (network interface prioritization), already ruled out for this case, but flagging as related prior art.
Root-cause narrowing: standalone RPCServer works, the app’s embedded SDK doesn’t
CrealityScan installs a background service /Library/Creality/RPCServer (com.creality.RPCServer LaunchAgent) that links the same libOrbbecSDK.1.7.1.dylib the app itself bundles.
RPCServer: successfully found & connected the Pika over WiFi (click to expand)
When manually restarted while already connected to the Pika’s WiFi hotspot, RPCServer’s GVCP client:
- detected the WiFi IP segment (
192.168.10.100) - discovered the Pika at
192.168.10.1via GVCP broadcast - opened a TCP control connection to
192.168.10.1:8090 - read firmware data and serial number
- initialized all sensors (Color, IR-Left, IR-Right, Accel, Gyro)
Reproduced twice, ~90s and ~180s after RPCServer start:
[GVCPClient.cpp:771] New ip segment found,new ip addr:192.168.10.100, mac:..., interfaceName:en0
[GVCPClient.cpp:457] 2,1, <MAC removed>,7, 5,3083, 192.168.10.1, 255.255.255.0, 192.168.10.254, Orbbec, Creality Pika, v1.0.1, Orbbec, <SN removed>,
[VendorTCPClient.cpp:131] TCP client socket created!, addr=192.168.10.1, port=8090
[PropertyAccessor.cpp:50] get firmware data success! propertyId: 1000, dataLen: 164
[PikaDevice.cpp:81] Pika device created! PID:3083, SN:<SN removed>, depthMode: {name: Laser Lines Scan, ...}
CrealityScan.app itself: never succeeded, even after 4.5 minutes (click to expand)
CrealityScan.app bundles its own copy of the SDK (liborbbec_scan.3.5.1.dylib + its own libOrbbecSDK.1.7.1.dylib under CrealityScan.app/Contents/PlugIns/) and runs its own independent GVCP discovery (Context created with config: default config!, EnumerateNetDevice:true — already on by default). Across two full test runs, launched while already connected to the Pika’s WiFi and correctly bound to 192.168.10.100, it never found the device:
- Run 1: 72 seconds, no device found
- Run 2: 4.5 minutes, no device found
Only this, repeating for the whole duration:
[GVCPClient.cpp:325] bind 192.168.10.100:0
[GVCPClient.cpp:239] local mac address: ..., local ip address:0.0.0.0, interfaceName:en0
[GVCPClient.cpp:355] sendto failed with error:49
No device found
(error 49 = macOS EADDRNOTAVAIL; one occurrence of error 65 = EHOSTUNREACH was also seen)
So the exact same underlying SDK binary succeeds as the standalone service, but fails every time inside the app’s own embedded instance, under identical WiFi conditions.
Already ruled out on the macOS side
(so please don’t ask me to try these — already tested, all clean)
- Private WiFi address / MAC rotation for the Pika network → set to Fixed, not rotating
- macOS “Local Network” permission (TCC) → no denial entries for either process
- macOS Application Firewall → completely disabled
- VPN → none active
- App Sandbox → CrealityScan.app is not sandboxed
- Wi-Fi 6 (802.11ax) support → present on both test Macs
- Other competing network interfaces (Ethernet/USB tethering/VPN) → all disabled, WiFi is the only active interface
EnumerateNetDevicein/Library/Creality/OrbbecSDKConfig_v1.0.xml→ tested both values; app’s embedded SDK already defaults totrueanyway
Minor extra oddity
The GVCP discovery broadcast from the scanner reports firmware v1.0.1, while CrealityScan’s Device Management page reports the same serial as firmware 1.1.10. Might be a red herring (different version field/namespace), but flagging it in case it’s a clue.
Question for the team
What differs between RPCServer’s GVCP discovery/connect path (works) and the liborbbec_scan.3.5.1.dylib discovery path used inside CrealityScan.app itself (fails consistently on macOS), given both ultimately call into the same libOrbbecSDK.1.7.1.dylib?
Full logs (RPCServer system log, CrealityScan Player.log, and the two failed test-run folders, all pre-checked for anything sensitive) can be provided. Happy to run additional test — just tell me what to check.