Skip to main content

· One min read

針對我所要用的編譯器 還有 執行檔 定義一些所需要的 set path

在命令提示字元底下一定要找得到以下幾個可執行的程式: nmake cl vcvars32.bat

我的電腦按右鍵 -> 內容 -> 進階 -> 環境變數 -> 系統變數 -> 編輯 path, 加入 C:\Program Files\Microsoft Visual Studio .NET 2003\Vc7\bin;

切換到目錄，執行 vcvars32.bat 以設定 vc71 環境. 若 path 變數未設好，則會出現找不到這檔案的訊息. 接著執行 m.bat 編譯即可.

若發生問題，可以試著鍵入 makemake 重新產生 makefiles. 再打入 nmake -f makefile.vc depend 確認相依性. 之後再執行 m.bat 重新編譯一次即可

參考網址 http://java.csie.nctu.edu.tw/~deryann/paper/HowToSTL.htm

· 2 min read

11th. Part: IPv4d/IPProcessing 模組功能等同 IPv4/IP 模組

因此 IPv4 資料夾即已實作 IPv4 協定 IPv4d 資料夾內程式則是將 IP 模組內容拆開成多個子模組， 以此推論，若模擬的目標是 IP 協定運作情形， 單單只看到 IP 模組並不能滿足要求時， 則將 Nodes/INET/ 各 .ned 檔中的 "IP" 改成 "IPProcessing" 應該 就可以看到更詳細的 IP 協定運作情形。建議名稱: Routerd / Router6d?

節點先做 Nodes/INET6/BurstHost6 與 Router6, StandardHost6 稍後再處理

  • 要寫自行設定模組的 Tutorial

12th. Part: INET 比 NS2 好的特色: FlatNetworkConfigurator, 只需指定網域 / 遮罩， INET 即自動配置各節點模擬用的位址.

  • 要研究 AutoRouting 中 FlatNetworkConfigurator 的做法 (怎麼與 ND 互補？(有 ND 那 FlatNetworkConfigurator 就不應作用於 '*Host' 上) ex:
  • 決定 Prefix/Prefix Lenth (Subnetmask),
  • 設定啟不啟動 DAD 等)

Neighbor Discovery vs ARP IPv6d/ND 將作為一個模組來對應 NetworkInterfaces/ARP

IP protocol header is represented by the IPDatagram message class

· One min read

(討論區整理得)

如果是已經 Compiler 過的 ns2, 則改 Makefile 然後在 ns2 的目錄下 例如: ns2.2x 則是在 ns-2.2x 目錄下執行

#make depand #make

這樣就可以從新 compiler ns2 並且加入自己的模組

如果想要加入自己寫的程式，則可以修改 ns2 的 Makefile 如果是還未 Compiler 過的 ns2, 則修改 Makefile.in 然後依照 ns2 的安裝說明來安裝

· 4 min read

9th. Part: 編輯 IP6Datagram.msg 參考 IANA 上PROTOCOL NUMBERS 來改寫 IP6Datagram.msg

Protocol field -> Next Header field 因此 enum 名稱 IP6ProtocolFieldId 改成 IP6NextHeaderFieldId

IPv4 上叫 Protocol field, IPv6 上稱 Next Header field 為了相容性，將原本定義的 Protocol field 全保留之外，另外新增

  • IP6_PROT_IPv6_Route = 43; //Routing Header for IPv6 [Deering]
  • IP6_PROT_IPv6_Frag = 44; //Fragment Header for IPv6 [Deering]
  • IP6_PROT_ESP = 50; //Encap Security Payload [RFC2406]
  • IP6_PROT_AH = 51; //Authentication Header [RFC2402]
  • IP6_PROT_IPv6_ICMP = 58; //ICMP for IPv6 [RFC1883] IP6_PROT_NONE = 59; --> IP6_PROT_NoNxt = 59; //No Next Header for IPv6 [RFC1883]
  • IP6_PROT_Opts = 60; //Destination Options for IPv6 [RFC1883]
  • IP6_PROT_ENCAP = 98; //Encapsulation Header [RFC1241,RXB3]

除了這些之外，順便把一些 Routing protocol 的號也加了上去.

IP6_PROT_IPv6_MOBILITY 原本給 62, 改成 IP6_PROT_IPv6_MOBILITY = 135; //Mobility Header for IPv6 [RFC3775]

從一串配給號碼中發現比較特別的是

61                 any host internal protocol           [IANA]
63                 any local network                    [IANA]
68                 any distributed file system          [IANA]
99                 any private encryption scheme        [IANA]
114                any 0-hop protocol                   [IANA]

剛開始看不知有何特別作用，後來想想這幾個保留位看起來對模擬工具好像不賴 --> 有新協定要試作？ 不必改到標頭定義，暫時先用這幾個吧！ 不過沒有標頭名稱怎麼辦？ Orz ..... 還是暫時不要加進去好了

本檔案編完的下一步應是編輯 IP6Address.h 或 IP6ControInfo.msg 吧

Ref: IP VERSION 6 PARAMETERS , ICMPv6 TYPE NUMBERS

10th. Part:

編輯 IP6Datagram.msg 中的 message IP6Datagram : 參考 IPv6Suite IP6Datagram.cc 來改寫 IP6Datagram.msg

ToDo: 1. 將相關各標頭定義在檔案裡. 2. 定義 flow_label 結構 (struct, 20 bit = double + short OR int + int + short OR?) 3. 訂 Options Types

IP6Datagram.cc 中標頭是如此定義出來的:

static const ipv6_hdr IPV6_INITIAL_HDR = { 0x60000000, //version 6, traffic class of 0, flow label of 0 0, //payload of 0 59, //No next header yet 0, //Hop Limit set to uninitialised IPv6_ADDR_UNSPECIFIED, IPv6_ADDR_UNSPECIFIED };

完整的標頭:

message IP6Datagram
{
 properties:
     //g Still unknown its func
     omitGetVerb = true;
 fields:
     short version            = 6;                               // version 6
     int traffic_class        = 0;                               // traffic class of 0
     IP6FlowLabel flow_label;                                    // flow label of 0
     double payload_length    = 0;                               // payload of 0
     int next_header enum(IP6NextHeaderFieldId) = IP_PROT_NONxt; // No next header yet
     int hop_limit            = 0;                               //Hop Limit set to uninitialised
     IP6Address srcAddress;
     IP6Address destAddress;
}

即將碰到 day 3 提到的 延伸標頭處理 問題. RFC2460 上的敘述是這樣的

4.1 Extension Header Order [Page 6] When more than one extension header is used in the same packet, it is recommended that those headers appear in the following order:

IPv6 header Hop-by-Hop Options header Destination Options header (note 1) Routing header Authentication header (note 2) Encapsulating Security Payload header (note 2) Destination Options header (note 3) upper-layer header Fragment header

填 class IP6Options, 碰到 Option_Data: Variable-length field. Option-Type-specific data 的問題

經 majorlee 學長指點 RFC 3493 Basic Socket Interface Extensions for IPv6. RFC 3542 Advanced Sockets Application Program Interface (API) for IPv6 裡可能會有答案.