Why they differ: nslookup queries router’s DNS server (192.168.2.1) directly and returns the IPv4 address. ssh doesn’t use DNS for .local names. It goes through the macOS system resolver, which uses mDNS/Bonjour. That path can return a different answer, for example an IPv6 link-local address (fe80::…) advertised by Aorus (avahi, it’s Linux).
And local router also resolves a plain Aorus name, since that goes through unicast DNS and avoids mDNS entirely.
dscacheutil queries on Aorus.local only IPv6 no IPv4 addresses returned:
Add the following configuration in .ssh/config file:
1 2 3
Host Aorus.local ConnectTimeout 10 User terrence
ConnectTimeout changes how ssh opens the socket. With no timeout set, ssh calls a plain blocking connect(). With a timeout, it switches the socket to non-blocking mode and waits for it with poll(). nc connects the non-blocking way too, which is why it worked all along.
So the evidence points to the blocking connect() to these mDNS-resolved IPv6 addresses failing on current macOS build, while the non-blocking path works. This could be a bug in this macOS build’s handling of mDNS-resolved scoped addresses, or something in the Local Network privacy layer.
Only the hostname path failed, because Aorus.local resolves to IPv6 addresses with an interface scope, and literals and the IPv4 name don’t hit that.
ConnectTimeout is harmless, since it just makes unreachable hosts fail after 10 seconds instead of the system default. It also covers scp, rsync and git over ssh.
Windows 11 Pro for Workstations 24H2, with Remote Desktop enabled, by running SystemPropertiesRemote.exe:
In addition, remote desktop login have been verified with Microsoft Account. Open Windows Powershell, and run with winver (Windows Version):
1 2 3
PS C:\Users\terre> runas /u:MicrosoftAccount\terrence.miao@paradise.net winver Enter the password for MicrosoftAccount\terrence.miao@paradise.net: Attempting to start winver as user "MicrosoftAccount\terrence.miao@paradise.net" ...
However, Windows App for Mac Error 0x4:
Error 0x204:
thrown when try to connect.
Clear the Windows App’s cached connection data on the Mac — this is the fix that repeatedly resolves this specific symptom (port open, still Error 0x204).
Quit Windows App, then in Finder go to ~/Library/Group Containers/, and delete the UBF8T346G9.com.microsoft.rdc folder.
Please enter your selection [0-28]: 20 1. Get SSL (Domain) 2. Revoke & Remove 3. Force Renew 4. Show Existing Domains 5. Set Cert paths for the panel 6. Get SSL for IP Address (6-day cert, auto-renews) 0. Back to Main Menu Choose an option: 1 acme.sh could not be found. we will install it [INF] Installing acme.sh... % Total % Received % Xferd Average Speed Time Time Time Current Dload Upload Total Spent Left Speed 100 270k 100 270k 0 0 1271k 0 --:--:-- --:--:-- --:--:-- 1277k [Thu Aug 27 09:10:20 AM AEST 2026] Installing from online archive. [Thu Aug 27 09:10:20 AM AEST 2026] Downloading https://github.com/acmesh-official/acme.sh/archive/master.tar.gz [Thu Aug 27 09:10:20 AM AEST 2026] Extracting master.tar.gz [Thu Aug 27 09:10:21 AM AEST 2026] Installing to /root/.acme.sh [Thu Aug 27 09:10:21 AM AEST 2026] Installed to /root/.acme.sh/acme.sh [Thu Aug 27 09:10:21 AM AEST 2026] Installing alias to '/root/.bashrc' [Thu Aug 27 09:10:21 AM AEST 2026] Close and reopen your terminal to start using acme.sh [Thu Aug 27 09:10:21 AM AEST 2026] Installing cron job [Thu Aug 27 09:10:21 AM AEST 2026] bash has been found. Changing the shebang to use bash as preferred. [Thu Aug 27 09:10:21 AM AEST 2026] OK [Thu Aug 27 09:10:21 AM AEST 2026] Install success! [INF] Installation of acme.sh succeeded. [INF] install socat succeed... Please enter your domain name: igloo-proxy.cloud-ip.cc [DEG] Your domain is: igloo-proxy.cloud-ip.cc, checking it... [INF] Your domain is ready for issuing certificates now... Please choose which port to use (default is 80): [INF] Will use port: 80 to issue certificates. Please make sure this port is open. [Thu Aug 27 09:11:29 AM AEST 2026] Changed default CA to: https://acme-v02.api.letsencrypt.org/directory [Thu Aug 27 09:11:30 AM AEST 2026] Using CA: https://acme-v02.api.letsencrypt.org/directory [Thu Aug 27 09:11:30 AM AEST 2026] Standalone mode. [Thu Aug 27 09:11:30 AM AEST 2026] Account key creation OK. [Thu Aug 27 09:11:30 AM AEST 2026] Registering account: https://acme-v02.api.letsencrypt.org/directory [Thu Aug 27 09:11:31 AM AEST 2026] Registered [Thu Aug 27 09:11:31 AM AEST 2026] ACCOUNT_THUMBPRINT='b5K6u4GCPMvP6jtVrI78pAl9YUrShU2Z8porK76hyr8' [Thu Aug 27 09:11:31 AM AEST 2026] Creating domain key [Thu Aug 27 09:11:31 AM AEST 2026] The domain key is here: /root/.acme.sh/igloo-proxy.cloud-ip.cc_ecc/igloo-proxy.cloud-ip.cc.key [Thu Aug 27 09:11:31 AM AEST 2026] Single domain='igloo-proxy.cloud-ip.cc' [Thu Aug 27 09:11:33 AM AEST 2026] Getting webroot for domain='igloo-proxy.cloud-ip.cc' [Thu Aug 27 09:11:33 AM AEST 2026] Verifying: igloo-proxy.cloud-ip.cc [Thu Aug 27 09:11:33 AM AEST 2026] Standalone mode server [Thu Aug 27 09:11:34 AM AEST 2026] Pending. The CA is processing your order, please wait. (1/30) [Thu Aug 27 09:11:38 AM AEST 2026] Pending. The CA is processing your order, please wait. (2/30) [Thu Aug 27 09:11:41 AM AEST 2026] Success [Thu Aug 27 09:11:41 AM AEST 2026] Verification finished, beginning signing. [Thu Aug 27 09:11:41 AM AEST 2026] Let's finalize the order. [Thu Aug 27 09:11:41 AM AEST 2026] Le_OrderFinalize='https://acme-v02.api.letsencrypt.org/acme/finalize/3489265815/549901388765' [Thu Aug 27 09:11:44 AM AEST 2026] Downloading cert. [Thu Aug 27 09:11:44 AM AEST 2026] Le_LinkCert='https://acme-v02.api.letsencrypt.org/acme/cert/06e0b6dbe51ac7d51573cf84994ca71741ad' [Thu Aug 27 09:11:44 AM AEST 2026] Cert success. -----BEGIN CERTIFICATE----- MIIDnzCCAyWgAwIBAgISBuC22+UZGNUVc8+EmUynF0GtMAoGCCqGSM49BAMDMDMx ... 2Ao/mUvkOPylsT42LE2vRnQCMBpDXfkcxsNWkiiWZxogKC6lahRpe7yz873EZLfE UUvAgAJ0INTMnqtKw15Eg8xyGw== -----END CERTIFICATE----- [Thu Aug 27 09:11:44 AM AEST 2026] Your cert is in: /root/.acme.sh/igloo-proxy.cloud-ip.cc_ecc/igloo-proxy.cloud-ip.cc.cer [Thu Aug 27 09:11:44 AM AEST 2026] Your cert key is in: /root/.acme.sh/igloo-proxy.cloud-ip.cc_ecc/igloo-proxy.cloud-ip.cc.key [Thu Aug 27 09:11:44 AM AEST 2026] The intermediate CA cert is in: /root/.acme.sh/igloo-proxy.cloud-ip.cc_ecc/ca.cer [Thu Aug 27 09:11:44 AM AEST 2026] And the full-chain cert is in: /root/.acme.sh/igloo-proxy.cloud-ip.cc_ecc/fullchain.cer [Thu Aug 27 09:11:45 AM AEST 2026] ARI suggestedWindow: 2026-10-25T00:57:16Z to 2026-10-26T20:08:06Z [Thu Aug 27 09:11:45 AM AEST 2026] Next renewal time picked from ARI window: 2026-10-26T07:45:41Z [INF] Your reloadcmd is: systemctl reload nginx ; x-ui restart [Thu Aug 27 09:14:30 AM AEST 2026] The domain 'igloo-proxy.cloud-ip.cc' seems to already have an ECC cert, let's use it. [Thu Aug 27 09:14:30 AM AEST 2026] Installing key to: /root/cert/igloo-proxy.cloud-ip.cc/privkey.pem [Thu Aug 27 09:14:30 AM AEST 2026] Installing full chain to: /root/cert/igloo-proxy.cloud-ip.cc/fullchain.pem [INF] Installing certificate succeeded, enabling auto renew... [Thu Aug 27 09:14:30 AM AEST 2026] Already up to date! [Thu Aug 27 09:14:30 AM AEST 2026] Upgrade successful! [INF] Auto renew succeeded, certificate details: cert/igloo-proxy.cloud-ip.cc: total 20K drwxr-xr-x 2 root root 4.0K Aug 27 09:14 . drwxr-xr-x 5 root root 4.0K Aug 27 09:11 .. -rw-r--r-- 1 root root 4.8K Aug 27 09:14 fullchain.pem -rw------- 1 root root 227 Aug 27 09:14 privkey.pem Would you like to set this certificate for the panel? (y/n): y set certificate public key success set certificate private key success set certificate for subscription public key success set certificate for subscription private key success [INF] Panel paths set for domain: igloo-proxy.cloud-ip.cc [INF] - Certificate File: /root/cert/igloo-proxy.cloud-ip.cc/fullchain.pem [INF] - Private Key File: /root/cert/igloo-proxy.cloud-ip.cc/privkey.pem
Get the Dynamic URL of domain igloo-proxy.cloud-ip.cc, then add cron job to update DNS Server with the Dynamic IP Address:
$ ssh -l root 192.168.8.1 ** WARNING: connection is not using a post-quantum key exchange algorithm. ** This session may be vulnerable to "store now, decrypt later" attacks. ** The server may need to be upgraded. See https://openssh.com/pq.html root@192.168.8.1's password:
_______ ________ __ | |.-----.-----.-----.| | | |.----.| |_ | - || _ | -__| || | | || _|| _| |_______|| __|_____|__|__||________||__| |____| |__| W I R E L E S S F R E E D O M ----------------------------------------------------- OpenWrt 21.02-SNAPSHOT, -----------------------------------------------------
$ lsusb | grep -i mediatek Bus 003 Device 002: ID 0e8d:7925 MediaTek Inc. Wireless_Device
$ rfkill list 0: hci0: Bluetooth Soft blocked: no Hard blocked: no 1: phy0: Wireless LAN Soft blocked: no Hard blocked: no
$ ls -al /lib/firmware/mediatek/mt7925/ ... -rw-r--r-- 1 root root 459528 Mar 19 23:32 BT_RAM_CODE_MT7925_1_1_hdr.bin.zst -rw-r--r-- 1 root root 197811 Mar 19 23:32 WIFI_MT7925_PATCH_MCU_1_1_hdr.bin.zst -rw-r--r-- 1 root root 1152702 Mar 19 23:32 WIFI_RAM_CODE_MT7925_1_1.bin.zst
MT7925 BlueTooth is usually exposed via USB (even though WiFi is PCIe).
1 2 3 4
$ dmesg | grep -i -E "bluetooth|mt7925|btmtk|firmware" ... Bluetooth: hci0: Failed to get device id (-108) [ 11.847463] ...
Failed to get device id (-108) is an ENOTUNIQ error from the USB/MMIO ID lookup in btusb/btmtk, often a known issue with MT7925 where the BlueTooth function doesn’t enumerate correctly or there’s a race during probe. This is a fairly common bug on MT7925 / 7925e cards on newer kernels.
The -108 error sometimes is caused by the BT USB device not being reset properly at boot. Try a full module reload in correct order:
1 2 3 4 5 6 7 8 9 10 11
$ sudo systemctl stop bluetooth
$ sudo lsof /dev/rfkill 2>/dev/null
$ sudo modprobe -r btusb $ sudo modprobe -r btmtk
$ sudo modprobe btmtk $ sudo modprobe btusb
$ sudo systemctl start bluetooth
Other like (-108) error:
1 2 3 4 5
$ dmesg | grep -i -E "bluetooth|mt7925|btmtk|firmware" ... Bluetooth: hci0: Failed to get fw version (-108) [ 8.050441] Bluetooth: hci0: HCI Enhanced Setup Synchronous Connection command is advertised, but not supported. ...
$ sudo hciconfig -a hci0 up Can't init device hci0: Connection timed out (110)
Fix it by Hardware Power Reset:
Often, MediaTek and other PCIe/USB combo cards get stuck in a low-power or un-responsive state that a simple reboot misses because power remains supplied to the motherboard.
Shut down your computer completely.
Unplug the power cable (and/or turn off the laptop and unplug the charger). Hold down the physical power button for 30 to 45 seconds to drain all residual charge from the system board.
Kilo Codedoesn't natively read **.github-based** Copilot skill/prompt/workflow/convention files — that format is specific toGitHub Copilot`’s custom instructions/prompts system.
Latest Ubuntu 26.04 LTS has dropped the support of X11 Server and xRDP and moved to the adoption of Wayland Display Server. Old approach with xRDP doesn’t work anymore. The solution / fix is the new Gnome Remote Desktop.
Generate Remote Desktop Server self-signed certificate:
NOTE: This is a well-documented, well-known incompatibility between Windows App on macOS and GNOME Remote Desktop’s “server redirection” handshake — not something specific to 26.04, and there’s a widely confirmed fix.
What’s actually happening: in “Remote Login” (system) mode, GNOME Remote Desktop doesn’t hand you straight into a session. It first accepts the connection, then sends an RDP Server Redirection PDU telling the client “reconnect, here’s the real session token” (that’s [RDP] Sending server redirection line — this part is normal and means auth succeeded). Windows App on Mac has a bug/quirk where it doesn’t follow that redirection properly by default, so it just logs off immediately — hence ERRINFO_LOGOFF_BY_USER right after.
Export the connection as an .rdp file
Edit the file to force redirection handling - Find the line use redirection server name:i:0 and change the 0 to a 1. This is the specific setting Windows App needs to correctly follow GNOME’s server-redirection handshake instead of dropping the session.
Delete old entry and import the edited .rdp file into Windows App
References
xRDP – Easy install xRDP on Ubuntu 22.04,24.04,25.10,26.04 (Script Version 1.6)- Maintenance Release https://c-nergy.be/blog/?p=20369
Extract data from the production tables and prepare JSON files for the test environment
1 2 3 4 5 6 7 8
for table in dashboard-tile-publisher-prod-group dashboard-tile-publisher-prod-tile dashboard-tile-publisher-prod-tile-event; do aws --profile production dynamodb scan \ --table-name $table \ --output json \ --max-items 10000 \ | jq --arg t "$table" '{ ($t): [ .Items[] | { "PutRequest": { "Item": . } } ] }' \ > $table.json done
Copy and modify the JSON files for the test environment
1 2 3 4
for suffix in group tile tile-event; do cp "dashboard-tile-publisher-prod-${suffix}.json" "dashboard-tile-publisher-ptest-${suffix}.json" sed -i '' "s/dashboard-tile-publisher-prod-${suffix}/dashboard-tile-publisher-ptest-${suffix}/g" "dashboard-tile-publisher-ptest-${suffix}.json" done
Update the content in the JSON files for the test environment
1 2 3
for suffix in tile tile-event; do sed -i '' 's/dashboard-tile-publisher-images-prod/dashboard-tile-publisher-images-ptest/g' "dashboard-tile-publisher-ptest-${suffix}.json" done
Import the modified JSON files into the test environment DynamoDB tables
1 2 3 4 5 6 7 8 9
for table in dashboard-tile-publisher-ptest-group dashboard-tile-publisher-ptest-tile dashboard-tile-publisher-ptest-tile-event; do jq -c --arg t "$table" '.[$t] | _nwise(25) | {($t): .}' "${table}.json" \ | while IFS='' read -r chunk; do aws --profile test dynamodb batch-write-item \ --no-cli-pager \ --request-items "$chunk"; \ sleep 10; # Add a small delay to avoid throttling done done
