載點:https://sourceforge.net/projects/extraputty/
2022年4月25日 星期一
主機板廠牌與型號/Windows 10序號 提取command
2022年2月18日 星期五
PHY暫存器
PHY暫存器的地址空間為5位，從0到31最多可以定義32個暫存器（隨著晶片功能不斷增加，很多PHY晶片採用分頁技術來擴充套件地址空間以定義更多的暫存器），IEEE802.3定義了地址為0-15這16個暫存器的功能，地址16-31的暫存器留給晶片製造商自由定義，如下表所示。
（1）官方介紹請參考IEEE802.3標準的22.2.4 Management functions節。
（2）上圖的B和E表示了，在特定介面下，暫存器是基本的還是擴充套件的。例如：MII介面下只有0和1暫存器是基本的，其它的是擴充套件的。注意：所為擴充套件是指留給IEEE以後的擴充套件特性用，不是給PHY廠商的擴充套件，PHY廠商自定義的只能是16~31號暫存器
（3）在IEEE標準文件及某些PHY手冊中，某暫存器的位元(bit)用X.y表示，如0.15表示第0暫存器的第15位。
Control Register (Register 0)
暫存器0是PHY控制暫存器，通過Control Register可以對PHY的主要工作狀態進行設定。應該保證控制暫存器每個位的預設值，以便在沒有管理干預的情況下，上電或復位時PHY的初始狀態為正常操作狀態。Control Register的每一位完成的功能見下。
- Reset：通過將位0.15設定為邏輯1來完成復位PHY。 該操作應將狀態和控制暫存器設定為其預設狀態。 因此，此操作可能會改變PHY的內部狀態以及與PHY關聯的物理鏈路的狀態。復位過程中Bit15保持為1，復位完成之後該位應該自動清零。在復位過程完成之前，PHY不需要接受對控制暫存器的寫入操作，並且在復位過程完成之前寫入0.15以外的控制暫存器位可能不起作用。 復位過程應在0.15位設定的0.5 s內完成。
（1）一般要改變埠的工作模式（如速率、雙工、流控或協商資訊等）時，在設定完相應位置的暫存器之後，需要通過Reset位復位PHY來使配置生效。
（2）該位元位的預設值為 0。
- Loopback：當位0.14被設定為邏輯1時，PHY應置於環回操作模式。 當位0.14置位時，PHY接收電路應與網路介質隔離，並且MII或GMII處的TX_EN斷言不應導致網路介質上的資料傳輸。 當位0.14置位時，PHY應接受來自MII或GMII傳送資料路徑的資料，並將其返回給MII或GMII接收資料路徑，以響應TX_EN的斷言。 當位0.14置位時，從斷言TX_EN到斷言RX_DV的延遲應小於512 BT。 當位0.14置位時，除非設定了位0.7，否則COL訊號應始終保持無效，在這種情況下，COL訊號的行為應如22.2.4.1.9所述。 清0.14位為零允許正常操作。
Loopback是一個除錯以及故障診斷中常用的功能，Bit14置1之後，PHY和外部MDI的連線在邏輯上將被斷開，從MAC經過MII/GMII（也可能是其他的MAC/PHY介面）傳送過來的資料將不會被髮送到MDI上，而是在PHY內部（一般在PCS）迴環到本埠的MII/GMII接收通道上，通過Loopback功能可以檢查MII/GMII以及PHY介面部分是否工作正常，對於埠不通的情況可用於故障定位。
（1）需要注意的是，很多時候PHY設定Loopback後端口可能就Link down了，MAC無法向該埠發幀，這時就需要通過設定埠Force Link up才能使用Loopback功能。
（2）該位元位的預設值為 0。
- Speed Selection：***Bit13和Bit6兩位聯合實現***對埠的速率控制功能。連結速度可以通過自動協商過程或手動速度選擇來選擇。 通過將位0.12清零來禁用自動協商時，允許手動速度選擇。
- 當禁用自動協商並將位0.6清除為邏輯0時，將位0.13設定為邏輯1將PHY配置為100 Mb / s操作，並將位0.13清除為邏輯0將PHY配置為10 Mb / s操作 。
- 當禁用自動協商並將位0.6設定為邏輯1時，將位0.13清零為邏輯0會選擇1000 Mb / s的操作。 將位0.6和0.13設定為邏輯1的組合保留用於未來的標準化。
- 當使能自動協商時，可以讀取或寫入位0.6和0.13，但位0.6和位0.13的狀態對鏈路配置沒有影響，位0.6和位0.13不需要反映當它被讀取時連結。
如果PHY通過位元1.15：9和位元15.15：12報告它不能工作在所有速度時，則位元0.6和0.13的值應該與PHY可以操作的速度相對應。並且任何試圖將該位設定為無效的操作均將被忽略。
（1）對Speed Selection的修改設定，往往需要復位端口才能配置生效。因此在設定該位置的時候需要檢查自動協商的設定並通過Bit15復位埠。
（2）位0.6和0.13的預設值是根據位1.15：9和15.15：12所指示的PHY可以操作的***最高資料速率***的編碼組合。
- Auto-Negotiation Enable：自動協商過程應通過將位0.12設定為邏輯1來啟用。 如果位0.12設定為邏輯1，則位0.13、0.8和0.6不應對鏈路配置和除了自動協商協議規定之外的站操作產生影響。 如果將位0.12清零為邏輯0，則無論鏈路配置和自動協商過程的先前狀態如何，位0.13、0.8和0.6都將確定鏈路配置。
如果PHY通過位1.3報告它缺乏執行自動協商的能力，則PHY應在位0.12返回零值。 如果PHY通過位1.3報告它缺乏執行自動協商的能力，則位0.12應該始終寫為0，並且任何嘗試將1寫入位0.12都應該被忽略。
必須注意的是，對於1000BASE-T介面,自動協商必須開啟。
- Power Down：通過將位0.11設定為邏輯1，可以將PHY置於低功耗狀態。 清0.11位為零允許正常操作。 PHY在掉電狀態下的具體行為是特定實現的。 處於掉電狀態時，PHY應響應管理事務。 在轉換到掉電狀態期間和處於掉電狀態期間，PHY不應在MII或GMII上產生寄生訊號。
當位0.11或位0.10被設定為邏輯1時，PHY不需要滿足RX_CLK和TX_CLK訊號功能要求。 在位0.11和0.10清零後，PHY應在0.5 s內滿足22.2.2中定義的RX_CLK和TX_CLK訊號功能要求。
（1）Power Down模式一般在軟體shut down埠的時候使用，需要注意的是埠從Power Down模式恢復，需要復位埠以保證埠可靠的連線。
（2）該位的預設值為 0。
- Isolate：通過將位0.10設定為邏輯1，PHY可能被迫將其資料路徑與MII或GMII電隔離。 清零位0.10允許正常操作。 當PHY與MII或GMII隔離時，它不會響應TXD資料包和TX_EN，TX_ER、GTX_CLK的輸入。並且它的TX_CLK，RX_CLK，RX_DV，RX_ER，RXD資料包、COL和CRS輸出均應為高阻態。 當PHY與MII或GMII隔離時，它將響應管理事務（MDC/MDIO介面的訊號）。
（1）IEEE802.3沒有對Isolate 時MDI介面的狀態進行規範，此時MDI端可能還在正常執行。Isolate在實際應用中並沒有用到。
（2）由於目前很多百兆的PHY晶片其MAC介面主流的都是SMII/S3MII，8個埠的介面是相互關聯的，一個埠設定Isolate可能會影響其他埠的正常使用，因此在使用中注意不要隨意更改bit10的狀態。
- Restart Auto-Negotiation：如果PHY通過位1.3報告它缺乏執行自動協商的能力，或者如果自動協商被禁用，則PHY應在位0.9返回零值。 如果PHY通過位1.3報告它缺乏執行自動協商的能力，或者如果禁用了自動協商，則應將位0.9始終寫為0，並且任何嘗試將1寫入位0.9應被忽略。
Bit9置1將重新啟動埠的自動協商程序，當然前提是Auto-Negotiation Enable是使能的。
一般在修改埠的自動協商能力資訊之後通過Bit9置1重新啟動自動協商來使埠按照新的配置建立link。
- Duplex Mode：可以通過自動協商過程或手動雙面選擇來選擇雙工模式。 通過將位0.12清零來禁用自動協商時，允許手動雙面選擇。
- 當禁用自動協商時，將位0.8設定為邏輯1將PHY配置為全雙工操作，並將位0.8清零以將邏輯0配置為用於半雙工操作的PHY。
- 當啟用自動協商時，可以讀取或寫入位0.8，但位0.8的狀態對鏈路配置沒有影響。
如果PHY通過位1.15：9和15.15：12報告它只能在一個雙工模式下工作，則位0.8的值應該與PHY可以工作的模式相對應，並且任何嘗試改變將該位0.8修改為無效指的操作應被忽略。
對Duplex Mode的修改配置也需要復位端口才能生效。
- Collision Test：衝突訊號（COL）測試開關。在需要對COL訊號進行測試時，可以通過Bit7置1，這時PHY將輸出一個COL脈衝以供測試。實際測試操作中也可以將埠配置為半雙工狀態，通過發幀衝突來測試COL訊號，因此該配置實用價值不大。
- Unidirectional enable：如果PHY通過位元1.7報告它不具備編碼和傳輸來自媒體獨立介面的資料的能力，而不管PHY是否確定已建立有效鏈路，則PHY應在位元0.5中返回零值，並且 任何嘗試寫一個到位0.5應該被忽略。
Status register
暫存器1是PHY狀態暫存器，主要包含PHY的狀態資訊，大多數bit的值都是由晶片廠家確定的，每一個bit的功能在表3種已有詳細說明。
暫存器中各位的詳細說明如下：
- 100BASE-T4 ability：當讀為邏輯1時，位1.15指示PHY有能力使用100BASE-T4信令規範執行鏈路傳送和接收。 當讀為邏輯0時，位1.15表示PHY缺乏使用100BASE-T4信令規範執行鏈路傳送和接收的能力。
- 100BASE-X full duplex ability：當讀為邏輯1時，位1.14指示PHY有能力使用100BASE-X信令規範執行全雙工鏈路傳輸和接收。 當作為邏輯0讀取時，bit1.14表示PHY缺乏使用100BASE-X信令規範執行全雙工鏈路傳輸和接收的能力。
- 100BASE-X half duplex ability：當讀為邏輯1時，位1.13指示PHY有能力使用100BASE-X信令規範執行半雙工鏈路傳輸和接收。 當讀為邏輯0時，位1.13指示PHY缺乏使用100BASE-X信令規範執行半雙工鏈路傳輸和接收的能力。
- 其他同類型的值意義基本與上面幾個相同：指示PHY所具有的工作模式能力，不再一一說明。
- Unidirectional ability：當讀為邏輯1時，位1.7指示PHY具有編碼和傳輸來自媒體獨立介面的資料的能力，而不管PHY是否確定已建立有效鏈路。 當讀為邏輯0時，位1.7指示PHY只有在PHY確定已建立有效鏈路時才能從媒體獨立介面傳輸資料。
- MF preamble suppression ability：當讀為邏輯1時，位1.6指示PHY能夠接受管理幀，而不管它們是否在22.2.4.5.2中描述的前導碼模式之前。 當讀為邏輯0時，位1.6指示PHY不能接受管理幀，除非它們之前是22.2.4.5.2中描述的前導碼模式。
- Auto-Negotiation Complete：當讀為邏輯1時，位1.5指示自動協商過程已完成，並且由自動協商協議（條款28或條款37）實施的擴充套件暫存器的內容是有效的。 當讀為邏輯0時，位1.5指示自動協商過程尚未完成，並且擴充套件暫存器的內容由自動協商協議的當前狀態定義，或者為手動配置寫入。 如果自動協商通過清除位0.12禁用，則PHY應在位1.5返回零值。 如果PHY缺乏執行自動協商的能力，它還應在位1.5返回零值。
在除錯以及異常故障處理時，可以通過該位暫存器的狀態判斷AN是否成功，從而進一步的檢查AN相關的設定是否正確，或者晶片的AN功能是否正常等。
- Remote Fault：當讀為邏輯1時，位1.4表示檢測到遠端故障狀態。 故障型別以及故障檢測的標準和方法是PHY特定的。 遠端故障位必須使用鎖存功能來實現，以便發生遠端故障將導致遠端故障位置位，並保持置位狀態直至被清除。 每當通過管理介面讀取暫存器1時，遠端故障位應清零，並且還應通過PHY復位清零。
遠端錯誤指示位。Bit4=1代表連線對端（Link Partner）出錯，至於出錯的具體型別以及錯誤檢測機制在規範中並沒有定義，由PHY的製造商自由發揮，一般的廠商都會在其他的暫存器（Register16-31由廠商自行定義）指示比較詳細的錯誤型別。在與埠相關的故障查證中，Remote Fault是一個重要的指示資訊，通過互聯雙方的Remote Fault資訊（可能要加上其他的具體錯誤指示），可以幫助定位故障原因。 - Auto-Negotiation ability：當讀為邏輯1時，位1.3指示PHY有能力執行自動協商。 當讀為邏輯0時，位1.3指示PHY缺乏執行自動協商的能力。
- Link Status：當讀為邏輯1時，位1.2指示PHY已經確定已建立有效鏈路。 當作為邏輯0讀取時，位1.2指示該連結無效。 確定鏈路有效性的標準是PHY特定的。 鏈路狀態位應該使用鎖存功能來實現，以便發生鏈路故障情況將導致鏈路狀態位清零並保持清零，直到通過管理介面讀取。 此狀態指示旨在支援在30.5.1.1.4，aMediaAvailable中定義的管理屬性。
實際應用中一般都是通過Bit2來判斷埠的狀態。而且，一般的MAC晶片也是通過輪詢PHY的這個暫存器值來判斷埠的Link狀態的（這個過程可能有不同的名稱，比如BCM叫做Link Scan，而Marvell叫做PHY Polling。）如前所述，在AN Enable的情況下，Link Status的資訊只有在Auto-Negotiation Complete指示已經完成的情況下才是正確可靠的，否則有可能出錯。 - Jabber Detect：當作為邏輯1讀取時，位1.1指示已經檢測到爆音條件。 此狀態指示旨在支援30.5.1.1.6中定義的管理屬性，aJabber和30.5.1.3.1 nJabber中定義的MAU通知。 檢測Jabber條件的標準是PHY特定的。 Jabber檢測位應該使用鎖存功能來實現，以便發生Jabber條件將導致Jabber檢測位置位，並保持置位狀態直至被清除。 每次通過管理介面讀取暫存器1時，Jabber檢測位應清零，並且還應通過PHY復位清零。
IEEE802.3對Jabber的解釋是“A condition wherein a station transmits for a period of time longer than the maximum permissible packet length, usually due to a fault condition”。這一位指示的是Link Partner傳送的時間超過了規定的最大長度。值得注意的是，Jabber Detect只有在10BASE-T模式下才有意義，100和1000M模式是沒有定義Jabber這一功能的。
PHY Identifier Register
暫存器2和3存放PHY晶片的型號程式碼，暫存器2(PHY ID1)為高16位，而暫存器3(PHY ID2)為低16位。由晶片製造商自行定義，實際應用中軟體通過讀取這兩個暫存器的內容可以識別PHY的型號和版本。
PHY識別符號應由由IEEE分配給PHY製造商的組織唯一識別符號（OUI）的（只需要使用第3至第24位，共22位），加上6位製造商的型號以及4位製造商的修訂版編號組成。 PHY識別符號旨在提供足夠的資訊來支援30.1.2中所要求的oResourceTypeID物件。
OUI的第三位分配給位2.15，OUI的第四位分配給位2.14，依此類推。 位2.0包含OUI的第十八位。 位3.15包含OUI的第十九位，位3.10包含OUI的第二十四位。 位3.9包含製造商型號的MSB。 位3.4包含製造商型號的LSB。 位3.3包含製造商版本號的MSB，位3.0包含製造商版本號的LSB。具體如下圖所示：
Auto-Negotiation Advertisement Register (Register 4) (R/W)
暫存器4是自動協商的能力通告暫存器，在AN Enable的前提下（見暫存器0），埠根據該暫存器的相關配置將自動協商資訊通過FLP在MDI上進行通告。當AN配置為Disable狀態的時候，暫存器4的配置將不起作用，埠的工作模式由控制暫存器中的配置決定。
該暫存器包含PHY的通告能力，它們將在自動協商期間傳送給其連結夥伴。 基本頁的位定義在IEEE標準的28.2.1.2中定義。 上電時，在自動協商開始之前，該暫存器應具有以下預設配置：
- Selector Field （4.4：0）：被設定為適當的程式碼，如IEEE標準的附件28A中所規定。
- Reserved（4.14）：被設定為邏輯0。
- Technology Ability Field（4.11：5）：根據MII狀態暫存器（暫存器1）（1.15：11）中設定的值或等效值設定。 另見28.2.1.2.3和附件28D。
Link codeword encoding（基本鏈路碼字）
在FLP Burst內傳輸的基本鏈路程式碼字（基本頁面）應該傳達如圖28-7所示的編碼。 自動協商功能可以使用下一頁功能支援其他頁面。 下一頁交換中使用的連結程式碼字的編碼在28.2.3.4中定義。 在FLP Burst中，D0應該是第一個傳輸的位。
Next Page function
下一頁功能使用標準的自動協商仲裁機制來允許交換任意的資料。 資料由可選的下一頁資訊攜帶，其遵循用於基本連結碼字的傳輸和確認過程。 定義了四種類型的下一頁編碼：訊息頁面，未格式化頁面，擴充套件訊息頁面和擴充套件的未格式化頁面。
關於該部分，具體見IEEE標準的28.2.3.4 Next Page function。
在IEEE標準中，Auto-Negotiation Advertisement Register中的各部分全部是在獨立章節中進行介紹的。具體如下：
- Selector Field：選擇器欄位（S [4：0]）是一個5位寬的欄位，編碼32個可能的訊息。 鏈路碼字中的選擇器欄位S [4：0]應用於識別自動協商傳送的訊息的型別。 下表列出了可能傳送的訊息的型別。 隨著新訊息的發展，該表格將相應更新。
未指定的組合保留供將來使用。 不會傳輸選擇器欄位的預留組合。***我們所接觸的乙太網PHY遵從IEEE802.3規範，Selector Field=0001，該區域不可隨意更改（很多PHY將此區域設計為只讀暫存器，以免被修改）***。 - Technology Ability Field：技術能力欄位（A [6：0]）是一個7位寬的欄位，其中包含指示選擇器欄位值特定的支援技術的資訊。 這些位被對映到各個技術，以便能夠針對單個選擇器欄位值並行通告能力。 附錄28B.2和附件28D描述了IEEE 802.3選擇器的技術能力欄位編碼。 連結程式碼字中可能會公佈多種技術。 裝置應支援其宣傳的技術的資料服務能力。
- Extended Next Page：擴充套件下一頁（XNP）被編碼在基本鏈路碼字的位D12中。 擴充套件下一頁位指示本地裝置在設定為邏輯1時支援擴充套件下一頁的傳輸，並指示本地裝置在設定為邏輯0時不支援擴充套件下一頁。 Extended Next Page的使用與協商的資料速率，媒體或連結技術是正交的。 擴充套件下一頁位按照28.2.3.4中的擴充套件下一頁功能規範使用。
- Next Page：無論選擇器欄位值還是連結碼字編碼，下一頁（NP）都在D15位編碼。 支援附加連結碼字編碼的傳輸和接收是可選的。 如果不支援Next Page功能，NP位應始終設定為邏輯0。 如果裝置實現下一頁功能並希望進行下一頁交換，則應將NP位設定為邏輯1。 裝置可以實現下一頁功能，並通過將NP位設定為邏輯0來選擇不參與下一頁交換。 下一頁功能在28.2.3.4中定義。
- Remote Fault：遠端故障（RF）編碼在基本鏈路碼字的位D13中。 預設值是邏輯零。 遠端故障位為傳輸簡單的故障資訊提供了一種標準的傳輸機制。 當自動協商通告暫存器（暫存器4）中的RF位設定為邏輯1時，傳送的基本鏈路碼字中的RF位被設定為邏輯1。 當接收到的基本鏈路程式碼字中的RF位被設定為邏輯1時，如果存在MII管理功能，則MII狀態暫存器（暫存器1）中的遠端故障位將被設定為邏輯1。
Auto-Negotiation Link Partner ability register (Register 5) (RO)
暫存器5儲存的是本端PHY接收到的對端PHY所通告的埠能力，暫存器5的結構和暫存器4基本一致。
Auto-Negotiation Expansion Register (Register 6) (RO)
暫存器6儲存了PHY自動協商過程的異常資訊。從這個寄存其中我們可以獲取到Link Partner子否支援自動協商以及自動協商下一頁有沒有收到的資訊。
Auto-Negotiation Next Page transmit register (Register 7) (R/W)
自動協商下一頁傳送暫存器包含在支援下一頁功能時要傳送的下一頁連結碼字。 （見表28-6）內容在28.2.3.4中定義。 上電時，該暫存器應包含預設值2001H，該值表示訊息程式碼設定為Null訊息的訊息頁面。 該值可以由裝置希望傳輸的任何有效的下一頁訊息程式碼替換。 寫入該暫存器應將mr_next_page_loaded設定為true。
Auto-Negotiation Link Partner Received Next Page register (Register 8) (RO)
https://blog.csdn.net/sternlycore/article/details/89065789
2020年11月17日 星期二
GPON Type B保護
from:https://blog.csdn.net/derek_yi/article/details/8743146
GPON TYPE B保護的組網圖如圖1所示，相應的保護範圍包括OLT的主用和備用PON端口，主用和備用光纖。
2020年11月10日 星期二
MACsec on Linux
from https://nextheader.net/2016/10/14/macsec-on-linux/
Starting with kernel 4.6, support for MACsec has been added in Linux so it won’t be needed to use a release candidate to test this feature.
There are two ways to implement MACsec:
- manually configure secure channel(SC), security association(SA) and the keys(this is what we are going to see)
- use dot1x with MACsec extensions that allows dynamic discovery of MACsec peers, SA and SC setup, key generation and distribution
This is the topology that is being used to demonstrate most of the implementation of MACsec on Linux and the purpose is to have connectivity between the two hosts using MACsec.
Between the two hosts there is a L2VPN that is provided by the QFX10K switches.
I won’t discuss how to set up the L2VPN as we already did this several times, one example being L2circuit for L2 protocol tunneling.
On top of this, we want to have additional security at Layer 2 between the two Linux hosts, hence MACsec is the suitable option here.
There are few prerequisites for running MACsec on Linux. I won’t mention here that you need a kernel that supports MACsec:
- add the macsec module in kernel
- install the latest version of iproute2
This is how you perform these two operations
git clone git://git.kernel.org/pub/scm/linux/kernel/git/shemminger/iproute2.git cd iproute2/ ./configure make make install modprobe macsec
So let’s move further with the configuration.
The required steps to configure MACsec are the following:
- create a MACsec device on the physical link over the traffic will be received and sent
- configure a secure association on the MACsec device
- configure a receive channel(you will need to use the peer MAC address as parameter)
- configure a receive association(you will need to use the peer MAC address as parameter)
First we need to know the MAC addresses of the two hosts between which MACsec will be configured. Each host needs to know from what MAC address will receive protected traffic.
This is UBUNTU-1:
root@UBUNTU-1:~# ifconfig eth1 eth1 Link encap:Ethernet HWaddr 56:68:a6:6f:08:d1 inet6 addr: fe80::5468:a6ff:fe6f:8d1/64 Scope:Link UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:114 errors:2 dropped:91 overruns:0 frame:2 TX packets:158 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:30957 (30.9 KB) TX bytes:26724 (26.7 KB) root@UBUNTU-1:~#
And this is UBUNTU-2:
root@UBUNTU-2:~# ifconfig eth1 eth1 Link encap:Ethernet HWaddr 56:68:a6:6f:08:d6 inet6 addr: fe80::5468:a6ff:fe6f:8d6/64 Scope:Link UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:63 errors:2 dropped:36 overruns:0 frame:2 TX packets:163 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:15079 (15.0 KB) TX bytes:27392 (27.3 KB) root@UBUNTU-2:~#
Let’s see the configuration for UBUNTU-1(the last two commands are also adding an IP address on the newly created interface and bring it up so we can test later on the IP reachability between the hosts):
ip link add link eth1 macsec0 type macsec
Creates the MACsec device on eth1 interface
ip macsec add macsec0 tx sa 0 pn 1 on key 01 12345678901234567890123456789012
Configure the transmit secure association, the packet number used as the start ID for the packets sent through this SA and the key.
ip macsec add macsec0 rx address 56:68:a5:c2:37:76 port 1 ip macsec add macsec0 rx address 56:68:a5:c2:37:76 port 1 sa 0 pn 1 on key 02 09876543210987654321098765432109
Configure the receive channel and receive association based on the peer MAC address, the port number, the first packet number expected and the key.
ip link set dev macsec0 up ifconfig macsec0 10.10.12.1/24
These two bring up the interface and configure an IP address on macsec0 interface.
Remember that the transmit SA key has to match the peer’s receive SA key and the other way around.
And this is the configuration for UBUNTU-2:
ip link add link eth1 macsec0 type macsec ip macsec add macsec0 tx sa 0 pn 1 on key 02 09876543210987654321098765432109 ip macsec add macsec0 rx address 56:68:a5:c2:4c:14 port 1 ip macsec add macsec0 rx address 56:68:a5:c2:4c:14 port 1 sa 0 pn 1 on key 01 12345678901234567890123456789012 ip link set dev macsec0 up ifconfig macsec0 10.10.12.2/24
Once the configuration is applied on both sides, you can check the MACsec configuration:
root@UBUNTU-1:~# ip macsec show 8: macsec0: protect on validate strict sc off sa off encrypt off send_sci on end_station off scb off replay off cipher suite: GCM-AES-128, using ICV length 16 TXSC: 5668a5c24c140001 on SA 0 0: PN 12, state on, key 12345678901234567890123456789012 RXSC: 5668a5c237760001, state on 0: PN 12, state on, key 09876543210987654321098765432109 root@UBUNTU-1:~#
As you can see the traffic is authenticated and encrypted by default using AES-GCM-128.
From the above output, some packets protected by MACsec exited and entered this device(“PN 12” shows this, we started at 1).
Let’s send some packets between the two hosts:
root@UBUNTU-1:~# ping 10.10.12.2 -c 3 PING 10.10.12.2 (10.10.12.2) 56(84) bytes of data. 64 bytes from 10.10.12.2: icmp_seq=1 ttl=64 time=24.3 ms 64 bytes from 10.10.12.2: icmp_seq=2 ttl=64 time=20.8 ms 64 bytes from 10.10.12.2: icmp_seq=3 ttl=64 time=19.3 ms --- 10.10.12.2 ping statistics --- 3 packets transmitted, 3 received, 0% packet loss, time 2003ms rtt min/avg/max/mdev = 19.367/21.533/24.388/2.106 ms root@UBUNTU-1:~# ip macsec show 8: macsec0: protect on validate strict sc off sa off encrypt off send_sci on end_station off scb off replay off cipher suite: GCM-AES-128, using ICV length 16 TXSC: 5668a5c24c140001 on SA 0 0: PN 15, state on, key 12345678901234567890123456789012 RXSC: 5668a5c237760001, state on 0: PN 15, state on, key 09876543210987654321098765432109 root@UBUNTU-1:~#
As you can see, the packet number increased.
You can also check detailed statistics about the MACsec traffic like this:
root@UBUNTU-1:~# ip -s macsec show 8: macsec0: protect on validate strict sc off sa off encrypt off send_sci on end_station off scb off replay off cipher suite: GCM-AES-128, using ICV length 16 TXSC: 5668a5c24c140001 on SA 0 stats: OutPktsUntagged InPktsUntagged OutPktsTooLong InPktsNoTag InPktsBadTag InPktsUnknownSCI InPktsNoSCI InPktsOverrun 0 0 0 9 0 0 0 0 stats: OutOctetsProtected OutOctetsEncrypted OutPktsProtected OutPktsEncrypted 14 0 1572 0 0: PN 15, state on, key 12345678901234567890123456789012 OutPktsProtected OutPktsEncrypted 14 0 RXSC: 5668a5c237760001, state on stats: InOctetsValidated InOctetsDecrypted InPktsUnchecked InPktsDelayed InPktsOK InPktsInvalid InPktsLate InPktsNotValid InPktsNotUsingSA InPktsUnusedSA 668 0 0 0 6 0 0 0 0 0 0: PN 15, state on, key 09876543210987654321098765432109 InPktsOK InPktsInvalid InPktsNotValid InPktsNotUsingSA InPktsUnusedSA 6 0 0 0 0 root@UBUNTU-1:~#
Two optional features that increase the security on MACsec traffic are encryption and replay protection.
- Encryption – The original payload is encrypted and authenticated
- Replay protection – The packet number of each packet that crossed the MACsec secured link is checked. If there is any packet that arrived out of sequence and the difference between the packet numbers is higher than the replay protection window size, the packet is dropped.
Let’s see how these are configured.
First the encryption:
ip link set macsec0 type macsec encrypt on
Remember that we were at PN 15. Let’s send another 3 packets using ping and then check the statistics:
root@UBUNTU-1:~# ip macsec show 8: macsec0: protect on validate strict sc off sa off encrypt on send_sci on end_station off scb off replay off cipher suite: GCM-AES-128, using ICV length 16 TXSC: 5668a5c24c140001 on SA 0 0: PN 19, state on, key 12345678901234567890123456789012 RXSC: 5668a5c237760001, state on 0: PN 19, state on, key 09876543210987654321098765432109 root@UBUNTU-1:~# ip -s macsec show 8: macsec0: protect on validate strict sc off sa off encrypt on send_sci on end_station off scb off replay off cipher suite: GCM-AES-128, using ICV length 16 TXSC: 5668a5c24c140001 on SA 0 stats: OutPktsUntagged InPktsUntagged OutPktsTooLong InPktsNoTag InPktsBadTag InPktsUnknownSCI InPktsNoSCI InPktsOverrun 0 0 0 23 0 0 0 0 stats: OutOctetsProtected OutOctetsEncrypted OutPktsProtected OutPktsEncrypted 14 4 1572 464 0: PN 19, state on, key 12345678901234567890123456789012 OutPktsProtected OutPktsEncrypted 14 4 RXSC: 5668a5c237760001, state on stats: InOctetsValidated InOctetsDecrypted InPktsUnchecked InPktsDelayed InPktsOK InPktsInvalid InPktsLate InPktsNotValid InPktsNotUsingSA InPktsUnusedSA 668 464 0 0 10 0 0 0 0 0 0: PN 19, state on, key 09876543210987654321098765432109 InPktsOK InPktsInvalid InPktsNotValid InPktsNotUsingSA InPktsUnusedSA 10 0 0 0 0 root@UBUNTU-1:~#
As you can see, we are now at PN 19, which means that actually there were 4 packets that were sent.
Three of them were the ICMP packets and one of them was the ARP Request.
The 4 packets have a total size of 464B. Let’s decompose the ICMP Request packet:
IP – 20B
ICMP – 64B
ICV – 16B
SecTag – 16B
Ethernet – 14
So a total of 130B and this means that 3 ICMP Request packets are 390B, which leave us 74B for the ARP Request packet which is broken down like this:
ARP – 28B
ICV – 16B
SecTag – 16B
Ethernet – 14
Actually doing a tcpdump on UBUNTU-2 while an ICMP Request/Reply was received/sent, you can see that the size is 130B:
root@UBUNTU-2:~# tcpdump -i eth1 tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on eth1, link-type EN10MB (Ethernet), capture size 262144 bytes 07:51:20.389014 56:68:a5:c2:4c:14 (oui Unknown) > 56:68:a5:c2:37:76 (oui Unknown), ethertype Unknown (0x88e5), length 130: 07:51:20.389190 56:68:a5:c2:37:76 (oui Unknown) > 56:68:a5:c2:4c:14 (oui Unknown), ethertype Unknown (0x88e5), length 130: ^C 2 packets captured 2 packets received by filter 0 packets dropped by kernel root@UBUNTU-2:~#
You can also see the MACsec ether-type, 0x88e5.
This is how you can enable the replay protection:
ip link set macsec0 type macsec replay on window 128
You can see that encryption and replay protection are enabled by checking the MACsec configuration:
root@UBUNTU-1:~# ip macsec show 8: macsec0: protect on validate strict sc off sa off encrypt on send_sci on end_station off scb off replay on window 128 cipher suite: GCM-AES-128, using ICV length 16 TXSC: 5668a5c24c140001 on SA 0 0: PN 40, state on, key 12345678901234567890123456789012 RXSC: 5668a5c237760001, state on 0: PN 40, state on, key 09876543210987654321098765432109 root@UBUNTU-1:~#
And this would be the basic configuration that you need to enable MACsec to protect the Layer 2 traffic.
I also tried to enable MACsec on bond links(aggregated interfaces or port-channels how they are named in networking vendors terminology), but I wasn’t able to do it.
In case of bond interfaces, the macsec devices are enslaved instead of the physical links and the macsec devices are created on the physical links. However, I wasn’t allowed to enslave the macsec devices in the bond for some reason.
I hope you found this post useful.
References:
訂閱：
文章 (Atom)
How to repair and clone disk with ddrescue
ddrescue is a tool that can be used to repair and clone disks on a Linux system . This includes hard drives, partitions, DVD discs, flas...
-
From: http://blog.chinaaet.com/justlxy/p/5100064818 SMI：串行管理接口（Serial Management Interface），通常直接被稱為MDIO接口（Management Data Input/Output I...
-
from: https://www.wpgdadatong.com/tw/blog/detail?BID=B0594 一. PHY包含的各個子層 ： PCS：編碼和解碼 PMA：串行器和反序列化器 PMD：取決於物理介質 Firgure 1: OSI模型裡示意...
-
在 前面我們所談的那些可以說是比較基本的東西，但是對於一份文件來說，光有前面所介紹的游標移動、刪除等等功能是不足夠的。面對一份文件我們通常會因為某些 緣故而使得我們必須去修改當中固定出現的字串樣式(pattern)成我們想要的樣子。最常遇到的就像中文文件的標點符號問題，或是 un...
