[ovs-discuss] [HELP] Question about icmp pkt marked Invalid by userspace conntrack

[Ben Pfaff]

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
> discuss at openvswitch.org
> https://mail.openvswitch.org/mailman/listinfo/ovs-discuss