Message ID | 20210927135727.11512-1-pweisong@vmware.com |
---|---|
State | Superseded |
Headers | show |
Series | [ovs-dev,ovs-dev,v1,1/1] datapath-windows:adjust Offset when processing packet in POP_VLAN action | expand |
Context | Check | Description |
---|---|---|
ovsrobot/apply-robot | success | apply and check: success |
ovsrobot/github-robot-_Build_and_Test | fail | github build: failed |
diff --git a/datapath-windows/ovsext/Actions.c b/datapath-windows/ovsext/Actions.c index e130c2f96..a9e486752 100644 --- a/datapath-windows/ovsext/Actions.c +++ b/datapath-windows/ovsext/Actions.c @@ -1122,6 +1122,13 @@ OvsPopFieldInPacketBuf(OvsForwardingContext *ovsFwdCtx, if (bufferData) { *bufferData = bufferStart + shiftLength; + } else { + /* Currently !bufferData means it should be treated as VLAN; + * Adjust layers Offset value as the vlan tag is removed + */ + OVS_PACKET_HDR_INFO *layers = &ovsFwdCtx->layers; + layers->l3Offset -= (UINT16)shiftLength; + layers->l4Offset -= (UINT16)shiftLength; } return NDIS_STATUS_SUCCESS;
In one typical setup, on the Windows VM running OVS Windows Kernel, a Geneva packet with 8021.q VLAN tag is received. Then it may do POP_VLAN action processing in Actions.c, if the packet does not have Ieee8021QNetBufferListInfo in the oob of the packet, it will be processed by function OvsPopVlanInPktBuf(). In the function it will go on remove VLAN header present in the nbl, but related layers is never readjusted for the offset value at this moment. As a result, it will cause function OvsValidateIPChecksum drop the packet. Reported-at:https://github.com/openvswitch/ovs-issues/issues/225 Signed-off-by: wilsonpeng <pweisong@vmware.com> --- datapath-windows/ovsext/Actions.c | 7 +++++++ 1 file changed, 7 insertions(+)