第一次看到以太網物理地址格式時，感覺很平淡。像看到IPV4和IPV6報文的標頭部分一樣沒有感覺。但真正去理解以太網物理地址某些比特含義時，是在幾年前的一次吹牛中體會到的。這次吹牛，差點毀掉了一直以來信譽良好的好名聲。

事情起源

在本文章中，曾經提到過，TSN(Time Sensitive Networking,TSN)和TTE(Time-Triggered Ethernet)的起源及應用領域，在那篇文章中，還提到了可以嘗試著把TTE看作是密閉空間內使用的TSN的說法。事實上，這種說法是非常不準確的。二者雖然都對業(yè)務進行了是否實時性的區(qū)分，但實現時卻采用了截然不同的兩種方法。

TTE和TSN實時業(yè)務的保障方式

1、保障業(yè)務的實時性采用的是調度表的方式，對TT業(yè)務的收發(fā)嚴格按照調度表執(zhí)行；詳見上一篇公眾號文章：一個人，一個想法，一家公司和即將被改變的全世界網絡

2、TSN中對業(yè)務實時性保障的方式不是通過調度表的方式，而是提供資源預留，即流預留協(xié)議(SRP)。TSN中的流預留協(xié)議(SRP)包括廣播、注冊和解注冊三步。在流的整個傳輸路徑上采用協(xié)商機制，提前保留出流量傳輸所需要的帶寬，如果交換端口帶寬允許，則建立連接，否則連接失敗。 同時SRP協(xié)議規(guī)定將75%的帶寬分配給實時流量，25%的帶寬分配給盡力傳BE流量，所以TSN為低優(yōu)先級流量的發(fā)送提供了機會，某種程度上可以緩解低優(yōu)先級流量“饑餓”現象。（關于TSN的帶寬預留機制可以參見IEEE 802.1Qat和Qcc標準）。

而本文所說的事情就與TSN中的資源預留協(xié)議的實現相關。準確的說是與車載時間敏感網絡中的IEEE802.1Qat協(xié)議相關，即多流注冊協(xié)議(Multiple Stream Registration Protocol,MSRP)。

任務要求

當時接到的任務是，通過XILINX的通用Zedboard開發(fā)平臺（本公眾號所有案例均在此平臺上實現），實現兩種數據幀的捕獲操作。

捕獲過程是指：數據幀通過網口進入FPGA，然后由FPGA通過字段匹配出需要提交給CPU的某種類型的數據幀，然后將該數據幀通過中斷的方式提交給CPU進行分析。

需要捕獲交給CPU的幀類型有兩種：1、MSRP報文：目的MAC為01-80-C2-00-00-0E，以太網類型為0x22EA；2、MVRP報文：目的MAC為01-80-C2-00-00-21，以太網類型為0x88F5；

要求：搭建一個演示平臺，通過CPU可以配置FPGA內部用來識別捕獲幀特征的寄存器，數據幀的類型和目的MAC地址可任意配置，然后將上述兩種FPGA內部產生的數據幀通過捕獲通道交給CPU。

看到了上述任務要求后感覺很簡單，這種事情做過的太多了。從HINOC項目到各種定制的星載交換系統(tǒng)，都有類似的需求。于是在被人問需要多久做好時，毫不猶豫的爽快的說道：很簡單，明天就給你！

出現問題

接到任務是下午，吃過晚飯后就找了兩個學生開干。Zedboard板子以及操作系統(tǒng)環(huán)境甚至連FPGA的代碼基本都是現成的，需要做的只是少許修改，首先要實現通過操作系統(tǒng)去配置FPGA上相應的寄存器內容（MAC地址寄存器），但就在Linux操作系統(tǒng)嘗試著通過TCP/IP協(xié)議棧配置FPGA的MAC地址時就出現了問題，一般的MAC地址都能很容易的配置成功，但就是前面需要捕獲給CPU的MAC，也就是MSRP報文和MVRP報文都不能配置成功。

經過反復的嘗試，發(fā)現MAC地址第一個字節(jié)最低位為1的MAC地址都無法正確配置。每次都返回set mac fail。

但在設置第一個字節(jié)最低位為0的地址時，都能夠設置成功。

調試中遇到問題是家常便飯，對于第一次遇見這樣奇怪的問題，一下子激起了大家的好奇心。決定一定要弄明白是怎么回事。

分析及查找問題

1、分析問題

通過Linux命令行配置目的MAC地址失敗，原因肯定在該數據的通路上。這個配置數據經過命令行輸入后，會依次經過TCP/IP協(xié)議棧、驅動，然后再由AXI總線寫入FPGA內部自定義的MAC寄存器。如果出現問題，那么肯定是這個通路沒有走通。那到底是哪一步沒有走通呢？

2、查看FPGA內部寄存器是否被正確寫入

為了定位問題，我們先從FPGA內部Verilog代碼描述的專門接收操作系統(tǒng)配置下來的目的MAC寄存器查起。為了定位，我們把該寄存器及相關的寫操作及寄存器內容都作為ChipScope的監(jiān)測信號。在命令行輸入配置信息后，看寫該寄存器的寫使能信號是否被觸發(fā)，結果發(fā)現在寫命令輸入之后，寫使能信號沒有被觸發(fā)，該寄存器值仍然是復位值。也就是說，MAC地址沒有寫入FPGA內部的相應寄存器中，甚至連寫該寄存器的動作都沒有。

3、看驅動是否接收到命令行給出的配置數據

從操作系統(tǒng)Linux命令行給出來的配置MAC指令，經過操作系統(tǒng)處理之后，最后肯定要寫到驅動上，由驅動執(zhí)行寫FPGA內部寄存器的動作才能把數據寫入FPGA內部寄存器。這里的驅動，屬于我們自己寫的SNMP網管軟件的一部分，SNMP網管功能主要包括驅動和應用程序兩個部分，這里的應用程序大家可以簡單的理解為就是剛才的命令行輸入的配置目的MAC地址的指令。而驅動則包括字符型驅動和網絡設備驅動兩部分。字符型驅動一般用來與應用程序進行交互。而網絡設備驅動，主要是插入捕獲功能等，本文開始提到的捕獲MSRP報文及MVRP報文就是通過網絡設備驅動執(zhí)行的。

于是，修改C代碼，在字符驅動相關函數中加入打印信息，命令行配置目的MAC地址后，該驅動函數未被調用。也就是說，配置信息連驅動層面都沒有到，下一步就猜測：有可能配置的目的MAC地址被TCP/IP協(xié)議棧給過濾掉了。

定位問題

經過上述分析和查找定位，基本上定位在配置的目的MAC地址可能被TCP/IP協(xié)議棧給過濾掉了。這個時候我們才想起來，會不會是我們給出的目的MAC地址不合法啊？為什么總是第一個字節(jié)最低位為1的目的MAC地址會被TCP/IP協(xié)議棧過濾掉（文中開頭提到的MVRP和MSRP報文MAC地址的第一個字節(jié)最低位都為1）呢？

我們先來看一下MAC地址的定義及每一個bit的含義吧。

MAC地址含義

1、MAC地址是48bit二進制的地址，前24位為供應商代碼，后24為序列號；2、單播地址：第一字節(jié)最低位為0，如00-e0-fc-00-00-06；3、多播地址：第一字節(jié)最低位為1，如01-e0-fc-00-00-06；4、廣播地址：48位全1，如ff-ff-ff-ff-ff-ff。

通過上面的描述，基本確認了問題，也就是說TCP/IP協(xié)議棧會把第一個字節(jié)最低位為1的MAC地址，也就是多播地址，自動的給過濾掉。會把配置多播地址為某個板子的MAC地址的Linux指令定義為無效指令。

找到并定位到問題以后，已經晚上12點了。。。原本以為半小時就能搞定的問題，竟然花了四個小時才定位到問題。

解決問題

既然TCP/IP協(xié)議棧會把這類MAC地址過濾掉，那么我們不走TCP/IP協(xié)議棧不就可以了嗎？

好在之前做過的項目中預留了可以旁路掉TCP/IP協(xié)議棧的通路，直接將配置數據交給驅動，寫進FPGA相應的寄存器中。

這樣，捕獲給CPU的觸發(fā)條件，也就是MAC地址就順利的配到FPGA內部了。好在，捕獲通道很順利，很容易的就把目的地址為任意MAC地址的以太網幀都順利的交給CPU了。（因為當時未保留MVRP和MSRP報文捕獲成功的截圖，隨便找了一張上課演示的圖片）

等一切都搞定的時候，已經到了凌晨一點多了。

哦，對了。本文中需要將Zedboard開發(fā)板設置為從SD卡啟動模式，板子上的跳帽位置如下：

同時，在這種模式下，不加載操作系統(tǒng)的純FPGA代碼上板調試是不受影響的。

結論

1、無論任何時候，都不要隨便的說大話。要保持低調且謙虛謹慎的態(tài)度去面對任何一次科學實驗；

2、MAC地址中第一個字節(jié)的最低位為1表示該地址是組播地址，是不能通過操作系統(tǒng)經過TCP/IP協(xié)議棧配置給FGPA板子的。這是文中的結論，求大佬們給出更專業(yè)的解釋。

3、本文是日常項目調試中出現的眾多問題中非常普通的一個，希望大家也能夠養(yǎng)成問題記錄的好習慣，引用一位跟我同名同姓老鄉(xiāng)的話來說就是：日有寸進，得寸進尺，日積月累，必有所成！