一個 ARP 廣播封包的故事

ARP 協定是在乙太區域網路中常用到的一個協定，當我們有資料要傳給區域網路上的某台裝置時，由於上層僅知道 IP 資訊，故需要使用 ARP 協定來得知該裝置的 MAC。

一般來說，系統都會有內建的 ARP table，以 Windows 來說，可以使用 "arp -a" 來觀看，如果在 table 中找不到對應的 IP，就會發出 ARP 廣播封包來得到該台裝置的 MAC，而這個封包的目的 MAC 便會是 "FF:FF:FF:FF:FF:FF"，表示要傳給區域網路中的所有節點。

我們有個專案會使用 UEFI Shell 開機且定時的使用 HTTP Web API 跟 Server 溝通，以得知接下來要做的測試並回報測試結果。

某天我們拿到了新的板子，恰巧的是網路卡晶片也改了，這時原本正常的測試都無法順利進行，不是 DHCP 取不到 IP 就是 HTTP Web API 無法正常工作。當然，一開始會直覺是因為新板子的緣故。

由於此板已經在私人的網路環境測試過，DHCP 看起來都正常工作，只好詢問公司 IT 是否有更改公司區域網路設定，不料 IT 並沒有修改設定，這段期間也有將自己電腦接到該板子所使用的 port 測試，看起來網路也都正常，偏偏兩者合起就來就是無法正常工作，這中間還做了很多實驗，但都無助於問題解決。

沒辦法只好動用 Wireshark 和 mirror port switch 了，首先可以確認的是某些時候不論是 DHCP 的回應封包或是測試 Server 的 SYN-ACK 封包，都有正常送回板子端，但不知道什麼緣故，板子會認為沒有收到封包，結果便是 DHCP 取不到 IP 以及 HTTP Web API 失效。

雖然從封包可以證明問題似乎是出自板子端，但對解決問題還是沒有幫助，畢竟在我們自己的私人網路環境都是正常的。幸好在截取封包的過程中，發現有一個設備不斷的在發出 ARP 廣播封包且每次要詢問的 IP 都不一樣，從比例來看，至少佔了封包數的 40 % 以上( 因為是 mirror 故這個數字可能 double 了 )，這是個不正常的現象，一般來說，大部份都會是 IPV4 封包佔的比例會是最高，ARP 應該是 10% 以下較為合理。

將此情況回報給 IT 後，據 IT 的說法是該台設備的使用者誤將 DHCP 設定設成固定 IP，導致該設備不斷的發出 ARP 廣播封包。說也奇怪，在 ARP 廣播封包消失後，我們的板子就恢復正常了，個人猜測是因為 UEFI Network Stack 的 implement 無法處理此類情況，畢竟 UEFI 只是個單執行緒的精簡 OS？

雖然後續測試看起來都正常了，但到底是不是因為 ARP 廣播封包所引起？這個問題一直在我心頭縈迴不去，看來證明它的方式便是想辦法創造出一樣的環境。

Google 了一下，想要發出 ARP 封包看起來在 Windows 下不可行，幸好這個世界上還有萬能 OS - Linux 存在，只要使用 RAW Socket 便可以順利的發出 ARP 廣播封包。

萬事具備，只欠東風，使用 Switch 架設了一個私人網路環境，並配合測試 Server 配置，設定了相關裝置的固定 IP，原本只是簡單寫個 for loop scrip 10000 + C code 發送 ARP 廣播封包，但板子看起來卻是一切正常？靈機一動之下，判斷是壓力不夠，在開啟另外一個終端機並執行相同的 script 後，我們的板子終於宣告不治，一直要等到 ARP 廣播封包結束後才能恢復正常。

能夠確認自己的判斷並重現問題，我想這才是 RD 的本事所在，真不枉費我寫了 14 年的 Code。

2021/12/24 更新

原來是我誤會 Windows 了，Windows 有提供一個 SendARP 的 Win32 API，故我們在 Windows 下也可以發送 ARP 封包，重點是可以用 Go！另外，我也找到一個 Go package 可以在 Linux 下發送 ARP 封包，這樣就更容易做測試了。

https://github.com/tylpk1216/ARP

Free Software EFI file system drivers

之前就看過有人提到此類 driver 的存在。最近在查資料時，又找了一下，記錄下來以備不時之需。

https://efi.akeo.ie/

上述是一個 open source 專案，裡面有很多 file system 的 EFI driver。以讀取 NTFS partition 來說，這個專案比較方便，直接使用 load 方式載入即可。不像另外一個 rufus 專案，還需要動到 dd command 才行。

唯一要注意的是 NTFS 只能 read，不支援 write。想想也很合理，畢竟微軟並沒有提供正式的 Spec，大部份的解決方式都是靠 open source 社群摸索出來的。

Wireshark 重出江湖

第一次使用 Wireshark 應該有 10 年以上了吧，記得最早的名字似乎不是 Wireshark？總之，那是個還買得到純 Hub 的年代，要抓封包並沒有那麼困難，因為 Hub 根本不管 MAC，故不像 Layer 2 Switch 一樣，可以解決碰撞的問題。

最近為了看一個問題，此問題可能是在 device 端，故我需要抓到流經 device 的封包。因為我不是 IT，我也沒有觸碰實體 IT Switch 的權限，最簡單的方式便是接個 Hub，沒想到市面上已經找不到純 Hub，不太可能為了這個去拍賣網站購買舊貨。幸好 Layer 2 網管型 Switch 一般都會有個 mirror port 的功能，可以把想監聽的 port 導出來好方便抓取封包。以前無聊就查過最便宜的機器要多少錢，沒想到只要一千塊就可以搞定，故趁這個機會買台來玩玩。

我購買的機器是 ZYXEL GS1200-5，這應該是市面上最便宜的了吧？只要設定 192.168.1.4 以後的 IP，便可能透過 Web 界面設定 mirror port 的功能。要注意的是由於是 mirror，故 Wireshark 除了 mirror port 的封包，還會抓到 Wireshark 本身電腦的封包，故 Switch 的接法便顯得重要。一開始我 mirror 的是 IT Switch 出來的線，會讓封包更顯得零亂，後來直接 mirror device 那個 port 才方便分析封包。

既然都要抓封包了，便趁這個機會買了本 Wireshark 的書，我是在 Google Play Book 購買的 PDF 電子書，大推這一本《實戰封包分析第三版》，說得非常清楚。我雖然也在 Amazon.cn 買了 2 本簡體書，但翻沒幾頁就看不下去了。

最後終於順利的解決問題了，但這個故事說來話長，有機會再好好分享。

Parsing XML that hast namespace in python

import xml.etree.ElementTree as ET

def main():
    tree = ET.parse('content.opf')
    root = tree.getroot()

    ns = {
        'manifest' : 'http://www.idpf.org/2007/opf',
        'item' : 'http://www.idpf.org/2007/opf'
    }

    manifest = root.find('manifest:manifest', ns)

    count = 0
    for item in manifest.findall('item:item', ns):
        s = item.attrib
        print(s['href'])
        count += 1

    print('All items are', count)

if __name__ == '__main__':
    main()

傳說中的記憶體增加警告

之前為了讓網域上的 device 可以連接 Server 做測試，需要有合法的 OS，但 IT 只有 Win10 的授權可以安裝，反正也不需要什麼多好的效能，故上線時倒也一直相安無事。

約莫是一年前發現 Server 會無緣無故無法從遠端連線，即使人在本機前面，輸入帳密後依然無法操作電腦，經過了幾次觀察後才發現，是因為實體記憶體已經快耗盡，系統不斷在做 Swap 才導致操作無法回應。後來歸納出是因為 Win10 只要一陣子沒有做 Windows Update，記憶體便會緩慢的不斷增加，而我們的電腦只有 8G 的 RAM 可用。

手上 Coding 的工作便做不完了，實在是不想每天做 IT 營運檢查，故那時寫了一個簡單程式，會去監控 Server 的記憶體使用情形，每天會發送一次 mail 報告目前記憶體使用情形，每一個小時也會檢查一次，如果超過 50% 便會再發一次 mail 通知，覺得記憶體使用過多，便遠端去做 Windows Update 即可。

雖然針對電腦管理也有很多免費軟體可用，但實在是不想安裝軟體，故自己來還是比較簡單，對 Server 也比較沒負擔，因為管理軟體大概都需要開啟 Web 服務以及安裝資料庫，好方便監控。

不知不覺就這樣過了一年，昨天休假時無聊開啟公司信箱，第一次遇到超過 50% 的情形，截張圖紀念一下。

話說 Win10 還真吃記憶體，昨天每日報告還在 38% 左右，晚上 5 點多左右便升到了 55%，Windows 還真是讓人猜不透呀。

熱騰騰的 Amazon 雲端發票

想不到 Amazon 沒有等到明年 1 月 1 日才搞定電子發票，而是在 11 月初就正式上線，不禁要給他一個讚，雖然還是輸 Google 好幾個光年XD

手邊雖然沒有微軟的服務，但我想微軟應該是一直都有開發票才對，畢竟有作業系統和辦公室軟體的銷售業務。

由於這些境外電商的銷售屬於新興類別，財政部於 2018 年 7 月 16 日修正公布統一發票使用辦法第 7-1 條第 2 款規定，本法第 6 條第 4 款所定營業人 ( 即境外電商營業人 ) 應開立雲端發票交付買受人。故電子郵件便順理成章的成為此類銷售的電子發票載具。

如果有自然人憑證或是手機條碼的人，可以去「財政部電子發票整合服務平台」，將電子郵件載具做歸戶的動作，只要再設立金融帳號，系統便可以自動對獎並匯款，真的是節省很多時間。

如果我是政府，我一定會開發一套適合各行業的發票系統，並免費提供給各家使用，這樣除了消費者對獎方便，其實也可以從這些數據看出國家目前的民生消費狀況，並依據情況來調整國家經濟政策。

繁體電子書閱讀元年

今年對我來說是個特別的一年，我從原本只有 PW3 的機器，陸續買了 Oasis 2、Boox Note Lite、Boox Nova Pro 以及最後的 mooInk Pro。也是從今年開始，知道了 Kobo、Google Play Book 以及 Readmoo 電子書商的存在。故我從購買原文資訊技術書開始轉變成購買繁體中文書，這一切的一切都是拜電子閱讀器所致。

當然，購買繁體中文書也開始遇到停滯期，感覺想買的書都買了，雖然從讀墨購書金額看不出來就是XD

mooInk Pro 1.4.1 更新

此次更新最大的亮點是增加了更換休眠圖片的支援，圖片大小為 1650 x 2200 pixel。不過因為灰階螢幕的關係，要做出漂亮的圖片還真不簡單！

關於更新一事，我後來想通了，mooInk Pro 既然是 Sony DPT-CP1 的機子，整體的 Code 應該都是 Sony 原本的，Readmoo 應該只有增加 UI 及 App 的支援。故關於 PDF 的相關更新，我想應該是很難，這部份應該都是原 Sony 的，真希望是我想錯就好了。

How to select server with NVIDIA GPU card support

Please refer to the link below.
https://www.nvidia.com/en-us/data-center/tesla/tesla-qualified-servers-catalog/

如果是 1U 的機器，顯卡都必須橫放，支援清單可以從上面的列表查到。
至於是立式的機器就比較不用擔心。

用電瓦數
NVIDIA T4 16GB - 70W。
NVIDIA Tesla P100 - 300W。
Inten Xeon CPU - 85W。

以 T4 的卡來說，其長寬如下
6.89 cm x 16.95 cm。

https://www.nvidia.com/content/dam/en-zz/Solutions/Data-Center/tesla-t4/t4-tensor-core-product-brief.pdf