Skip to content

Add AirDrop hint to macOS Wi-Fi warnings - #1974

Open
affectful wants to merge 1 commit into
moonlight-stream:masterfrom
affectful:macos-awdl-connection-warning
Open

Add AirDrop hint to macOS Wi-Fi warnings#1974
affectful wants to merge 1 commit into
moonlight-stream:masterfrom
affectful:macos-awdl-connection-warning

Conversation

@affectful

Copy link
Copy Markdown

Summary

  • detect whether the active host route uses a Wi-Fi interface on macOS
  • when Moonlight reports real poor-connection frame loss and AirDrop is discoverable, suggest setting AirDrop to No One
  • preserve the existing bitrate warning for Ethernet, VPN, non-macOS, and AirDrop-Off streams

Motivation

macOS AWDL activity used by AirDrop and Continuity can periodically move the shared Wi-Fi radio off the infrastructure channel. This can look like insufficient bitrate even when PHY rate and TCP throughput are high.

I reproduced this against a wired Sunshine host with a Mac on 5 GHz Wi-Fi:

Test AirDrop discoverable AirDrop No One
Router RTT avg / max / stddev 10.599 / 89.103 / 20.067 ms 2.056 / 8.480 / 0.653 ms
Reverse UDP at 5 Mbps 11% loss 0% loss
Reverse UDP at 20 Mbps 14% loss 0% loss

The OpenWrt AP counters showed matching AP-to-Mac transmit failures during the lossy test. The route remained local over Wi-Fi, signal was about -50 dBm with 40 dB SNR, and reverse TCP still exceeded 500 Mbps by hiding the loss behind retransmissions.

This change deliberately does not infer AWDL interference from awdl0 merely being up. The hint is shown only when:

  1. moonlight-common-c has already reported poor connection quality from unrecovered frame loss,
  2. the established host route uses Wi-Fi, and
  3. AirDrop is currently Contacts Only or Everyone.

The message remains probabilistic: AirDrop may interfere; set it to No One.

Related: #159, #1427

Testing

  • git diff --check
  • compiled the Objective-C++ helper with Xcode clang++
  • standalone assertions for AirDrop modes Off, Contacts Only, Everyone, and unknown values
  • verified the test restored the real AirDrop preference to Off

A full Qt build was not run locally because this Mac does not have qmake/Qt installed.

@andygrundman

Copy link
Copy Markdown
Contributor

This is the wrong way to deal with AWDL. Set your 5ghz channel to 149 or 44, and disable 6E (6ghz) if your device supports it.

@affectful

affectful commented Aug 14, 2026

Copy link
Copy Markdown
Author

It's just a warning. I want to continue using a DFS channel as I am in a crowded apartment building and otherwise if I use a crowded channel I will not be able to stream 4k well. 5ghz only has really two usable channels and my apartment has about 20 networks on each using them, and it seems everyone puts their router near the window to the shared courtyard.

I'd much rather disable airdrop than to change the 5ghz channel to a crowded one. Can the warning be to tell the user to do either?

Or perhaps the warning could be "Airdrop may be causing stuttering, switch to channel 149 or 44". That way the solution to turn off airdrop can be implied for people like me who prefer that

@andygrundman

Copy link
Copy Markdown
Contributor

It sucks but the situation is that you cannot get around the AWDL problem by trying to disable services. It's used by so many things and I'm not sure it's possible to disable them all. Handoff, Continuity, Universal Clipboard, Sidecar, Airplay, Apple TV control, the list just goes on. The only solutions are wifi channel and buying a new Mac with an N1 chip.

@affectful

affectful commented Aug 14, 2026

Copy link
Copy Markdown
Author

Just disabling the constant scanning by turning Airdrop to "No One" immediately stopped the constant channel switch every 1s. As I've said, changing the wifi channel is not a solution for me because those channels are crowded; that would cause more lag. I'm also not going to drop my 64GB m1 max laptop that works fine for everything else and buy another $3k machine.

I can keep this solution in my head for personal use, but I worry for those users who are going to blame Moonlight for an Apple problem, or buy a new $300 router trying to fix it and find out they are still lagging.

@peter-ergisi

Copy link
Copy Markdown

Can confirm, bought a $300 router before seeing this in pursuit of fixing Wi-Fi issues related to AWDL

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants