[!NOTE] Precisely, the use in the SIMPLE Project is by bringing a M2L2 (an all-in-one device including an offline WiFi router, six Meta Quest headsets, and a computer running software; everything interconnected) into classrooms to easily use VR in ASEAN schools.
Most of the configuration presented here is made precisely for this use case.
If your setup runs on a local network with no internet access, the Quest will eventually disconnect. Android continuously tests whether WiFi has internet access, and when the check fails, it flags the network as bad, shows a No internet access warning.
On regular Android that's not too much of an issue, but Meta hates that (they want your data) and auto-disconnects to "avoid the inconvenience of not having internet" or something. Also Meta disable the automatic connection to a network tagged as No internet access, being a major issue in a game session to run LAN games...
SIMPLE fixes this by disabling the network probes entirely, so no wifi network can be flagged.
Android pings Google servers to check for captive portals, the login pages you see at hotels and airports. On an offline network, these requests time out, and Android interprets that as a connectivity problem. To spoof this, I simply disabled captive portal detection and points the probe URLs at localhost so they always answer instead of failing outward:
captive_portal_detection_enabled: 0
captive_portal_mode: 0
captive_portal_server: "localhost"
captive_portal_https_url: "https://localhost"
captive_portal_http_url: "http://localhost"
private_dns_mode: "off" handles a related issue: Android's private DNS feature (DNS-over-TLS) tries to connect to hardcoded DNS servers. On an offline network, these connections fail and can trigger additional disconnect logic. Turning it off removes that failure path.
Even with captive portal detection disabled, Android has multiple watchdog services that will abandon a network they don't like. SIMPLE disables all of them:
wifi_watchdog_on: 0
wifi_watchdog_poor_network_test_enabled: 0
network_recommendations_enabled: 0
network_avoid_bad_wifi: 0
wifi_passpoint_enabled: 0
wifi_enhance_network_while_sleeping: 0
The WiFi watchdog roams to another network or drops the connection when it thinks quality is poor. network_avoid_bad_wifi does exactly what it says: it disconnects from networks without internet. network_recommendations_enabled pops up suggestions to switch networks, which is disruptive mid-demo. wifi_passpoint_enabled disables automatic authentication with carrier hotspot networks, which is irrelevant in most setups but removes another background process that could interfere.
wifi_sleep_policy: 2 keeps WiFi active when the device sleeps. Without this, a headset that dozes briefly drops its connection and you have to manually reconnect it. Annoying.
wifi_networks_available_notification_on: 0 and netstats_enabled: 0 remove the last two sources of network-related noise: popups about other nearby networks, and background data usage tracking. Less background activity means fewer opportunities for the system to interrupt the connection.
A Meta Quest headset is quite battery hungry because of all the processing it has to do (6 DOF, heavy graphical computing, etc), and having 30~60 minutes of battery life is bad press. So a Meta Quest headset is the laziest device in the world and try to sleep as much as it can.
For instance, a stock Quest falls asleep after a few minutes of idle time. In any demo or session, "idle" happens constantly as someone waiting for instructions, a discussion, a presenter demonstrating something on the projector. If the headset sleeps, the player drops from the simulation (disconnect from the backend server) and has to wake it, reconnect, and rejoin. SIMPLE prevents this at three layers.
stay_on_while_plugged_in: 15
This is a bitmask. Each bit controls a different power source:
| Bit | Value | Power Source |
|---|---|---|
| 0 | 1 | AC adapter |
| 1 | 2 | USB |
| 2 | 4 | Wireless charging |
| 3 | 8 | Docked |
1 + 2 + 4 + 8 = 15, so the screen stays on across all four conditions. In a setup where headsets sit on USB charging cables or charging stands between uses, this alone prevents most mid-session blackouts.
screen_off_timeout: 86400000 // 24 hours
sleep_timeout: -1 // Disabled entirely
screen_off_timeout lives in the system settings namespace and controls when the display subsystem turns off the screen. sleep_timeout lives in the secure namespace and governs when the entire device enters deep sleep. SIMPLE sets both to never trigger.
<!-- Modifying secure settings requires WRITE_SECURE_SETTINGS permission, which is why SIMPLE installs a companion app with that privilege.-->
Meta adds its own logical layer, touching obviously to the lazyness sleep logic on top of Android, controlled through the PreferencesService binder interface:
idle_time_threshold: 14400 // Display off after 4 hours
autosleep_time: 14400 // Sleep mode after 4 hours
Both values are in seconds. Four hours covers a full session with breaks, but still lets a forgotten headset power down eventually instead of sitting awake overnight. The code checks the current value via getprop and only writes if it changed, so repeated reconnections don't waste calls.
[!NOTE] You can also set
autosleep_timethrough the headset's system settings GUI, it's probably the only setting from this entire article that's exposed in the interface. But SIMPLE sets it via ADB anyway as part of the automated configuration.
This one is interesting! 😋
When you remove a Quest headset, a proximity sensor detects the gap and blacks out the display to save power (or doze if you didn't applied any of the above parameters, remember: lazy device). In any multi-user setup, demo, else, headsets get passed around or set on charging stations between activities. If the display blacks out, the streaming session breaks and the next person sees a dark screen instead of the simulation.
<figure> <img src="/images/quest-adb-setup-simple-sensor.webp" alt="Picture of proximity sensors inside of a meta quest headset" /> <figcaption>This captor exists in both <i>Meta Quest 2</i> and <i>Meta Quest 3</i> (not the 3s)</figcaption> </figure>
SIMPLE disable this behavior by sending a broadcast on each headset's boot:
am broadcast -a com.oculus.vrpowermanager.prox_close
This forces the power manager to treat the headset as currently worn. The display stays on even when the headset is sitting on a charging stand or being handed from one user to the next, so the stream keeps flowing uninterrupted. The disadvantage is the battery life which is the most impacted by it.
[!NOTE] A lot of people (as well as us first) are putting opaque tape or similar on the sensor to fake it. But, from our experience, it's not that much reliable and created a lot of instability on some units. This method is better.
Beyond the session fixes, SIMPLE tweaks the devices with a maintenance layer that keeps the equipment stable over time. I don't want any new firmware changes overnight or connection drift breaking my setup in the morning of an exhibition...
ota_disable_automatic_update: 1
A system update downloading during a session, or worse, forcing an unexpected reboot, can end a demo. This stops Android's OTA updates from triggering automatically.
am set-standby-bucket com.oculus.updater restricted
am set-standby-bucket com.oculus.nux.ota restricted
cmd appops set com.oculus.updater RUN_ANY_IN_BACKGROUND deny
cmd appops set com.oculus.nux.ota RUN_ANY_IN_BACKGROUND deny
com.oculus.updater and com.oculus.nux.ota handle Meta's layer for firmware updates and telemetry. With restricted standby buckets and background execution denied, they cannot wake the headset. This pairs with ota_disable_automatic_update: 1 at the global settings level makes a two-layer defense against a fleet of headsets deciding to search and download a system update at anypoint.
[!CAUTION] Disabling auto-updates keeps your fleet in a known software state, which is what you want for reproducible demos. Just remember to manually update the headsets between projects if you need security patches or new features.
adb_allowed_connection_time: 9007199254740991 // ~285 years, effectively never
Meta's Android build times out ADB debugging sessions. When it expires, the headset drops from the platform and you have to re-authorize the host (to make this point clear, it's not ADB which is not up, but it refuses to connect with old paired device, ie. the server). Setting this to MAX_SAFE_INTEGER means the session survives indefinitely.
SIMPLE also installs eu.project_simple.adbautoenable, a companion app that keeps the ADB connection alive and handles re-authorization automatically. I already presented how it works in a previous article : https://arthurbrugiere.fr/blog/mq3-wireless-adb/
You pretty much broke all the engineering Meta put in their devices to give the players a nice experience, but you succeed to have device which works as you would expect in an exhibition or a classroom.
At least I'm happy to run them in the project now 😁
]]>Here is every issue I ran into, in order, so you don't have to repeat my mistakes.
[!NOTE] This "guide" is describing the struggle I had to install OMV 8.0.7 (stable) on a machine in a network with IPv6 disabled.
If you're using another version of OMV, your mileage may vary :)
I do have some experience installing Linux systems, so I pretty much followed the same steps as described in the official documentation: Downloaded the iso, flashed a USB stick, boot the OMV ISO, follow the first steps, connect to your WiFi network, type the password, see the "Configuring DHCP" loading screen, see the "Configuring DHCPv6" loading screen...
<figure>
<img src="/images/install-omv-8-without-ipv6-dhcp.webp" alt="Debian installer DHCP loading screen" />
<figcaption>I don't have ways to capture my installation screen, imagine it's written DHCPv6 please....</figcaption>
</figure>
The popup closes. You're staring at a blank blue Debian installer background. Nothing works. The keyboard registers keys and displays them on the screen, but nothing happens.
<figure> <img src="/images/install-omv-8-without-ipv6-bsod.webp" alt="Debian installer blue screen" /> <figcaption>The BSOD (Blue Screen Of <s>Death</s> Debian), not my most useful illustration...</figcaption> </figure>
The likely cause: the Debian installer tried DHCPv6 after getting an IPv4 address. However, my router has IPv6 disabled, the request timed out with no response or got an unexpected message... Anyway, the installer broke and after waiting 1 hour, I tried to fix it: I disabled IPv6 at the kernel level for this boot only.
To do so, at the GRUB boot menu, press e to edit the current entry. Find the linux line and append ipv6.disable=1 to the end:
linux /install/vmlinuz vga=normal quiet file=/cdrom/preseed.cfg ipv6.disable=1
Press Ctrl+X or F10 to boot. The installer skips DHCPv6 and proceeds.
[!TIP] Editing in GRUB with
echanges the boot parameters for this session only. Nothing gets written to disk. If it doesn't work, reboot and try something else. Once you confirm the fix, you can make it permanent later.
OMV installs, reboots, and the WiFi interface (wlp2s0 in my case) has no IPv4 address. The web UI is, obviously, unreachable. The ipv6.disable=1 fix was only for the installer boot, and the freshly installed system tries to negotiate IPv6 on the network. My router still has IPv6 disabled, so the negotiation fails and the interface gets no usable IP at all.
The fix: Again, boot with ipv6.disable=1 added from GRUB (press e at the boot menu, add it to the kernel line, Ctrl+X to boot).
After this, nothing is magically working yet. I had to manually bring the WiFi up with a few commands:
# Generate WPA config
wpa_passphrase "YourSSID" "YourPassword" > /etc/wpa_supplicant/wpa_supplicant.conf
# Connect my wifi interface using the generated config
wpa_supplicant -B -i wlp2s0 -c /etc/wpa_supplicant/wpa_supplicant.conf
# Request an IPv4 address to the network's DHCP.
dhcpcd wlp2s0
You should now have an IPv4 address and be able to ping the machine, but you won't be able to reach the web UI at http://<machine-ip> yet...
With WiFi up and an IPv4 address in hand, I tried to open the OMV web UI. Nothing on port 80. The nginx service was failing to start:
-- Unit nginx.service has begun starting up.
Jun 02 14:46:27 nginx[5069]: nginx: [emerg] socket() [::]:80 failed (97: Address family not supported by protocol)
Jun 02 14:46:27 nginx[5069]: nginx: configuration file /etc/nginx/nginx.conf test failed
Jun 02 14:46:27 systemd[1]: nginx.service: Control process exited, code=exited status=1
Jun 02 14:46:27 systemd[1]: Failed to start A high performance web server and a reverse proxy server.
-- Subject: Unit nginx.service has failed
The reason: OMV's nginx config binds to [::]:80 (the IPv6 wildcard) by default. But I had booted with ipv6.disable=1 on the kernel command line, my router doesn't provide any IPv6: so IPv6 is not available. Nginx tries to listen on [::]:80, gets "Address family not supported by protocol," and dies.
The fix: Edit the nginx site config to remove the IPv6 listen directive:
nano /etc/nginx/sites-enabled/openmediavault-webgui
Comment out the line listen [::]:80; (but keep the listen 80; line used for IPv4). Then restart nginx:
systemctl restart nginx
The web UI comes up. Log in, with the default credentials (admin / openmediavault), go to Network → Interfaces, configure your WiFi interface (me wlp2s0) with your WiFi credentials, set the IPv4 as DHCP and the IPv6 as Disabled, save and apply. On the next reboot the web UI starts without trouble, because the saved network config no longer uses the faulty IPv6.
<figure> <img src="/images/install-omv-8-without-ipv6-network-config.webp" alt="OMV network config with IPv6 disabled" /> <figcaption>Saved working network with IPv6 disabled</figcaption> </figure>
Finally :)
With the OS running on the SSD, the two 1TB drives become the data pool. I used Btrfs in RAID1.
Btrfs is a copy-on-write filesystem with built-in checksums, snapshots, and native RAID support. For a NAS, the checksums detect silent data corruption, snapshots let you roll back files if someone overwrites them, and RAID1 keeps your data alive if one drive fails (both disks are mirrored, I lose a lot of space, but I'm less likely to lose data). OMV handles all of this through the UI.
BTRFS from the dropdown.RAID1 for me).<figure> <img src="/images/install-omv-8-without-ipv6-btrfs.webp" alt="OMV FS configured with BTRFS and displaying 1TB of usable storage" /> <figcaption>Saved working network with IPv6 disabled</figcaption> </figure>
After that, create a shared folder on the volume and enable SMB, NFS and other network protocols under Services.
One thing to not forget to ease the management of the NAS is to set up a regular (monthly) scrub to catch silent data corruption. OMV 8 doesn't expose this in the UI, so use a scheduled task:
System → Scheduled Tasks → Add
Schedule: Monthly (0 2 1 * * for 2am on the 1st)
Command: btrfs scrub start /srv/dev-disk-by-uuid-XXXX
The goal for this NAS is simple: anyone in the lab walks in with their own machine, opens the file manager, find the NAS in their Network file tab, and gets in. No passwords, no account creation, no IT support. I configured the SMB share with Guests allowed, meaning anyone can connect as a guest and access files. I also enabled NFS and other protocols for the Linux (me 😁) and macOS machines in the lab.
Everything worked on every Linux machines. Everything worked on all macOS machines. It worked on the first Windows 11 machines. But other Windows 11 popped up a credential prompt that rejected everything I threw at it. Blank username, guest, random names. Nothing worked, no error message, no hint, just an endless login loop.
The probable cause: Windows 11 24H2 changed two SMB security defaults. Microsoft now requires SMB signing on all connections, and Windows 11 Pro disables insecure guest logons[^1]. Earlier builds (23H2 and before) still allowed guest fallback. 24H2 does not, and the behavior is inconsistent. Some 24H2 machines on my network connected fine, others refused. I couldn't find a pattern.
I tried the obvious OMV-side fixes. Guests only (force anonymous access). Guests allowed with nobody given full ACL permissions. None of it mattered. The Windows machines that locked down guest access wouldn't connect without a valid credential, and OMV didn't have any credential to connect with.
I saw on internet the possibility to use some admin PowerShell commands that I did not try. The whole point of this NAS is that it works from any machine in the lab without touching the client. Running around to every Windows computer to change security settings is not an acceptable fix.
The fix: Create a single shared user in OMV.
In the OMV web UI:
lab (or whatever, I won't write on internet the one we use :) )password (something simple everyone in the lab can remember, but maybe not that..)Then in your SMB share settings, set Public to Guests allowed and give the lab user read/write permissions on the shared folder.
On each Windows machine, when the credential prompt appears:
labpasswordWindows caches the credentials after the first successful connection. You enter them once per machine and you won't need to enter them again.
<figure> <img src="/images/install-omv-8-without-ipv6-final.webp" alt="OMV dashboard with plenty of stats" /> <figcaption>The dashboard of the NAS with plenty of stats but nobody using it there</figcaption> </figure>
Two weeks in, the NAS just works. The Windows machines all connect, the scrubs run monthly (I hope), and everyone's happy about it.
[^1]: Microsoft made this change in Windows 11 24H2, released in late 2024. It affects both the SMB signing requirement and guest logon behavior on Pro and Enterprise editions. See Microsoft's official guidance on SMB signing and guest authentication.
]]>I spent several days in that gap between "possible on paper" and "working in practice." The project is SIMPLE Webplatform, a Node.js application that bundles a web frontend, a WebSocket server (via uWebSockets.js, the fastest WebSocket implementation for Node.js with a minimal memory footprint), and all the background logic and streaming layer into one stack. Shipping it meant producing a single file that a researcher or developer could download and double-click without installing Node.js, opening a terminal, or running npm install.
A previous attempt had used @yao-pkg/pkg, a community fork of the now-deprecated pkg, to build binaries for Linux, macOS and Windows from NodeJS applcaition. Those 2 first binaries worked. The Windows binary exited with code 0xC0000005 (access violation) the instant you ran it. No output. No stack trace. Just a segfault.
This is the story of how I fixed it, and the two Windows behaviors you will not find in any documentation.
The application uses uWebSockets.js for its WebSocket and HTTP servers. This library is written in C++ and exposes a native .node binary that hooks deep into the Node.js event loop. That detail, native module, turns out to be the entire problem.
@yao-pkg/pkg works by embedding your JavaScript and assets into a modified node.exe, then patching process.dlopen (Node.js's low-level function for loading native .node binaries, similar to LoadLibrary on Windows) so it can load native modules from an in-memory snapshot rather than the filesystem. On Linux and macOS, this patch is transparent. On Windows, it crashes during uWebSockets.js initialization.
I confirmed this through isolation. The .node file extracted from the snapshot was valid. You could load it with regular Node.js without issue. The crash happened inside @yao-pkg/pkg's patched dlopen the moment uWebSockets.js tried to register its NAPI callbacks (functions that bridge between C++ code and the JavaScript engine) with the runtime. The module was incompatible with the patched loader on Windows, full stop.
Replacing uWebSockets.js with the pure-JavaScript ws library was not an option. The project depends on uWebSockets.js for its throughput and memory efficiency (it handles an order of magnitude more concurrent connections than ws with a fraction of the RAM). I needed a packaging tool that leaves process.dlopen untouched.
Node.js 20 introduced Single Executable Applications (SEA), a native mechanism for embedding your application into a copy of node.exe. SEA does not patch process.dlopen. It uses postject (a CLI tool that injects a binary blob as a new section into an existing executable) to embed your code and assets as a PE (Portable Executable, the standard binary format for Windows) / Mach-O section into an unmodified Node.js binary. The runtime stays stock. Native modules load through the same path they would in a normal Node.js process.
I rewrote the build pipeline:
uWebSockets.js .node file into a SEA configurationnode --experimental-sea-config generates the blobpostject injects the blob into a Windows node.exe copyThe resulting binary was 103 MB and crashed on launch. The crash was not the same 0xC0000005 from pkg. This time, the issue was that SEA mode replaces the standard require() with an internal embedderRequire that cannot load .node files from arbitrary paths. The .node file was embedded in the SEA asset bundle, but require(tmpFile) failed because embedderRequire does not know how to handle a native module path in SEA context.
This was the moment the investigation turned from frustrating to non-sense. I had been testing hypotheses about Control Flow Guard flags, Authenticode signature corruption, and DLL load paths. None of them panned out. Then I ran a test I should have tried hours earlier. I took a plain, unmodified node.exe, with no SEA blob, no injection, nothing, copied it to the same directory, renamed the copy to plain-node.exe, and tried to load uWebSockets.js from it.
It crashed.
I renamed that exact same file back to node.exe. It worked.
Same bytes. Same directory. Same everything except the filename. One crashed, one did not.
Windows maintains an Application Compatibility database, a set of shims that apply behavioral fixes to specific executables based on their name. One of those shims targets node.exe and alters how DLLs are loaded to support Node.js native modules. When you rename the executable to anything else, simple-win.exe, app.exe, anything, that shim disappears, and uWebSockets.js's NAPI initialization hits a code path that triggers an access violation.
This is not documented anywhere obvious. You will not find it in the Node.js SEA guide or the postject README. You find it by accident, after stripping a binary down to nothing and watching a plain node.exe copy fail because you generated the artifact file with a meaningful name.
The build script now outputs the SEA binary to bin/win/node.exe. Not simple-win.exe. Not app.exe. The application must be named node.exe for the Windows AppCompat shim to activate.
With the name fixed, the binary started. But uWebSockets.js was not loading from the SEA asset bundle yet. SEA provides two ways to access embedded assets: sea.getAsset() returns the raw bytes, and require() in SEA mode uses an internal embedderRequire that cannot load .node files from arbitrary paths.
The fix was a Vite plugin that transforms every require("uWebSockets.js") in the compiled bundle into a self-contained loader (not the real code, but a comprehensive snippet):
// In SEA mode:
// Load the SEA module (only available inside SEA binaries)
const sea = require('node:sea');
// Build a versioned temp path for the .node file
const tmpFile = path.join(os.tmpdir(), 'uws-' + process.versions.modules + '.node');
// Extract the native module from the embedded asset blob to disk
fs.writeFileSync(tmpFile, Buffer.from(sea.getAsset('uws_win32_x64_137.node')));
// Create an empty module object for dlopen to populate
const mod = { exports: {} };
// Load the .node file directly via the C-level loader (bypasses SEA's embedderRequire)
process.dlopen(mod, tmpFile);
// Return the loaded module to the caller
module.exports = mod.exports;
In development or standard packaging, it falls back to a normal require('uWebSockets.js'). The .node file gets extracted to a temp directory once and loaded through the unmodified process.dlopen. Because the parent binary is named node.exe, this now works.
Shipping an application called node.exe is not a good user experience. Users see a generic name in their download folder, their task manager, and their desktop shortcuts. I needed a user-facing binary with a proper name that still resulted in a process named node.exe running under the AppCompat shim.
The solution is a launcher, a thin wrapper that extracts the real binary and runs it. I chose Go because it compiles to a statically linked native Windows executable with zero runtime dependencies. Three extra megabytes for the launcher is a fair trade for shipping a single file that needs nothing installed on the user's machine.
The launcher, written in Go:
node.exe payload and a magic number to verify validitynode.exe to %TEMP%\swp-node-<size>\node.exe (preserving the critical name)node.exe with all command-line arguments forwarded, inherits stdout/stderr, and exits with the same codeThe build pipeline compiles the Go launcher, appends the node.exe SEA binary, writes the footer, and produces a single file: simple-win.exe.
First launch takes a few seconds as 103 MB extracts to temp. Every launch after that is instant.
With Windows solved, I looked at the remaining packaging infrastructure. @yao-pkg/pkg was still building Linux and macOS binaries through a cross-compilation pipeline that required QEMU user-mode emulation and ldid for macOS code signing. It worked, but it was a maintained fork of an abandoned project, running emulated architectures on an Ubuntu CI runner: Not very easy to maintain.
Since SEA was now working for Windows and is a native Node.js feature, the question became: why maintain two packaging systems? I migrated Linux and macOS to SEA as well. The same build script template works on all three platforms with minor platform-specific flags (--macho-segment-name for macOS, ad-hoc codesigning after injection). Cross-compilation disappears, since each platform builds on its own native GitHub Actions runner, but the project is open source and the runners are free.
The CI pipeline now has three parallel jobs: ubuntu-latest for Linux, macos-latest for macOS, and windows-latest for Windows. Each produces one binary using the same Node.js SEA mechanism. No more QEMU. No more ldid. No more pkg.
The SIMPLE Webplatform now ships as a single executable on all three platforms. Windows uses a Go self-extracting launcher that bundles a SEA-built node.exe and extracts it to temp on first run. Linux and macOS use native SEA binaries without wrappers. The packaging pipeline relies on Node.js built-in tools plus postject and Go. No deprecated third-party packagers, no emulation layers, no platform-specific native module patching.
<figure> <img src="/images/packaging-nodejs-windows-sea-compilation.webp" alt="Compilation logs of the windows binary" /> <figcaption>Compilation logs of the windows binary on Github Actions</figcaption> </figure>
If you are packaging a Node.js application with native modules for Windows, use Node.js SEA (it's been in beta for very long time, but it really works fine nowadays), name your binary node.exe, and wrap it with a launcher if your users need a branded filename. Those three things would have saved me days of debugging.
The full implementation is in project-SIMPLE/simple.webplatform#151.
]]>I needed my MacBook Air M2 (Sonoma) to broadcast its own WiFi network, being a WiFi server instead of a client. Not to share an internet connection, just to create a local wireless network so other devices could connect to it and talk to each other. Think local development and setting up a private LAN without carrying a router.
macOS has a built-in Internet Sharing feature (documentation), but it's designed to share an existing internet connection (like Ethernet or Bluetooth tethering) over another network (such as WiFi).
On a MacBook with only a WiFi card and no wired connection, creating a standalone access point is not straightforward.
So I did follow the documentation and the internet's recommendations. I went to System Settings → General → Sharing → Internet Sharing and enabled everything:
Wi-FiEverything appeared enabled. No error messages. No warnings. But the WiFi network simply never appeared. Not on my phone, not on any other device. macOS accepted the configuration but silently refused to actually broadcast the signal.
<figure> <img src="/images/macbook-air-access-point-wifi-not-working.webp" alt="Internet sharing is enabled, but not wifi is broadcasted" /> <figcaption>Internet sharing is enabled, but not wifi is broadcasted (it should be displayed here as we will see later)</figcaption> </figure>
The reason: macOS Internet Sharing is built to share an existing (i.e. activated, up) connection, not blindly bridge one network stack to another. Without an active upstream connection that the system recognizes as active, the underlying service doesn't actually bring up the access point, even though the UI lets you enable everything.
The solution came from a gist by @zhuhuilin: <a href="https://gist.github.com/zhuhuilin/01656866b3e73a677a434c21183b40d2" target="_blank">macOS Internet Sharing Without Internet Connection</a>[^note].
The trick is to create a new network service on the loopback interface (lo0). macOS only checks that the network service has an IP address (which is apparently how it determines whether a connection is active) before allowing Internet Sharing. It doesn't verify that the connection reaches the real internet. By assigning a static IP to lo0 and registering it as a network service, macOS happily accepts it as a valid source.
The gist provides the exact commands to run in Terminal:
curl -L https://gist.github.com/zhuhuilin/01656866b3e73a677a434c21183b40d2/raw/setup-adhoc-network.sh | bash
<figure> <img src="/images/macbook-air-access-point-wifi-terminal.webp" alt="Running zhuhuilin's setup script" /> <figcaption>Running zhuhuilin's setup script</figcaption> </figure>
This will automatically:
AdHoc) on lo010.10.10.1 on this new service<figure> <img src="/images/macbook-air-access-point-wifi-AdHoc-setup.webp" alt="MacOS Settings window with the Internet Sharing configured with the AdHoc interface" /> <figcaption>Internet Sharing configured with the AdHoc interface, just need to enable it now</figcaption> </figure>
Then you can select this AdHoc service as your source in Internet Sharing. Once configured, macOS actually brings up the WiFi access point, and devices can see and connect to it.
[!CAUTION] The WiFi should be enabled on MacOS to have the beacon activated. But it should not be connected to any networks.
<figure> <img src="/images/macbook-air-access-point-wifi-enabled.webp" alt="Keeping wifi enabled and seeing the shared network broadcasted" /> <figcaption>WiFi is enabled, and is showing the "Internet Sharing" on Channel 11</figcaption> </figure>
By default, macOS Internet Sharing assigns connected devices to the 192.168.2.0/24 range. I needed mine to be 192.168.68.0/24 to match my existing setup.
After some digging, I found that you can override the default DHCP range with three defaults write commands targeting the system NAT preferences:
# Set the starting IP address
sudo defaults write /Library/Preferences/SystemConfiguration/com.apple.nat NAT -dict-add SharingNetworkNumberStart 192.168.68.2
# Set the last IP address
sudo defaults write /Library/Preferences/SystemConfiguration/com.apple.nat NAT -dict-add SharingNetworkNumberEnd 192.168.68.254
# Set the netmask as /24
# -> This isn't automatic and is necessary!
sudo defaults write /Library/Preferences/SystemConfiguration/com.apple.nat NAT -dict-add SharingNetworkMask 255.255.255.0
After running these and restarting Internet Sharing, connected devices received IPs in the 192.168.68.x range — exactly what I needed.
[!TIP] Settings seems to cache these parameters. Quit the Settings application before applying them, then reactivate Internet Sharing.
The whole thing works reliably once the loopback trick is in place. The AdHoc service survives reboots, and the DHCP range sticks as long as you don't reset the NAT preferences. The one thing to keep in mind: if you do have an actual upstream connection available (Ethernet, USB tethering), you can use that directly as the Internet Sharing source and skip the loopback hack entirely, it's only needed when you want to have an access point from macOS without internet.
[^note]: I made a backup of Zhuhuilin's scripts here
]]>adb tcpip 5555 again" isn't a solution, it's a support ticket generator at best. I spent weeks trying to automate the "Allow wireless debugging?" popup out of existence. The path involved dead ends, Android security walls, and finally a brute-force accessibility hack that actually works.
<figure> <img src="/images/mq3-wireless-adb.webp" alt="ADB Wireless Popup visible in a Meta Quest 3 headset" /> <figcaption>The "Allow wireless debugging?" popup on a Meta Quest 3.<br/>Credit: Image from <a href="https://www.quest-games-optimizer.com/how-to-enable-adb-from-your-meta-quest">QGO</a></figcaption> </figure>
Wireless ADB on stock Android is straightforward: enable it once, pair your machine, and the phone remembers. Meta's Quest OS, built on Android but heavily modified, treats this differently: On every reboot, the system clears its in-memory list of trusted wireless debugging fingerprints. The adb_wifi_enabled setting flips to 0 (which is normal). Reconnect, and you're greeted with the same permission dialog asking if you trust this network.
For the SIMPLE project — a swarm of six Meta Quest 3 headsets streaming video via scrcpy and receiving commands from a central controller — this was a deployment blocker. We can't send a technician to every school every morning to click one popup in each headset...
Before writing a single line of Java, I tried the obvious tools Automate, Tasker (ie. the usual Android automation workhorses). Set up a simple flow: when the system shows the ADB popup, click "Allow" or "Always allow." Should be trivial.
It isn't. The moment those apps trigger adb tcpip 5555 (toggle the wireless debugging setting), the system popup appears and pauses the automation engine.
The blueprint or macro freezes in place, waiting for the dialog to dismiss — which it never will by the automation, because the automation is paused and can't click it. Classic deadlock. The popup blocks the very tool trying to dismiss it.
This killed the no-code approach instantly. I needed something that could run outside the normal app lifecycle, something the system couldn't freeze when the dialog appeared.
The next obvious approach: grant WRITE_SECURE_SETTINGS to a foreground service and toggle adb_wifi_enabled to 1 on boot. This works right up until the system shows the trust popup. Writing the setting triggers WifiDebuggingAlertActivity from com.oculus.os.vrusb, which sits there waiting for human input. The setting value bounces back to 0 until someone clicks "Allow."
So the real problem isn't enabling ADB (by automation or from within some java code) it's dismissing the popup without a finger.
Android's input command can simulate key events. From a PC, adb shell input keyevent 66 (Enter) dismisses the popup instantly. Running the same command from inside the app, however, throws:
Targeted input event injection from pid 3266 was not directed at a window owned by uid 10168
The app runs as a regular user (UID 10168). The popup belongs to the system package com.oculus.os.vrusb (UID 1000). Android's input injection security prevents cross-UID event spoofing unless you hold INJECT_EVENTS, which is signature-level and not grantable via pm grant. The shell user (UID 2000) has this permission, which is why ADB from a PC works. Your app does not and, except if you can root the device, can't have it.
I tried Shizuku as a workaround — it lets apps run code via a privileged server process. Even with Shizuku, the input injection path hit the same wall. The Quest's VR shell is aggressively locked down.
Android's AccessibilityService is the standard way to automate UI interaction for assistive purposes. It can traverse the view hierarchy, find nodes by text or ID, and perform ACTION_CLICK. This works beautifully for normal apps. I assumed it would work here too. I assumed wrong, and I spent two days proving it.
The popup activity launches — ActivityTaskManager confirms it:
04-21 10:27:35.928 ActivityTaskManager: START u0 cmp=com.oculus.os.vrusb/.WifiDebuggingAlertActivity
But getWindowsOnAllDisplays() returns everything except the VrUsb window. The scan shows Meta Horizon Shell, Navigator, Quick controls, random AndroidPanelLayer components: the usual VR shell noise. No popup. I broadened the search to check every display, every package containing com.oculus.os, every title containing "debugging" or "alert". Still nothing.
When I finally managed to catch a window with the right package name, its root node was null.
Not empty — null. The accessibility service could see the window existed but it was a black box. Meanwhile, uiautomator dump (running as shell user) could see the full node tree with "Always allow" and "Allow" plain as day. The popup was there on screen, visible to privileged tools, but to my accessibility service it was a ghost behind frosted glass.
I tried every variation: traversing parent nodes from child windows, using getRootInActiveWindow() instead of enumerating displays, matching by ViewIdResourceName, searching for partial text. I added aggressive logging that dumped every node property I could access. The service logged hundreds of windows across dozens of scans, but the moment the popup appeared, the corresponding window either vanished from the list or reported root=null.
Meta's VR environment renders system dialogs through a completely different path than standard Android views. The compositor draws them; the accessibility tree doesn't expose them. This isn't a bug you can code around but an architectural mismatch. The accessibility framework was built for flat phone screens, not layered VR shells where a "window" might be a texture mapped onto a curved surface in 3D space.
Days of dead ends.
After the clicking approach failed, I realized something: I didn't need to see the button. I needed to make the system think someone pressed Tab and Enter. And the AccessibilityService has a way to do that — not by injecting raw input events (Attempt 3), but by sending accessibility events that the VR shell already listens to for controller navigation.
The AccessibilityService detects the popup via window title matching — when getWindowsOnAllDisplays() returns a window containing "VrUsb", it triggers. Then it simply runs input keyevent via Runtime.exec(). The exact same command that failed from a regular app.
Here's the code of the accessibility service:
private void performBlindSequence() {
lastActionTime = System.currentTimeMillis();
Log.d(TAG, "TAB x3, ENTER");
handler.postDelayed(() -> sendKey(KeyEvent.KEYCODE_TAB), 0);
handler.postDelayed(() -> sendKey(KeyEvent.KEYCODE_TAB), 100);
handler.postDelayed(() -> sendKey(KeyEvent.KEYCODE_TAB), 200);
handler.postDelayed(() -> sendKey(KeyEvent.KEYCODE_ENTER), 300);
}
private void sendKey(int keyCode) {
try {
Runtime.getRuntime().exec("input keyevent " + keyCode);
} catch (Exception ignored) {}
}
First Tab put focus on the VrUsb window, then two extra Tabs move focus from "Allow" to "Deny" to "Always allow on this network". Enter activates. The 100ms spacing between each keypress is the minimum I found that the shell reliably registers — any faster and keys get dropped.
The window detection is equally dumber:
for (AccessibilityWindowInfo w : windows) {
CharSequence title = w.getTitle();
if (title != null && title.toString().contains("VrUsb")) {
Log.i(TAG, "VrUsb detected. Triggering trust sequence.");
performBlindSequence();
return;
}
}
No node traversal. No findAccessibilityNodeInfosByText. Just check if any window title contains "VrUsb" and blindly fire keys.
The full solution is a foreground service that:
WRITE_SECURE_SETTINGSadb_wifi_enabled to react instantly when Meta's system clears itNo hardcoded boot delays. No "wait 60 seconds for WiFi" loops. The service reacts to actual system state changes.
Quest OS has a few behaviors that make this harder than stock Android:
adb_wifi_enabled flips to 0, which happens because the popup appeared. If your service blindly retries enabling ADB in response, you spawn infinite threads racing each other. We guard this with an AtomicBoolean so only one configuration attempt runs at a time.getWindowsOnAllDisplays() to show you the popup. Don't trust getRootInActiveWindow(). The popup exists in the compositor, not the standard view hierarchy. Blind key injection is the only reliable path.The app is a single APK, granted WRITE_SECURE_SETTINGS once via ADB after installing the app. After that, teachers power on the headsets, the service starts automatically, and wireless ADB is ready within seconds after the headset connect to the network without anyone touching the controllers.
Repository is here if you're fighting the same fight: https://github.com/project-SIMPLE/adb-auto-enable
<figure> <video controls style="width:100%"> <source src="/videos/mq3-wireless-adb.mp4" type="video/mp4"> </video> <figcaption>Demo: headset auto-enabling/accepting the ADB Wireless popup.</figcaption> </figure>
If Meta ever exposes a system property or hidden API to persist wireless debugging trust, this whole accessibility dance becomes unnecessary. Some developers already filed feedback through their developer channels for, maybe, years, but I'm not holding my breath. For now, abusing the accessibility framework for input injection is the least-worst option.
]]>