On 06/15/2017 12:31 PM, Jason Wang wrote:
On 2017年06月14日 16:04, Zhang Chen wrote:
On 06/13/2017 05:14 PM, Jason Wang wrote:
On 2017年06月12日 17:27, Zhang Chen wrote:
+ if (nf->direction == NET_FILTER_DIRECTION_RX ||
+ nf->direction == NET_FILTER_DIRECTION_ALL) {
+ vnet_hdr_len = nf->netdev->vnet_hdr_len;
This can only work if e.g virtio-net set its own vnet_hdr_len. But
looks like it use guest_hdr_len instead.
I see in hw/net/virtio-net.c use the
"qemu_set_vnet_hdr_len(nc->peer, n->guest_hdr_len);" to
set the nf->netdev->vnet_hdr_len, any case not include here?
You mean:
if (peer_has_vnet_hdr(n) &&
qemu_has_vnet_hdr_len(nc->peer, n->guest_hdr_len)) {
qemu_set_vnet_hdr_len(nc->peer, n->guest_hdr_len);
n->host_hdr_len = n->guest_hdr_len;
}
?
From the code, it only set peer's vnet header when peer supports
vnet_hdr up to n->guest_hdr_len. If peer can't, virtio-net will
strip the header.
So, We should get the n->guest_hdr_len in another way? like set a new
parameter in NetClientState?
Any suggestion about it?
Thanks
Zhang Chen
Rethink about this, a question is do we really care guest vnet header
len? During guest transmission, when packet reaches netfilter. The
vnet_header should have been stripped to netdev->vnet_hdr_len.
But we use filter-redirector send packet to colo-compare that get the
packet with the vnet header.
That is colo-compare see:
1241@1497507100.108799:colo_compare_pkt_info_src src/dst: 192.168.4.144
s: seq/ack=2181260317/2075177759 res=0 flags=18 spkt_size: 95
1241@1497507100.108803:colo_compare_pkt_info_dst src/dst: 192.168.4.88
d: seq/ack=2181260317/2075177759 res=0 flags=18 dpkt_size: 95
colo-compare ppkt: 0000: 01 00 00 00 00 00 22 00 10 00 00 00 12 14
fc 1d ......".........
colo-compare ppkt: 0010: 1a 6b 52 54 00 12 34 56 08 00 45 00 00 45
12 61 .kRT..4V..E..E.a
colo-compare ppkt: 0020: 40 00 40 06 9e 19 c0 a8 04 90 c0 a8 04 58
04 d2 @.@..........X..
colo-compare ppkt: 0030: ca 98 82 03 64 1d 7b b0 b3 1f 80 18 00 e3
8a 70 ....d.{........p
colo-compare ppkt: 0040: 00 00 01 01 08 0a 00 00 5b fa 00 4d f1 aa
73 65 ........[..M..se
colo-compare ppkt: 0050: 72 76 65 72 20 67 65 74 20 69 74 20 34 36
38 rver get it 468
colo-compare spkt: 0000: 01 00 00 00 00 00 22 00 10 00 00 00 12 14
fc 1d ......".........
colo-compare spkt: 0010: 1a 6b 52 54 00 12 34 56 08 00 45 00 00 45
12 61 .kRT..4V..E..E.a
colo-compare spkt: 0020: 40 00 40 06 9e 19 c0 a8 04 90 c0 a8 04 58
04 d2 @.@..........X..
colo-compare spkt: 0030: ca 98 82 03 64 1d 7b b0 b3 1f 80 18 00 e3
8a 70 ....d.{........p
colo-compare spkt: 0040: 00 00 01 01 08 0a 00 00 5c 02 00 4d f1 aa
73 65 ........\..M..se
colo-compare spkt: 0050: 72 76 65 72 20 67 65 74 20 69 74 20 34 36
38 rver get it 468
So, colo-compare need to know the vnet_hdr_len for skip this field, then
colo-compare
can parse the net packet correctly.
Back to this patch, how should I fix it?
Thanks
Zhang Chen
I still think use nf->netdev->vnet_hdr_len is sufficient.
Thanks
Thanks
.
--
Thanks
Zhang Chen
