nic – Gea-Suan Lin's BLOG

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 過了十幾年還是...

Netflix 的 Open Connect 機器往 800Gbps 推進

2021 年的時候曾經提過 Netflix 試著用單機推出 400Gbps 的流量 (用在 Netflix 的 Open Connect)：「Netflix 在單機服務 400Gbps 的影音流量」，快一年後的目前，Netflix 的人已經成功推到接近 800Gbps 了：「Serving Netflix Video Traffic at 800Gb/s and Beyond」。另外在 Hacker News 上的討論「Serving Netflix Video Traffic at 800Gb/s and Beyond [pdf] (nabstreamingsummit.com)」也可以看看。

翻了一下投影片，最後衝到 720Gbps，主要是因為 NIC output drop，而非其他部份。

裡面還是把之前的故事也都講了一遍 (不然簡報的時間會太短？)，如果有看過前面的內容可以快速看一下就好，這次新的東西從 page 89 開始：

Asynchronous Sendfile (2014)
Kernel TLS (2016)
Network-centric NUMA (2019)
Inline Hardware (NIC) kTLS (2022)
800G initial results

最後面幾張投影片裡面有提到往 800Gbps 衝的硬體平台：

AMD (EPYC 7713 CPUs)
Dell (PowerEdge R7525)
Mellanox/NVIDIA (ConnectX-6 Dx NICS)
Intel (P5316 NVME)

下個目標不知道是什麼，看起來目前已經壓榨到 memory bandwidth 也有點極限的感覺了...

歡樂的 md5crypt 密碼...

作者寫了一篇關於以前在 WHOIS 記錄上看到一串 $1$ 開頭的 md5crypt 密碼 XDDD：「I mean, why not tell everyone our password hashes?」。

Now the fields are filtered but this is a reasonably recent change. Prior to July 2015 the hashed passwords were shown to anyone who whois’d the maintainer object and used md5 passwords. Which was nearly all of them in my experience.

Mntner:         DTAG-NIC
Descr:          Deutsche Telekom Internet Services NIC
Admin-c:        KK281-RIPE
Tech-c:         HI56-RIPE
Auth:           MD5-PW $1$KQ3NSRfS$/bcvLAz2BKyf5HF4VkPMh/
Mnt-by:         DTAG-NIC
Referral-by:    RIPE-DBM-MNT

不知道有沒有人去跑看看... XD

話說 md5crypt 已經被認為不安全 (當初的發明人 phk 也有出來建議大家換掉了：「Md5crypt Password scrambler is no longer considered safe by author」)，從目前 Hashcat 的攻擊速度就可以看出來... 找個最近的例子來說，可以參考「8x Nvidia GTX 1080 Hashcat Benchmarks」這篇。

Hashtype: md5crypt, MD5(Unix), FreeBSD MD5, Cisco-IOS MD5

Speed.Dev.#1.:  9918.1 kH/s (97.10ms)
Speed.Dev.#2.:  9830.1 kH/s (97.70ms)
Speed.Dev.#3.: 10017.4 kH/s (97.36ms)
Speed.Dev.#4.:  9986.5 kH/s (96.92ms)
Speed.Dev.#5.:  9976.8 kH/s (97.74ms)
Speed.Dev.#6.:  9889.2 kH/s (97.29ms)
Speed.Dev.#7.: 10010.5 kH/s (97.40ms)
Speed.Dev.#8.: 10083.0 kH/s (96.94ms)
Speed.Dev.#*.: 79711.6 kH/s

而隔壁的 bcrypt 對 Hashcat 的防禦性完全在不同等級：

Hashtype: bcrypt, Blowfish(OpenBSD)

Speed.Dev.#1.:    13094 H/s (47.51ms)
Speed.Dev.#2.:    13076 H/s (47.63ms)
Speed.Dev.#3.:    13292 H/s (46.88ms)
Speed.Dev.#4.:    13250 H/s (47.17ms)
Speed.Dev.#5.:    13296 H/s (46.86ms)
Speed.Dev.#6.:    13160 H/s (47.30ms)
Speed.Dev.#7.:    13260 H/s (46.98ms)
Speed.Dev.#8.:    13280 H/s (46.80ms)
Speed.Dev.#*.:   105.7 kH/s

直接相除是 754 倍左右。

以 85 個字元的組合計算 ([0-9A-Za-z] 62 個，特殊字元 22 個，加上空白 1 個)，抗性多了 1.5 個字 (log₈₅(754) 大約是 1.49)？如果以 62 個字元來看也有 1.6 個字，強了不少...

用 Intel 網卡上的 Flow Director 過濾封包

在「Traffic filtration using NIC capabilities on wire speed (10GE, 14Mpps)」這邊看到的技巧。

作者建議另外安裝 driver，因為 Linux kernel 內的 driver 功能有限：「Intel Ethernet Drivers and Utilities」。

重點在 ethtool 這個工具，可以看到條件設定：

ethtool --help:
        ethtool -N|-U|--config-nfc|--config-ntuple DEVNAME    Configure Rx network flow classification options or rules
        rx-flow-hash tcp4|udp4|ah4|esp4|sctp4|tcp6|udp6|ah6|esp6|sctp6 m|v|t|s|d|f|n|r... |
        flow-type ether|ip4|tcp4|udp4|sctp4|ah4|esp4
            [ src %x:%x:%x:%x:%x:%x [m %x:%x:%x:%x:%x:%x] ]
            [ dst %x:%x:%x:%x:%x:%x [m %x:%x:%x:%x:%x:%x] ]
            [ proto %d [m %x] ]
            [ src-ip %d.%d.%d.%d [m %d.%d.%d.%d] ]
            [ dst-ip %d.%d.%d.%d [m %d.%d.%d.%d] ]
            [ tos %d [m %x] ]
            [ l4proto %d [m %x] ]
            [ src-port %d [m %x] ]
            [ dst-port %d [m %x] ]
            [ spi %d [m %x] ]
            [ vlan-etype %x [m %x] ]
            [ vlan %x [m %x] ]
            [ user-def %x [m %x] ]
            [ action %d ]
            [ loc %d]] |
        delete %d

看起來 stateless 的過濾可以在上面做...

NIC of India 簽發 Google 的 certificate

Google 昨天發出的公告，發現 NIC of India 發出了幾張 Google 網域的 SSL 憑證：「Maintaining digital certificate security」。

NIC of India 所取得的憑證權限是 India CCA 所發出的 Intermediate CA 權限。而目前 India CCA 只在 Microsoft Root Store 上面有使用，所以會受到影響的範圍是 Windows 上的 IE 以及應用程式，而因為 Google Chrome 有白名單保護，至少在 Google 的網域裡面是不受到直接傷害...

事情還在調查 (還在戳湯圓？)，歷史總是不斷地重演...

Ubuntu 12.04 上用 KVM (CLI) 裝 FreeBSD

過年後在家裡弄了一台技嘉的準系統跑 Ubuntu 12.04，結果手上突然沒機器可以跑 porttools 測試，而這台機器平常也沒接鍵盤，就想直接跑 command line 的 KVM 裝 FreeBSD。其實知道方式後就很簡單，只是一開始沒弄懂花了不少時間...

首先是安裝 KVM，這部份用 apt-get install kvm 就可以拉下來裝好了。

真正要做的第一部是先用 qemu-img 建立 40GB 的 disk image (qcow2)：

qemu-img create -f qcow2 ~/vm/image.qcow2 40G

然後直接用 iso image 安裝 (抓 iso image 的事情也跳過去請各位自己來)，設為 4 CPU (-smp 4)、1024MB RAM (-m 1024)，並且透過 serial console 安裝 (-nographic -curses)，開機先從 cdrom 上開 (-boot d)：

kvm -smp 4 -drive file=/abs/path/vm/image.qcow2,if=virtio -cdrom /abs/path/vm/FreeBSD-10.0-RELEASE-amd64-bootonly.iso -m 1024 -nographic -curses -net nic,model=e1000 -net tap -boot d

其中網路的部份卡了最久，後來發現預設值的 -net nic -net user 意思是：

-net nic 表示在 Guest OS 內建立一張網卡接到 KVM 的 vlan0。
-net user 表示在 KVM 的 vlan0 上建使用 userland mode NAT。

由於 userland mode NAT 很受限 (只有 TCP 與 UDP 會通)，所以我用 -net nic -net tap 表示直接 bridge 到 virbr0 上再 NAT 出去。而我希望對 Guest OS 使用 e1000，所以最後就變成 -net nic,e1000 -net tap。

接下來安裝 FreeBSD 時就可以用 DHCP mode 抓到 IP 了，由於我希望可以從 Host 直接連進去，所以我是設成 static IP。

裝完後就不需要掛 cdrom 與優先從 cdrom 開始開：

kvm -smp 4 -drive file=/abs/path/vm/image.qcow2,if=virtio -m 1024 -nographic -curses -net nic,model=e1000 -net tap

先前用 -hda /abs/path/vm/image.qcow2 掛上去，結果 i/o 很慢，被 delphij 提醒後改跑 virtio，速度就正常多了。不過這是因為 FreeBSD 10 就內建支援 virtio 了，如果是使用 FreeBSD 9 的需要另外再透過 ports 裝進去。

記錄下來給需要的人玩看看，下次也許應該玩玩看 VNC display？