@@ -493,15 +493,33 @@ static __inline NDIS_STATUS
OvsDetectCtPacket(OvsForwardingContext *fwdCtx,
OvsFlowKey *key)
{
+ NDIS_STATUS status = NDIS_STATUS_SUCCESS;
+ OvsFlowKey newFlowKey = { 0 };
+
switch (ntohs(key->l2.dlType)) {
case ETH_TYPE_IPV4:
if (key->ipKey.nwFrag != OVS_FRAG_TYPE_NONE) {
- return OvsProcessIpv4Fragment(fwdCtx->switchContext,
+ status = OvsProcessIpv4Fragment(fwdCtx->switchContext,
&fwdCtx->curNbl,
fwdCtx->completionList,
fwdCtx->fwdDetail->SourcePortId,
&fwdCtx->layers,
key->tunKey.tunnelId);
+ if (status == NDIS_STATUS_SUCCESS) {
+ /*after the Ipv4 Fragment is reassembled, update flow key as
+ L3 and L4 headers are not correct */
+ status =
+ OvsExtractFlow(fwdCtx->curNbl, fwdCtx->srcVportNo,
+ &newFlowKey, &fwdCtx->layers,
+ fwdCtx->tunKey.dst != 0 ? &fwdCtx->tunKey : NULL);
+ if (status != NDIS_STATUS_SUCCESS) {
+ OVS_LOG_INFO("Extract flow failed status %d Nbl %p",
+ status, fwdCtx->curNbl);
+ return status;
+ }
+ *key = newFlowKey;
+ }
+ return status;
}
if (key->ipKey.nwProto == IPPROTO_TCP
|| key->ipKey.nwProto == IPPROTO_UDP
While testing OVS-windows flows for the Ip fragments, the traffic will be dropped As it may match incorrect OVS flow. From the code, after the Ipv4 fragments are Reassembled, it willl still use the flow key of the last Ipv4 fragments to match CT causing match error. Reported-at:https://github.com/openvswitch/ovs-issues/issues/232 Signed-off-by: Wilson Peng <pweisong@vmware.com> --- datapath-windows/ovsext/Conntrack.c | 20 +++++++++++++++++++- 1 file changed, 19 insertions(+), 1 deletion(-)