Trunk模式的數(shù)據(jù)包iph->version異常

tough_lion

最近基于網(wǎng)橋 + NatFilter分析Trunk模式發(fā)來的數(shù)據(jù)包.  發(fā)現(xiàn)其中 iph->version為0, 正常應(yīng)為iph->version:4

對于Trunk模式的數(shù)據(jù), 在代碼中是先移位4的, 請問各位有沒有遇到同類問題:

tough_lion

                     這是移位代碼:
                          if(skb->protocol==htons(ETH_P_8021Q))
                {
                        iph=(struct iphdr *)((u8*)iph+4);                       
                }

nswcfd

bridge在調(diào)inet_netfilter之前，應(yīng)該已經(jīng)把nh+4（指向iphdr）[@net/bridge/br_netfiler.c]，所以在hook里面是不需要再次偏移的。

tough_lion

在Trunk模式下, 實際收到的iph->version為0, 說明這個數(shù)據(jù)包還是有問題, 請問應(yīng)如何解析來自Trunk模式下的數(shù)據(jù)包?

nswcfd

回復 4# tough_lion

建議先假設(shè)數(shù)據(jù)包是沒有問題的（正常的帶tag的ip報文），在你的抓包點里把從skb->head到skb->data+32這個區(qū)間的數(shù)據(jù)打印出來，
人為判斷mac頭在什么地方，vlan頭在什么地方，ip頭在什么地方，然后跟skb_network_header、skb->data比較，
這樣就能知道在你的抓包點，skb的各個字段是否需要偏移了。


   

jasonew

可以去看我帖子里的源碼

http://72891.cn/thread-4171778-1-1.html

tough_lion

回復 6# jasonew


    你帖子里并沒有源碼, 方便再給我個鏈接嗎?

tough_lion

回復 5# nswcfd


   感謝, 我先試試, 另外Trunk模式下, 應(yīng)該是公共標準, 即移動4位吧?

jasonew

回復 7# tough_lion



二層數(shù)據(jù)包 如果帶VLAN TAG的話，那就是數(shù)據(jù)頭指針P + 18 得到IP頭指針的位置 struct iphdr *iph = (struct iphdr*)(pData + 1;，然后可以根據(jù)協(xié)議，比如IPPROTO_TCP == iph->protocol，那么 struct tcphdr *tcph = (struct tcphdr*)(iph + 1)，UDP 一樣，換個結(jié)構(gòu)體就好

如果是正常的二層數(shù)據(jù)包，那么數(shù)據(jù)頭指針P + 14 得到IP頭指針的位置struct iphdr *iph = (struct iphdr*)(pData + 14);，其他都一樣