Tag: workaround

VirtualBox 內的 Windows 上傳速度很慢的問題

因為我電腦有兩張網卡，兩條線分別接到自己拉的 HiNet 以及社區網路 (不過出去也是 HiNet，這是另外一回事了)。

我桌機的預設 routing 是走自己拉的 HiNet，但我希望 VM 是走社區網路，所以用 bridge mode 設定到網卡上，用 DHCP 取得分享器給的 private IP。

之前一直都沒注意到，前幾天用 Line 傳照片的時候很慢 (之前就有發生了，一直忘記去追問題)，花了點時間追問題的時候發現是 VM 裡面的 Windows 10 上傳很慢，這點可以從 Speedtest 的測試結果看到：

先講最後的結論，在交叉測了很多組合後，我發現遇到的問題是把網卡裡的 Large Send Offload (IPv4) (也就是 LSO) 從 Enabled 改成 Disabled：

回到當時抓問題的情況，當時先用筆電與 host 測試都沒看到問題，所以看起來應該是 VM 裡面的狀況，但不確定是什麼情況，畢竟不是斷掉...

由於下載速度正常，只有上傳速度卡住，一開始想到的是跟 MTU 相關的問題，所以找了指令降到 1400 後測試，還是一樣...

後來先把 VM 的網路改成 NAT，再測試上傳速度就正常了...

接著想要換個網路卡類型看看，結果卡在找不到 driver。

本來已經想拿 tcpdump 出來追了，但想說先去看看 Windows 10 網卡設定裡面的設定，結果看到 LSO... 就先關看看 (算是以前在 FreeBSD 以及 Linux 下的經驗？)。

然後一關就正常了，交叉再開關兩次確認這個參數有影響，就肯定這個 workaround 應該是有效了...

另外在自己找完問題後，在「Virtualbox 7.0.12 slow upload speed in any Guest OS」這邊看到了類似的問題以及同樣的 workaround。

LSO 過了十幾年還是...

Firefox 與 Chrome 處理 Intermediate CA 的不同方式

在 Fediverse 上看到「The recording of my "Browsers biggest TLS Mistake" lightning talk at #37C3」這個，這是出自 37C3 的 lightning talk，影片不長，只有五分鐘，可以在「Browsers biggest TLS mistake」這邊看到。

正常的 HTTPS server 會送出 Intermediate CA certificate 與自己的 TLS certificate：

當伺服器端沒有設定好，通常是只送出自己的 TLS certificate：

這種情況在 Firefox 裡有處理，軟體本身會預載所有的 Intermediate CA 避免這種問題 (當然會需要跟著軟體更新)，這點在三年前有提到過：「Firefox 試著透過預載 Intermediate CA 降低連線錯誤發生的機率？」，也就是這張投影片提到的情況：

而 Chrome 則是去看目前的 cache 資料，找看看是不是在其他地方有看到適合的 Intermediate CA 可以接起來：

這好像可以解釋為什麼之前遇到類似的問題的時候，在 Chrome 上面會需要進 chrome:// 裡面清東西才能重製...

JavaScript 的分號，以及 ASI (Automatic Semicolon Insertion)

目前 community 的主流跟我理出來的期望不一樣... 所以記錄一下。

先提一下背景，在 JavaScript 程式語言裡面，在大多數的情境下是可以省略掉分號 (;) 的，也就是說這兩種寫法都是合法的 JavaScript 語法：

console.log('Hello, world.')
console.log('Hello, world.');

這是因為在 ECMA-262 裡面有 ASI (Automatic Semicolon Insertion) 的設計：「Automatic Semicolon Insertion」。

ASI 設計本身是好的，可以讓開發者少處理 ;，但偏偏 EMCA-262 又允許千變萬化的換行，於是就造成了各種奇怪的現象。

因此早期在 community 上都是推薦無條件加上分號，這可以避免各種奇怪的 bug 與 error，像是「Do you recommend using semicolons after every statement in JavaScript?」以及「Should I use semicolons in JavaScript?」這些問答。

大家會推薦加上分號主要的原因是因為，不加上分號遇到的 error 與 bug 不是那種你知道很雷，所以會主動查詢 & 避開的問題：

而是各種平常寫就會遇到的情況，最容易中獎的是第二組敘述是 (、[ 開頭的，像是 ECMA-262 文件裡面提到的 case 就算常見了：

a = b + c
(d + e).print()

// 等價於：
a = b + c(d + e).print();

而且不因為註解受到影響：

// blahblah
a = b + c

// blahblah
(d + e).print()

// 還是等價於：
a = b + c(d + e).print();

另外一個常見的情況是我們會利用 anonymous function 包出一個 block，避免變數污染到外面：

// I want to do blahblahblah...
(() => {
  const a = '';
  // ...
})()

// I want to do another blahblahblah...
(() => {
  const a = '';
  // ...
})()

大多數的情況應該會 error，除非第一個 anonymous function 傳回一個 callable，而這種情況跑出來的結果就更慘了...

另外這種 case 也是常見的情況：

// ...
[1, 2, 3].forEach(...)

// ...
[4, 5, 6].forEach(...)

// 等價於：
[1, 2, 3].forEach(...)[4, 5, 6].forEach(...)

這邊省略分號最大的問題是你無法知道「自己這行需不需要加上分號」，因為註解可能很長有個 30 行，所以依照這些現況，比較好的方法應該是全部加上分號，保持一致性。

但這幾年所有的 frontend framework 都是推動拿掉分號，這可以從各家的文件看到，就搞不懂 community 是怎麼推導出來的... 在全部都拿掉分號的情況下，遇到上面的情況就得寫成不一致的 style：

// ...
[1, 2, 3].forEach(...);

// ...
[4, 5, 6].forEach(...)

查了目前可行的 workaround，大多都是透過 ESLint 類的工具來擋可能會出現 bug 的地方，也只能先這樣做了...

Firefox 的 :has() 支援度問題

在 Can I Use... 上面的「:has() CSS relational pseudo-class」裡面可以看到 Firefox 一直都還沒支援，只有在 nightly 版本上面預設有開，這也代表還沒辦法很穩定的用這個 selector... (除非你直接忽略掉 Firefox)。

看到「Prodding Firefox to Update :has() Selection」這篇，Eric Meyer 在抱怨 Firefox 的這個問題，就算是 nightly 的版本也還是有奇怪的 bug，會抓不到 :has() 條件，需要用 contenteditable 的 workaround 觸發 Firefox 的計算。

在 Mozilla 的 Bugzilla 上可以看到票還開著：「Implement the :has() pseudo class」，看起來這陣子是一直有在更新，應該是有資源在上面追進度。

等到真的支援，就可以在 querySelectorAll() 裡面直接用 :has() 了，現在 Firefox 的情況讓 Userscript 寫起來有點卡...

幾個其他 Teams 的替代方案 (但還是連到 Teams 伺服器)

這邊講的替代方案不是換掉 Teams，而是找其他的方法連上 Teams 伺服器，畢竟用 Teams 的人大多都沒得選...

在「Teams is killing my Mac every day (microsoft.com)」這邊看到的一些資料可以嘗試，裡面有很多抱怨 Teams 的問題，但還是有些人有給出一些 workaround。

大家主要遇到的問題除了 CPU 吃很兇以外，另外就是記憶體這塊。

一種方法是是用 Edge 瀏覽器的 extension 來跑，我本來想看看 Linux 上的 Brave 能不能裝，但沒有看到對應的安裝連結，大概是 Edge 限定：

If you don't want to use the Microsoft Teams app (which uses a lot of resources), you can:

1. Install the Microsoft Edge Web browser on your Mac

2. Log into https://teams.microsoft.com

3. Click ... > Apps > Install this site as an app

This will create an Edge app for Teams that uses almost no resources but has feature parity with the regular Microsoft Teams app.

We tell all of our students to do this, and it has solved all Microsoft Teams performance issues on student Macs (both Intel and Apple Silicon).

另外有人提到其實官方是有放 M1 的 preview 版本的，雖然不是正式版，但總是比 Intel 版本會好一些：

If you're running an Apple Silicon Mac you can get an early build of Teams osx-arm64 from the exploration build link listed here.[0]

I've been running a daily build for a few weeks and it's noticeably better than the Intel build on an M1 Pro. It launches in half the time and feels far more responsive (probably due to not needing to use the Rosetta JIT for Electron). That said it's still a daily "exploration" build so YMMV.

[0] https://raw.githubusercontent.com/ItzLevvie/MicrosoftTeams-msinternal/master/defconfig

據說會少吃一點點記憶體，就真的大概一點點：

Can confirm it is snappier on a M1 Macbook Pro and using *less* RAM, maybe about 10% less.

但據說這個 preview 版本在自我更新時會跳到 Intel 版本，還要再找一下 workaround 關掉自動更新：

How do you prevent it from automatically updating to the Intel version? I keep downloading the preview builds and they keep getting updated.

後面還有看到有人說他直接實體隔離，把這些肥滋滋的 app 跑在另外一台 Mac 上，然後透過 Universal Control 使用，大多數的情況下都夠用，真的有需要分享畫面時再跑在自己機器上，用完就可以關掉：

Thanks for the tip. I'll give this a try!

For work, I have to run Microsoft Teams, Slack, and Discord. Of those 3, Slack surprisingly uses the least amount of memory (~700 MB), and Teams uses the most (~1.5 GB). I dusted off an old Intel Mac (literally) and interact with it using Universal Control. It only runs those 3 chat apps + mail. It's turned out to be a great way to offload resource hogs and as an added benefit, it minimizes distractions. I'll occasionally glance at the dock to see if there are any notification badges, whereas on my main Mac, I'd feel compelled to deal with notifications immediately.

When I have to share my screen or focus on a conversation, I'll fire up one of those 3 apps on my main (M1) Mac and quit it when I'm done.

Universal Control still feels rough around the edges, but it has saved me from ditching my Macbook Air and shelling out for an M1 Macbook Pro. Sometimes there are issues with reconnecting to the Intel Mac, but it seems to resolve itself if I wait a bit or turn off/on wifi.

大家都在找方法 XDDD

修正 Curl 的 TLS handshake，避開 bot 偵測機制

利用 TLS handshake 的 pattern 可以當作是某種 fingerprint，就可以知道你是用 Curl，這個方式在蠻多 CDN 都會用在 anti-bot 機制 (像是 Cloudflare)，而剛剛看到有人投稿自己的 patch，試著將 Curl 修改成 Firefox 的 pattern：「curl-impersonate」，Hacker News 上的討論在這邊可以看到：「Show HN: Curl modified to impersonate Firefox and mimic its TLS handshake (github.com/lwthiker)」。

作者有提到這次的 patch 偏 hack，不太可能整進上游，但希望未來改的乾淨一點，然後整進上游：

I hope to do so in the future, for now the implementation is extremely hacky so I doubt it can get accepted into curl.

另外有人提出來說應該要用 Firefox ESR 版本的 pattern 而非 stable channel，也有人提出來說用 Google Chrome 的更好，不過我覺得有人開始做就已經很棒了 XD

在非 4K 的螢幕上跑 HiDPI

前幾天看到 BetterDummy 這個專案，作者在 M1 上面外接 24" 1440p 的螢幕，但沒辦法啟用 HiDPI，於是就寫了一個軟體來解：

M1 macs tend to have issues with custom resolutions. Notoriously they don't allow sub-4K resolution displays to have HiDPI ("Retina") resolutions even though (for example) a 24" QHD 1440p display would greatly benefit from having an 1920x1080 HiDPI "Retina" mode.

在這之前的解法都有些麻煩，一種是買個 dummy dongle 去騙 macOS，另外是用 mirror 的方式使用：

To fix this issue, some resort to buying a 4K HDMI dummy dongle to fool macOS into thinking that a 4K display is connected and then mirror the contents of this dummy display to their actual monitor in order to have HiDPI resolutions available. Others use the built in screens of their MacBooks to mirror to the external display. These approaches have obvious drawbacks and cannot solve all problems.

作者提供的軟體可以先建立 Dummy Monitor，然後再透過 mirror 掛到實際螢幕上：

不確定用起來如何，但如果之後有需要的話好像可以測試看看...

OpenSSL 1.0.2 與 Let's Encrypt 在這個月月底的相容性問題

看到 OpenSSL 的官方居然特地寫一篇與 Let's Encrypt 的相容性問題：「Old Let’s Encrypt Root Certificate Expiration and OpenSSL 1.0.2」。

這邊提到的 OpenSSL 1.0.2 很舊了 (在 Ubuntu 16.04 內是 1.0.2g)，理論上大多數的機器應該不太會遇到這個問題。

問題出自 Let's Encrypt 舊的 DST Root CA X3 將在這個月月底過期，這在 Let's Encrypt 的「DST Root CA X3 Expiration (September 2021)」這邊也有提到。

The currently recommended certificate chain as presented to Let’s Encrypt ACME clients when new certificates are issued contains an intermediate certificate (ISRG Root X1) that is signed by an old DST Root CA X3 certificate that expires on 2021-09-30.

理想上只有要任何一條 trust chain 成立，就應該會把這個憑證認為是合法的憑證，但這在 OpenSSL 1.0.2 (以及之前的版本) 不是這樣設計。

舊版的設計是只要有任何一條過期的憑證，就會把憑證認為過期而失效：

Unfortunately this does not apply to OpenSSL 1.0.2 which always prefers the untrusted chain and if that chain contains a path that leads to an expired trusted root certificate (DST Root CA X3), it will be selected for the certificate verification and the expiration will be reported.

OpenSSL 官方給了三個 workaround 可以做，另外我還有想到一個惡搞方式，是可以用其他家免費的憑證... 不過也是得測看看在 OpenSSL 1.0.2 下會不會動。

在 AWS 上面的 OpenVPN Server 效能

這篇的後續可以參考「Amazon EC2 的網路效能」這篇。

最近在在調整跑在 Amazon EC2 上 OpenVPN server 的效能，要想辦法把 network throughput 拉高，當作在導入 WireGuard 之前的 workaround，但看起來還是頗有用，記錄一下可以調整的部份...

在還沒灌大量流量前是用 t3a.nano (開 Unlimited mode)，然後會觀察到的瓶頸是 OpenVPN 的 daemon 吃了 100% CPU loading，最高速度卡在 42MB/sec 左右。

第一個想到的是看看 OpenVPN server 有沒有可以使用多 CPU 的方式，但查了資料發現 OpenVPN server 無法使用 threading 或是 fork 之類的方法善用多顆 CPU，所以就開始想其他方法...

接著看到我們目前用的是 AES-256-CBC 了，網路上很多文章都有提到 AES-128-CBC 會快一些，但我們的 OpenVPN client 已經是設死都用 AES-256-CBC 了，這個就沒辦法了...

而第一個可行的解法是把 AMD-based 的 t3a.nano 換成 ARM-based 的 t4g.nano，還是 100% 的 CPU loading，但直接多了 50%+ 的效能，到了 69MB/sec。

第二個解法是找資料時發現的 fast-io 參數，加上去以後可以再快一些，到 77MB/sec。

有了這兩個 workaround 應該就堪用了，接下來是發現在傳大量資料跑一陣子後速度會掉下來，於是開了兩台 t4g.nano 用 iperf 對測了一下，發現會逐步掉速：

  • 前 15 秒可以直接到 5Gbps，就是 AWS 網頁上宣稱的最高速度，接下來降到 800Mbps 左右。
  • 到 180 秒左右後降到 300Mbps。
  • 到 210 秒左右後回到 800Mbps。
  • 到 300 秒左右後降到 500Mbps。
  • 到 300 秒左右後降到 300Mbps。
  • 到 1260 秒左右後降到 30Mbps，後面就一直維持這個速度了。

看起來 network bandwidth credit 是分階段的，但 30Mbps 真的有點低...

在換成四倍大的 t4g.small 測試後發現也只能到 40MB/sec 左右 (比較疑惑的是，居然不是四倍？)，目前上了 c6g.medium，但看起來網路的部份也還是有瓶頸，在 46MB/sec 左右，要再想一下下一步要怎麼調整...

但以目前看到的情況總結，如果能用 ARM 架構就儘量用，效率與價錢真的是好 x86-64 不少...

Shell Script 裡面 [ "x$var" = "xval" ] 的歷史

看到「What exactly was the point of [ “x$var” = “xval” ]?」這篇，在講為什麼不直接寫 [ "$var" = "val" ] 而是會加上 x 而寫成 [ "x$var" = "xval" ]，被稱為 x-hack 的 workaround... (其實已經變成 best practice 了)

最常被拿出來講的是 - 開頭的字串，不過文章作者找到更多奇怪的 bug report，像是 ( 與 ) 之類的問題 XD

雖然作者提到大概在 2010 (或是 2015) 都修完了，但我應該還是會繼續這樣寫 (算是 best practice 了)，可以避免在遇到老系統上遇到問題...