> Currently the layers info propogated to ProcessDeferredActions may be > incorrect. Because of this, any subsequent usage of layers might result > in undesired behavior. Accordingly in this patch it will add the related > layers in the deferred action to make sure the layers consistent with > the related NBL. > > In the specified case 229, we have encountered one issue when doing > the decap Geneve Packet and doing the twice NAT(via two flow tables) > and found the HTTP packet will be changed the TCP sequence. > > After debugging, we found the issue is caused by the not-updated > layers value isTcp and isUdp for Geneve decapping case. > > The related function call chains are listed below, > > OvsExecuteDpIoctlâ>OvsActionsExecuteâ>OvsDoExecuteActions->OvsTunnelPortRx > ââ>OvsDoExecuteActionsââãnat ct action and recircle action > ->OvsActionsExecute->defered_actions processing for nat and recircle action > > For the Geneve packet decaping, it will firstly set the layers for Udp packet. > Then it will go on doing OVS flow extract to get the inner packet layers and > Processing the first nat action and first recircle action. After that datapath > Will do defered_actions processing on OvsActionsExecute. And it does inherit > The incorrect geneve packet layers value( isTCP 0 and isUdp 1).So in the > second > Nat action processing it will get the wrong TCP Headers in > OvsUpdateAddressAndPort > And it will update related TCP check field value but in this case it will > change > The packet Tcp seq value. > > Reported-at:https://github.com/openvswitch/ovs-issues/issues/229 > Signed-off-by: Wilson Peng <[email protected]> > --- >
Thank you for tracking down the issue and fixing it! I applied the patch and backported until branch-2.13. If you want me to apply it further back please let me know.
_______________________________________________ dev mailing list [email protected] https://mail.openvswitch.org/mailman/listinfo/ovs-dev
