2017/11/15_OVS+DPDK取5-tuple

1. 位置如當初所想，在emc_processing()裡面的miniflow_extract()。

用 ovs 2.8.0 版本，非大叔的 ovs 2.6.0。因為當初 ovs 2.6.0 裝不起來。但兩個版本在flow.c檔案中無太大差異，要改很快。

2. 可以取得src_ip / dst_ip (是ovs_16aligned_be32格式，非int，強迫用%d顯示有點問題，有時候會拿到負值)。

已解決!

用 %ld 可解決，因為 int 範圍 -2147483648 ~ 2147483647，但4211081440 (251.0.0.224) 比最大值大，會繞兩圈最後變負值。

詳見附註2

3. Length的值只有L3 Layer的長度，不含L2 Layer。

ip_len == L3 Header length >> ICMP Request/Respond >> 20 bytes

tot_len == L3 Total length >> ICMP Request/Respond >> 84 bytes [Frame Length is 98 bytes here]

nh->ip_tot_len == 不知道是什麼值

詳見附註3

4. 整理了ovs+dpdk install 步驟。

5.只解 IPv4 ，不解 ARP 跟 IPv6 。

因為只解 ipv4 ， 不解 ARP / ipv6。

若ping 10.0.0.100 只會有ARP request封包，沒有人回，所以沒有ICMP request封包，所以也就沒有解析出來。

6.測試方式，由Host 1 經由 OVS ping Host 2，或由Host 2 經由 OVS tracereply 16個封包到 Host 1。

Host 1 經過 OVS ping Host 2 >> 正常，ICMP封包都有收到。

Host 2 經過 OVS tracereply 16個封包到 Host 1 >> 16個封包只有解析到其中2個????

已解決。 #752 ~ #769行，把一些不符合長度的封包濾掉了。

附註2

在 types.h 檔案內

/* A 32-bit value, in network byte order, that is only aligned on a 16-bit

 * boundary. */

typedef struct {

        ovs_be16 hi, lo;

} ovs_16aligned_be32;

le 跟 be 分別表示little endian和big endian。

/* The ovs_be<N> types indicate that an object is in big-endian, not

 * native-endian, byte order.  They are otherwise equivalent to uint<N>_t. */

typedef uint16_t OVS_BITWISE ovs_be16;

typedef uint32_t OVS_BITWISE ovs_be32;

typedef uint64_t OVS_BITWISE ovs_be64;

#define OVS_BITWISE __attribute__((bitwise))

負值原因分析

224.0.0.251 (MDNS) >> 4211081440 (251.0.0.224)

224.0.0.22 (IGMPv3) >> 369098976

int ( 32 bits)：-2147483648 ~ 2147483647 (%d) (%i)

印出 unit32_t 的方法有以下兩種