最近 Asus Merlin 韌體停止支援我家 ASUS RT-66U_B1 了，因此決定改刷成 FreshTomato。

Merlin 韌體似乎會對上傳的韌體檔案做一些檢查，我如果直接上傳 Freshtomato 的 .trx 檔案會出現錯誤訊息說韌體錯誤。

因此再來我改用 TFTP 模式嘗試刷進去，但似乎也失敗了，我看它一直循環重開機。

幸好這款是用 Broadcom 的 SOC，有內建 CFE webserver，基本上就是回復模式，使用有線網路設定一個固定 IP 192.168.1.x 就可以連上 192.168.1.1 的 CFE webserver。

使用 CFE webserver 上傳 freshtomato 的 trx 之後就成功刷入了。

刷完之後馬上來測速，發現 WAN 端被限制在 330 Mbps 左右，發現是 Cut-through forwarding 沒開，開了就可以吃到 ISP 的 500Mbps。

刷完雖然也是可以用，但換換病有點發作，忍不住好奇現在最新的 802.11ax AP 速度可以到多快。目前這台速度只到 802.11ac 的 AC1750。

802.11ac Wifi 5 AC1750

讀完維基百科，瞭解到 AC1750 是 2.4GHz 450Mbps 加上 5GHz 1300 Mbps。而且沒有任何一個單一裝置可以吃到全部 1750Mbps 的頻寬，是所有裝置同時連線的吞吐量可以達到 1750Mbps。

然後 5GHz 1300 Mbps 是由 3 streams @ MCS 9 組成。MCS 是 Modulation and Coding Scheme，每個不同的 MCS 對應到不同的 modulation type (xxx-QAM) 和 coding rate 也就是 有用資料率 ÷ (有用資料率+錯誤糾正碼率)。這順便複習了我以前學過的網路通訊原理。

3 streams @ MCS 9 意思就是最多可以有 3 個並行的 MCS 9 通道（不確定 ac 下同一個 client 是否可以使用超過一個 stream，但 ax 可以），MCS 9 的編碼組合在 80MHz 的頻寬下（暫時不研究 GI）可以跑到 433 Mbps 的理論速率。

使用筆電的 Intel AX210 Wifi 6 網卡（應該支援所有較慢的 Wifi 5 802.11ac 速率），iperf3 測出 270 Mbps 的實際速度（距離天線 1 公尺，沒有遮蔽物）。這樣看起來似乎是只有一個 stream。

802.11ax Wifi 6

測了另一臺友人的 Wifi 6 AP, 據 iw dev wlan0 station dump 的資料：

rx bitrate: 1080.6 MBit/s 80MHz HE-MCS 10 HE-NSS 2 HE-GI 0 HE-DCM 0

距離天線約 5 公尺，有一道牆加一道木門。這邊顯示使用的是 MCS 10，NSS 是2，這應該是有 2 個 spatial stream 的意思。

實測 iperf3 是 450 Mbps。

然後 Wifi 6 是可以結合 2.4 GHz 和 5 GHz 的 stream 的（wifi 5 不行），但此 AP 是分開不同的 SSID 所以這功能沒有啟動。

結論

好像沒有比想像中快很多，我以為可以快個 2~3 倍吧（雖然說測試環境障礙也不一樣啦）。換換病症狀暫時好了一些。不過在拍賣網站看到一台二手支援 OpenWRT 的 Linksys AP 好便宜啊啊啊。

其他筆記

• OpenWRT 目前還沒有正式支援 Qualcomm 的 NSS 加速功能，所以速度可能比不上原廠韌體

一年前，大約 2020 年購入的 Razor Ornata v2 鍵盤的部分按鍵變得無法感應，但覺得不想製造那麼多垃圾，於是決定嘗試自行維修。

這鍵盤平常是接在遊戲用桌機上面，平均每個禮拜的使用時數不超過 6 小時，沒想到才不到五年就壞掉了，可見這品質有多爛。至於當時為什麼會買？因為平常主力工作機是 Thinkpad，打習慣筆電的淺鍵盤了，覺得普通的桌機鍵盤太深沒有那麼順手，但普通巧克力鍵盤的觸感和回饋又太差，最後才找到 Ornata 這款短鍵程、觸感和回饋均佳的鍵盤。這款是薄膜鍵盤，但是按鍵的支撐是使用特別的立體橡膠膜，可以製造出類似機械式鍵盤的手感。

導電漆

差點買了 Bare Conductive，但仔細研究發現他官網有寫，Bare Conductive 的阻抗仍然高於銀漆（懶得找來源，但可能是這頁），畢竟他還是石墨為基礎的，不是金屬，但相較於金屬漆，有其他優勢。

然後嘗試了電子材料行買的銀漆，但他的銀漆是裝在針筒裡面，要很用力才能擠出來，讓我根本沒辦法在鍵盤薄膜上面精細畫線，因為沒辦法在用力壓針筒的時候瞄準，很容易就會碰到其他不該碰的線路。

最後去今華電子買了導電銀漆筆：

使用電錶尋找斷點

我自己想出幾個比較快速的方法。

因為導線比較細，所以每次要將測針對準、按在導線上其實比較慢。我想出這個方法：

1. 左手測針按 [1]，右手測針按 [2]
2. 左手測針移至 [3]，右手測針不動，聽電錶是否嗶嗶叫指示通路
3. 左手不動，右手測針移至 [4]，聽電錶

如此一來就可以快速判斷斷點位置。

然後，如果有一排導線平行，要用眼睛跟著導線再用手拿探針瞄準導線也需要花上比較多時間。但其實可以：

1. 左手測針按 [2]，右手測針照黃色路徑劃過，聽是否嗶嗶叫指示通路

這樣就省去瞄準的時間。

斷點？原來只是三用電錶通路標準不一樣

用這個方法一開始發現了很多斷點，我就興高采烈地把斷點補起來，其中有許多段的導線和其他導線距離太近 (1mm) ，銀漆筆又比較粗（2mm），所以我就用紙膠帶當 masking tape 才避免畫到臨近的導線。

折騰了一番，似乎把大部分線都補好了，但我意識到事情不太對勁，用電錶的時候，有些導線雖然沒有發出嗶聲指示通路，但他的電阻值顯示的是 50~150 ohm （我不確定電錶的單位是什麼但應該是歐姆），和真正完全的斷路顯示的 -- 不太一樣。

所以我猜測，其實 150 ohm 對鍵盤來說也是通路（我缺乏電學常識）？稍早白費心力了。

是 FPC 接頭的問題

原本以為的斷點其實原來都是通路，這下要重新尋找斷點。

四處測了半天，都是通的，才想到測試 PCB 板上面的針腳——發現有些斷路！

但 PCB 上面的針腳都是固態金屬線，不太可能斷吧？

仔細研究了電路薄膜，意識到我其實沒有測過薄膜插入 FPC 接頭的凸出部位接點，一測果然發現斷路在此！

用銀漆補畫了幾條導線（使用紙膠帶當 masking tape），最後測試確認修好了！！

又壞了

用了一陣子之後，有些按鍵開始黏在一起，Q+A , W+S 等上下相鄰排的按鍵會被同時觸發。

型號這個修補算是簡單：仔細檢查了之前在薄膜 FPC 接點上面畫的線，有其中兩條因為畫的銀漆太厚，擠壓後扁掉，接在一起了。用尖銳的鑷子把中間的銀漆劃開，就完成了維修。

結論：下次還是不要買雷蛇

目前找了很久還沒找到心目中下一隻想要的鍵盤，因為我想要一個特殊的排列，覺得很奇怪為什麼沒有廠商做：

• 不要 numpad，太少用
• 要有獨立 function key 和 media key，因為很多程式開發工具需要按 function key，獨立的話就不需要記一堆組合鍵，可能是開始用電腦的年代就習慣用 function key 了，現在 function key 幾乎都要用 Fn 組合出來，實在很不習慣（我知道有 Fn lock 這功能，但開了 Fn lock 我就不能一鍵調音量和亮度和下一首啦）
  • 到現在我還是覺得有些按鍵感覺不太自然：
    • 重新整理是 Ctrl+R 而不是 F5
    • 關閉視窗是 Alt+F4 最自然, 沒有 F4 的快捷鍵我根本記不得
    • 全螢幕是 F11，沒有 F11 的快捷鍵我根本記不得
    • vim paste mode 切換是 Ctrl+H 而不是 F2
• 要有 ScrollLock PrintScr, Home, End, PageUp, PageDown
• 要有旋鈕可以調音量或是自定義
• 獨立媒體鍵超級重要，每一個功能我都覺得重要到不應該要按組合鍵：音量大小、靜音、麥克風、螢幕亮度大小、鍵盤亮度大小、上一首、暫停、下一首

好，現在覺得最適合我的鍵盤其實是 Dell Business Keyboard 哈哈哈哈，但他還是有 numpad 而且只是個不舒服的薄膜鍵盤。

為什麼沒有機械式鍵盤廠商出這種排列啊？

記錄一下我的 RSS 全系統，從產生饋流到閱讀器。原則：盡量不花錢。

用爬蟲產生饋流

很多網站沒有提供饋流，所以就要用額外的爬蟲去產生。

這方面最有名的大概屬 RSSHub，不過我其實要反推它，雖然看起來是支援很多網站沒錯，但當中大半無法正常運作，也並沒有很多貢獻者去修復爬蟲，所以很多網站的爬蟲壞了半年一年也都沒有修復。雖然架設起來輕鬆方便但實在沒有它所聲稱的那麼美好。

類似 RSSHub 的還有 rss-bridge，我以前有使用但很多年沒有再使用了，不確定現在的狀況如何，我覺得受限於他的 PHP 架構，要跑一些比較有彈性的爬蟲會很麻煩，比如說如果要做一些背景定期任務，或是要起一個 headless browser 之類的都會很麻煩。

我強烈推薦 rss-proxy，他厲害的地方在於是用一個演算法分析網頁的 HTML 結構，自動抓出文章清單，幾乎適用於任何網站，都可以抓出文章清單、標題，甚至是預覽圖。它也提供一個非常讚的網頁介面可以輕鬆選擇不同演算法產出的文章清單候選，選擇一個候選項，它還會再網頁截圖上標示抓到的文章清單給你看。如此可以輕輕鬆鬆產出饋流，不用自己寫爬蟲。

rss-proxy 是純靜態的爬蟲，作者還有做了另一個進階版的，內嵌瀏覽器的爬蟲，支援 Javascript：feedless。

除此之外，還有幾個方案：

• Fetchrss.com：免費的帳號可以建立最多5個饋流
• hnapp.com: 可以產生 Hacker News 的饋流，而且可以訂閱特定用戶的留言或是貼文，我發現有時候找到厲害的人，訂閱他們的留言，也可以學到不少

針對 Facebook，我自己寫了一個很髒的基於他們 GraphQL API 的靜態爬蟲，可以爬粉絲專頁和公開的社團。Instagram 則使用 Bibliogram 裡面內建的 RSS 產生器功能，雖然 Bibliogram 上游已停止維護一年以上了，但大部分的功能仍可以正常運作。

繞過反爬蟲 / IP 限流

Facebook 和 Instagram 有非常嚴格的反爬蟲機制，我想應該是有做一些 browser fingerprinting，但到頭來發現，其實還是 IP 聲譽佔最大影響。

最簡單的測試方法就是拿普通瀏覽器掛上不同 IP，看 Facebook 會給你什麼資料，我觀察有兩種可能：

1. 顯示部分內容，覆蓋一個登入對話框，這個就可以用爬蟲拿到覆蓋底下的資料
2. 直接重新導向至登入網址，這樣爬蟲什麼資料都拿不到

以前即使是拿雲端主機的 IP 去請求 Facebook 都會拿到結果一，數個請求過後才會拿到結果二。但最近雲端主機的 IP 已經不管用了，會直接回結果二。所以就要真的拿固網 IP 來使用才拿得到內容。

彙整

主要是使用 Inoreader，但我只用比較便宜的方案所以有限制500個饋流數量，而且 Inoreader 的 app 有幾個不足的地方：

• 介面美觀不如其他閱讀器 app
  • 動畫讓人感覺有點陽春的感覺
  • 整體介面感覺沒有那麼原生
• 對於只提供摘要的文章來說，沒辦法自動載入全文，一定要打開瀏覽器閱讀
• 比較貴的方案才有離線功能
• Inoreader 服務本身沒有動態 OPML 的功能，只能一次性匯入 OPML

倒是我覺得 Inoreader 網頁版就蠻不錯。

當初一開始其實是因為不想要自己架 RSS 相關的軟體，加上 Android 上面並沒有介面美觀功能齊全的 RSS 閱讀器（付費的我也沒找到），才選擇付費使用 Inoreader，不過現在訂閱的數量已經超過 Inoreader 500 的限制，所以今年還是開始自己架起來 FreshRSS。

因為 FreshRSS 網頁版的閱讀器我覺得還不如 Inoreader 美觀，而且萬一 FreshRSS 壞掉，我不太想要花太多時間維護這軟體，所以目前大概是這樣區分：

1. 主要會閱讀的消息來源、資訊量比較多的消息來源放在 Inoreader
2. 其他比較不重要，偏娛樂性質或是瞄過即可的消息來源放在 FreshRSS，壞掉的話也就不太影響

閱讀器

Capy reader

開源的 Android RSS 閱讀器，介面基本簡潔，功能也非常基本，但至少有 FreshRSS 同步功能。

在這之前我使用 Read You，也是開源的但沒有同步功能。

NetNewsWire, Reeder Classic

主要是在 iPad 上面使用這兩個，Reeder Classic 本來要錢但我某次拿到限時免費。

這兩個 app 就是我覺得目前 RSS 閱讀程式的頂點了，介面設計美觀、平台同步等各種功能齊全。

最近偏愛 NetNewsWire 更多一點，因為它是開源的。NetNewsWire 有個我最喜歡的功能是一個按鈕就可以載入全文，因為我使用的是很舊的 ipad 所以如果要看全文要打開瀏覽器的話要等很久。不知道這功能是如何實作的但我猜可能是簡單的靜態 HTTP 請求和解析器吧，因為有時候這全文解析出來的和網頁的內容還是有些不同，但大部分狀況下這樣也夠用了。

FreshRSS

比較不重要的饋流我放在 FreshRSS，客戶端使用 Capy Reader 閱讀。

架設起來相當簡單，就是一個簡單的 PHP 網頁程式。

FreshRSS 有個功能我很喜歡：動態 OPML。簡單來說 OPML 就是 RSS 饋流的清單，FreshRSS 可以訂閱一個 OPML 網址，啟用動態 OPML 的話，網址內的 OPML 如果增加了新的饋流，FreshRSS 也會自動訂閱。我的 Facebook RSS 爬蟲會讀一個粉專 ID 的清單，然後產出一系列的 RSS XML 檔案，同時我拿這個 ID 清單拿去產生 OPML，讓 freshrss 去訂閱，這樣若要追蹤新的粉專，只要去清單內增加 ID 就好了。

遺珠

Feedbin

是個付費服務，網頁版看起來不錯，介面美觀功能齊全，不幸的是沒有專屬的 Android app，所以在 Android 上面的閱讀體驗不佳，不過現在有了 Capy Reader 所以應該好很多。

另外 Feedbin 也有開源程式碼（似乎只有部分），但他部件很多，也沒有很好的說明讓你跟著自架，再加上它是 Ruby 寫的，如果出錯或是要改程式碼的話我不熟悉，會很麻煩。之前也嘗試自架過一次，但說明實在太缺乏了問題一堆，我也不會 Ruby。所以最後放棄。

Omnivore

後來才發現的閱讀器，主打功能是有很棒的文字轉語音產生器，是真的蠻厲害，這樣長篇文章就可以用聽的了。不過發現它過沒多久就被併購然後下架了。

Omnivore 被併購後的公司有提供一個 ElevenReader，但它的 Android app 產生語音時一直產生錯誤，無法使用。後來我好奇去拆開它看一下流量發現是有 Play Integrity API，所以有 root 的手機都過不了。它完全沒有提示，很爛。

結語

一個人所吸收的資訊會決定他的想法，因此控制自己所吸收的資訊，而不是被推薦演算法控制，對於培養思考和增廣見聞來說非常重要。這也是為什麼我決定花這麼多時間搞一整套 RSS 的資訊訂閱和閱讀系統。

Spotify snap 似乎不再提供 MPRIS 的功能，讓我無法用媒體按鍵控制他，這功能似乎已經壞掉一陣子，但我一直懶得檢查到底是哪裡壞掉，只記得以前應該是有這個功能的。官方只提供 snap 和 deb 兩種格式的套件而已，但想一想裝來路不明的 flatpak 的風險應該還是低於安裝來源已知但是閉源的 deb 檔，所以決定還是用 flatpak 安裝。

flatpak 安裝後確認有 MPRIS：

確認可以使用媒體按鍵。

然後我又發現中文輸入 (fcitx) 壞掉了，不過以前我在 snap 版本修過一次這個問題，修 flatpak 應該如法炮製就可以了。

首先去 ~/.local/share/applications 裡面把 .desktop 檔案複製一份目前使用者可以編輯的版本，原始他是個 symlink 到 /var 裡面，不能編輯。

cd  ~/.local/share/applications
rm com.spotify.Client.desktop
cp /var/lib/flatpak/app/com.spotify.Client/current/active/export/share/applications/com.spotify.Client.desktop .

接下來把 Exec= 開頭那行改成這樣：

Exec=/usr/bin/flatpak run --branch=stable --arch=x86_64 --command=spotify --file-forwarding com.spotify.Client --enable-features=UseOzonePlatform --ozone-platform=wayland --enable-wayland-ime @@u %U @@

然後我發現還是不能開，發現是因為這個 flatpak 套件是使用 X11 模式。

使用 Flatseal 編輯 spotify flatpak 的權限，授予 Wayland 權限，啟動的時候應該就會自動使用 Wayland。

改完就成功啦！

相關設定

另外還有個相關設定可能需要調整：Firefox 和 Chromium 等瀏覽器播放媒體的時候預設也會註冊 MPRIS ，因此媒體按鍵就會變成控制瀏覽器的媒體而不是 spotify，只要去 Firefox 設定裡面把「使用鍵盤、耳機或虛擬介面控制媒體內容播放行為 (V)」關掉就可以了。

還有，Spotify 應用程式登入的時候要開啟瀏覽器，如果沒有設定預設瀏覽器的話會沒有反應。我是使用 firefox-deflector 讓我可以選擇不同的 profile 來開啟連結。

小米溫度計要使用的話預設得要搭配小米的手機應用程式，要使用這個應用程式得要註冊小米芭樂帳號，因此我當然不會使用。但這樣要用手機或是電腦看溫度就很麻煩，而且也沒辦法看溫度紀錄。

後來發現超讚的第三方韌體，用 Chromium 透過 WebBluetooth 功能，使用他提供的 OTA 網頁程式，很輕鬆就可以將溫度計刷上他的第三方韌體。就再也不需要使用小米芭樂app。

開心使用了一陣子，某天回想起我之前看到的 OpenHayStack 專案，Openhaystack 是個開源的 Apple Airtag 實作，讓任何 BLE 裝置可以變成一個 Airtag 被追蹤。我靈機一動，小米溫度計不也是 BLE？那不就可以把它變成一個 airtag 了！小米溫度計在台灣只賣 $135 ，比 Apple airtag 便宜多了。傳統上 Openhaystack 是設計給 ESP32 之類的藍牙開發板刷的，但如果真的要把這類開發板當成 airtag 使用，那一個方便的外殼和長效的電池就很重要，這個是一般 ESP32 開發板出廠沒有提供的。但如果使用小米溫度計的話就完美地解決了這個問題。於是我開始進行研究。

OpenHayStack 的 airtag 實作

Openhaystack 原始碼裡面目前提供 ESP32, Microbit 和 Linux HCI 的 airtag 實作，我看了很開心，就開始研究怎麼把這個實作移植到 ATC_MiThermometer 韌體上面，看來似乎主要需要修改 ble.c 。

Openhaystack 的實作意外地非常簡單，只有設定一個固定的廣播資料，也就是 key 而已。這個 key 是需要透過他們的程式來產生。

我看到一半準備開始移植的時候，想一想不對，我記得 Openhaystack 的論文裡面說到為了避免單一 airtag 被追蹤，airtag 廣播的 key 和 mac address 都會隨著時間改變。這就和我上面看到的實作只用固定 key 不一樣。仔細一看才發現 Openhaystack README.md 裡面寫著這些都只是 proof-of-concept 因此只會廣播固定 key。我心涼了一半，這就表示如果使用 openhaystack 的實作那麼雖然我可以追蹤這個裝置但其他任何人只要收的到這個裝置的廣播也都可以追蹤，顯然有巨大的隱私風險。

Openhaystack 的開發者有說想要開發完整的 rolling key 廣播實作但是不知道需要多久。目前也沒看到任何開發中的跡象。

其他 airtag 實作

於是我重新看了逆向 Apple FindMy 協定和實作 openhaystack 原始的論文，發現 airtag 廣播的 key derivation 是透過一連串的橢圓曲線公私鑰演算法來演算出隨著時間變化的 key。這個以我目前的嵌入式平台開發能力應該是辦不到。

我再找到了其他 airtag 的實作，主要有二：

1. GitHub – dakhnod/FakeTag: firmware for nRF51 chips that is coincidentally compatible with the FindMy (AirTag) ecosystem (https://github.com/dakhnod/FakeTag)
2. GitHub – biemster/FindMy: Query Apple’s Find My network (https://github.com/biemster/FindMy)

這兩個專案都支援廣播 rolling key，但他們其實都沒有實作上面提到的那個 key derivation 演算法，都用了一個很天才的方法繞過：先在電腦上產生好所有未來要使用的 key，然後 hard code 進韌體裡面，再刷進去就好啦，這樣就不需要在嵌入式硬體上面做橢圓曲線公私鑰運算了。

至於在電腦上如何預先演算這些 key？實作在 generate_keys.py 內。

我其實也有點懷疑這個 key generator 真的和 apple 使用的演算法相同。不過似乎 key derivation 演算法即使沒有和 apple 官方的實作完全相同應該也仍然可以使用 FindMy 網路，因為 FakeTag 的作者有提到他使用了自己的私有演算法，而且原始 Openhaystack 則根本是使用固定 key，所以很可能蘋果的伺服器其實不在意資料是怎樣加密的。

這倒是也蠻合理的，因為蘋果 FindMy 協定的設計是伺服器接受的是公鑰加密後的地理位置資料，而私鑰僅有 airtag 擁有者才擁有，所以伺服器無法解密任何上傳的內容，所以內容是啥對伺服器其實不重要。重要的是 airtag 擁有者必須要知道該跟伺服器下載哪一個編號的加密地理位置資料，這個只要客戶端實作正確應該就可以正常算出來。

想到這點就想到之前看到的另一個專案 send-my，就正是利用 Apple Findmy 伺服器可以接受任意藍牙資料的特性來做一個 data exfiltration 的概念驗證。

除此之外我還發現 micro-ecc，是個在嵌入式環境內實作橢圓曲線演算法的函式庫，如果未來我有時間的話可以考慮把這個整合進我寫的小米溫度計韌體。

Roadmap

釐清完技術細節，就可以列出實作里程碑了：

1. 自行編譯未修改的 ATC_MiThermometer 的韌體刷入
2. 修改韌體加入廣播固定 key 的功能
3. 測試 biemster/FindMy 專案提供的程式來註冊修改後的小米溫度計，嘗試下載地理定位資料
4. 修改韌體加入儲存一系列 key 並輪流廣播的功能，並測試下載資料
5. 若有時間的話，整合 micro-ecc