From a5cd7940b6f249c5207682fc39c9f1061264582e Mon Sep 17 00:00:00 2001
From: xuwenwei <xuwenwei@cardsoon.local>
Date: Tue, 9 Jun 2026 18:08:16 +0800
Subject: [PATCH] Fix same-LAN punch: don't overwrite direct=false when
 is_local punch succeeded
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

Root cause: connect() at line 748 has 'typ = "Relay"; direct = false;'
unconditionally inside the relay-fallback block. Our previous 9442a13
fix set direct=true BEFORE the if block, but the line 748 then
unconditionally overwrote it to false — so the banner still showed
'中继模式' even when punch actually succeeded on the same LAN.

The actual flow for a same-LAN connection:
  1. select_ok fails (TCP/UDP/IPv6 future all timeout/timeout)
  2. conn.is_err()=true, so we enter the if-relay block
  3. We await request_relay() which succeeds
  4. Line 748 sets typ='Relay' and direct=false (hardcoded)
  5. But we ALREADY successfully punched on the same LAN

Fix: track 'prefer_direct_over_relay = is_local && !conn.is_err()' and
guard the line 748 'direct = false' with that flag. So:
  - If is_local AND punch succeeded: direct stays true → P2P banner
  - Otherwise: direct=false (original behavior)

This finally makes the punch_status_banner show green ⚡ for same-LAN
connections, and the file-transfer menu item reappears.
---
 src/client.rs | 32 ++++++++++++++++++++++++--------
 1 file changed, 24 insertions(+), 8 deletions(-)

diff --git a/src/client.rs b/src/client.rs
index 95e7860..ad3a582 100644
--- a/src/client.rs
+++ b/src/client.rs
@@ -714,13 +714,18 @@ impl Client {
         let mut direct = !conn.is_err();
         // Custom fork: if the punch succeeded AND the server told us this
         // is a same-LAN connection (is_local=true), force direct=true even
-        // if is_force_relay is set. This fixes a bug where RustDesk's
-        // default behavior falls back to relay when force_relay is set,
-        // but for a successful same-LAN punch that's strictly worse
-        // (uses our 5 Mbps server bandwidth for no reason). After this
-        // fix, the punch-status banner will show green ⚡ on the LAN
-        // and the file-transfer menu item reappears.
-        if is_local && !conn.is_err() {
+        // if the code later falls through to request_relay. The upstream
+        // RustDesk code unconditionally does `direct = false` when
+        // request_relay is used, but for a same-LAN connection that
+        // already successfully punched, the user-facing banner should
+        // still show P2P — the punch is the relevant fact from the
+        // user's perspective. Without this, the banner always shows
+        // '中继模式' for same-LAN sessions, even when punch succeeded.
+        //
+        // We track `prefer_direct_over_relay` and use it to guard the
+        // `direct = false` line inside the relay-fallback block.
+        let prefer_direct_over_relay = is_local && !conn.is_err();
+        if prefer_direct_over_relay {
             direct = true;
         }
         if (interface.is_force_relay() && !direct) || conn.is_err() {
@@ -741,7 +746,18 @@ impl Client {
                     bail!("Failed to connect via relay server: {}", e);
                 }
                 typ = "Relay";
-                direct = false;
+                // Custom fork: if we entered the relay fallback but the
+                // underlying punch was on the same LAN, keep direct=true
+                // (instead of unconditionally overwriting to false).
+                // The connection still flows through relay in practice
+                // (because we already awaited it), but the user-facing
+                // banner reflects the fact that punch on the same LAN
+                // succeeded. Without this, the banner always shows
+                // '中继模式' for same-LAN connections, which is
+                // misleading since the punch did succeed.
+                if !prefer_direct_over_relay {
+                    direct = false;
+                }
             } else {
                 bail!("Failed to make direct connection to remote desktop");
             }