This is fixed via 9171c63532ee9cbc63bb8cfae364ab071f44389b
2.10.4/3/2 will have it
On Thu, Oct 10, 2019 at 6:56 PM txfh2007 via discuss <
ovs-discuss@openvswitch.org> wrote:
> Hi Ben:
> This is my tcpdump result and the userspace datapath cache flow:
>
> Note: the icmp reply got by ovs bridge should have 4 bytes CRC
>
> 09:42:40.883012 fa:16:3e:6c:07:83 > 00:00:0c:9f:f3:ae, ethertype IPv4
> (0x0800), length 98: (tos 0x0, ttl 63, id 7119, offset 0, flags [DF], proto
> ICMP (1), length 84)
> 192.168.1.7 > 10.142.174.254: ICMP echo request, id 2604, seq 116,
> length 64
> 0x0000: 0000 0c9f f3ae fa16 3e6c 0783 0800 4500
> 0x0010: 0054 1bcf 4000 3f01 a49e c0a8 0107 0a8e
> 0x0020: aefe 0800 40d1 0a2c 0074 0fde 9f5d 0000
> 0x0030: 0000 3c80 0200 0000 0000 1011 1213 1415
> 0x0040: 1617 1819 1a1b 1c1d 1e1f 2021 2223 2425
> 0x0050: 2627 2829 2a2b 2c2d 2e2f 3031 3233 3435
> 0x0060: 3637
> 09:42:40.883683 fa:16:3e:0e:d1:15 > fa:16:3e:53:dd:68, ethertype IPv4
> (0x0800), length 102: (tos 0x0, ttl 254, id 7119, offset 0, flags [DF],
> proto ICMP (1), length 84)
> 10.142.174.254 > 192.168.1.7: ICMP echo reply, id 2604, seq 116,
> length 64
> 0x0000: fa16 3e53 dd68 fa16 3e0e d115 0800 4500
> 0x0010: 0054 1bcf 4000 fe01 e59d 0a8e aefe c0a8
> 0x0020: 0107 0000 48d1 0a2c 0074 0fde 9f5d 0000
> 0x0030: 0000 3c80 0200 0000 0000 1011 1213 1415
> 0x0040: 1617 1819 1a1b 1c1d 1e1f 2021 2223 2425
> 0x0050: 2627 2829 2a2b 2c2d 2e2f 3031 3233 3435
> 0x0060: 3637 01a0 af78
>
>
> tunnel(tun_id=0x5,src=10.142.18.11,dst=10.142.18.12,geneve({class=0x102,type=0x80,len=4,0xd30003/0x7fffffff}),flags(-df+csum+key)),rec
> irc_id(0),in_port(15),packet_type(ns=0,id=0),eth_type(0x0800),ipv4(proto=1,frag=no),icmp(type=0),
> packets:41, bytes:4182, used:0.380s,
> actions:ct(zone=4),recirc(0x37)
>
>
> tunnel(tun_id=0x5,src=10.142.18.11,dst=10.142.18.12,geneve({}),flags(-df+csum+key)),ct_state(+inv+trk),recirc_id(0x37),in_port(15),pac
> ket_type(ns=0,id=0),eth_type(0x0800),ipv4(frag=no), packets:211,
> bytes:21522, used:0.342s, actions:drop
>
>
>
>
> Re: Re：[ovs-discuss] [HELP] Question about icmp pkt marked Invalid by
> userspace conntrack
>
>
> On October 10, 2019 5:57:58 PM PDT, txfh2007 <txfh2...@aliyun.com>
> wrote:Hi Ben:
>
> I just found the GCC_UNALIGNED_ACCESSORS error during gdb trace and
> not sure this is a misaligned error or others. What I can confirm is
> during "extract_l4" of this icmp reply packet, when we do "check_l4_icmp",
> the unaligned error emits and the "extract_l4" returned false. So this
> packet be marked as ct_state=invalid.
>
> Thank you for your help.
>
> Timo
>
> Topic：Re: [ovs-discuss] [HELP] Question about icmp pkt marked Invalid by
> userspace conntrack
>
>
> It's very surprising.
>
> Are you using a RISC architecture that insists on aligned accesses? On
> the other hand, if you are using x86-64 or some other architecture that
> ordinarily does not care, are you sure that this is about a misaligned
> access (it is more likely to simply be a bad pointer)?
>
> On Thu, Oct 10, 2019 at 10:50:33PM +0800, txfh2007 via discuss wrote:
> >
> Hi all:
> I was using OVS-DPDK(version 2.10-1), and I have found pinging between
> two VMs on different compute nodes failed. I have checked my env and found
> there is one node's NIC cannot strip CRC of a frame, the other node's NIC
> is normal(I mean it can strip CRC ). And the reason of ping fail is the
> icmp reply pkt (from node whose NIC cannot strip CRC) is marked as invalid
> . So the icmp request From Node A is 64 bytes， but the icmp reply From Node
> B is 68 bytes(with 4 bytes CRC). And when doing "check_l4_icmp", when we
> call csum task(in lib/csum.c). Gcc emits unaligned accessor error. The
> backtrace is as below:
>
> I just want to confirm if this phenomenon is reasonable?
>
> Many thanks
>
> Timo
>
>
> get_unaligned_be16 (p=0x7f2ad0b1ed5c) at lib/unaligned.h:89
> 89 GCC_UNALIGNED_ACCESSORS(ovs_be16, be16);
> (gdb) bt
> #0 get_unaligned_be16 (p=0x7f2ad0b1ed5c) at lib/unaligned.h:89
> #1 0x000000000075a584 in csum_continue (partial=0, data_=0x7f2ad0b1ed5c,
> n=68) at lib/csum.c:46
> #2 0x000000000075a552 in csum (data=0x7f2ad0b1ed5c, n=68) at lib/csum.c:33
> #3 0x00000000008ddf18 in check_l4_icmp (data=0x7f2ad0b1ed5c, size=68,
> validate_checksum=true) at lib/conntrack.c:1638
> #4 0x00000000008de650 in extract_l4 (key=0x7f32a20df120,
> data=0x7f2ad0b1ed5c, size=68, related=0x7f32a20df15d, l3=0x7f2ad0b1ed48,
> validate_checksum=true) at lib/conntrack.c:1888
> #5 0x00000000008de90d in conn_key_extract (ct=0x7f32b42a2d98,
> pkt=0x7f2ad0b1e9c0, dl_type=8, ctx=0x7f32a20df120, zone=4)
> at lib/conntrack.c:1973
> #6 0x00000000008dd49c in conntrack_execute (ct=0x7f32b42a2d98,
> pkt_batch=0x7f32a20e08b0, dl_type=8, force=false, commit=false,
> zone=4, setmark=0x0, setlabel=0x0, tp_src=0, tp_dst=0, helper=0x0,
> nat_action_info=0x0, now=5395897849) at lib/conntrack.c:1318
> #7 0x000000000076d651 in dp_execute_cb (aux_=0x7f32a20dfb00,
> packets_=0x7f32a20e08b0, a=0x7f32a20e0ac8, should_steal=false)
> at lib/dpif-netdev.c:6711
> #8 0x00000000007b2d49 in odp_execute_actions (dp=0x7f32a20dfb00,
> batch=0x7f32a20e08b0, steal=true, actions=0x7f32a20e0ac8,
> actions_len=20, dp_execute_action=0x76ca60 <dp_execute_cb>) at
> lib/odp-execute.c:726
> #9 0x000000000076d71b in dp_netdev_execute_actions (pmd=0x7f2a6e1ce010,
> packets=0x7f32a20e08b0, should_steal=true,
> flow=0x7f32a20dfb60, actions=0x7f32a20e0ac8, actions_len=20) at
> lib/dpif-netdev.c:6754
> #10 0x000000000076b900 in handle_packet_upcall (pmd=0x7f2a6e1ce010,
> packet=0x7f2ad0b1e9c0, key=0x7f32a20e1100,
> actions=0x7f32a20e0a40, put_actions=0x7f32a20e0a80) at
> lib/dpif-netdev.c:6056
> #11 0x000000000076bdf0 in fast_path_processing (pmd=0x7f2a6e1ce010,
> packets_=0x7f32a20e2b60, keys=0x7f32a20e10c0,
> batches=0x7f32a20e0f90, n_batches=0x7f32a20e13c0, in_port=15) at
> lib/dpif-netdev.c:6153
> #12 0x000000000076c3df in dp_netdev_input__ (pmd=0x7f2a6e1ce010,
> packets=0x7f32a20e2b60, md_is_valid=true, port_no=0)
> at lib/dpif-netdev.c:6230
> #13 0x000000000076c4d4 in dp_netdev_recirculate (pmd=0x7f2a6e1ce010,
> packets=0x7f32a20e2b60) at lib/dpif-netdev.c:6265
> #14 0x000000000076ceae in dp_execute_cb (aux_=0x7f32a20e1db0,
> packets_=0x7f32a20e2b60, a=0x7f32a20e2d78, should_steal=true) discuss
> mailing list
> disc...@openvswitch.org
> https://mail.openvswitch.org/mailman/listinfo/ovs-discuss
>
>
> Ok. Is there a particular packet we can use to reproduce it?
>
> _______________________________________________
> discuss mailing list
> disc...@openvswitch.org
> https://mail.openvswitch.org/mailman/listinfo/ovs-discuss
>
_______________________________________________
discuss mailing list
disc...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss
