Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

[Windows] OVSext driver doesn't support discontiguous net buffer on Windows Server 2019 #323

Open
wenyingd opened this issue Mar 21, 2024 · 2 comments
Open

[Windows] OVSext driver doesn't support discontiguous net buffer on Windows Server 2019 #323

wenyingd opened this issue Mar 21, 2024 · 2 comments

Comments

@wenyingd
Copy link

wenyingd commented Mar 21, 2024 •
edited
Loading

Hi OVS dev,

We recently hit an issue with OVSext on Windows, after TCP handshake is completed, the following request packet is dropped by OVS datapath because they are marked as invalid.

Below is a screen shot of the packet capture,

pcap

The traffic topology is like this,

  • we have two VMswitch on the same Windows host, one (vsw1) is controlled by Windows OS without any Extension enabled, and the other (vsw2) is set with OVSext enabled
  • A container is attached to vsw1, which is working as a client
  • We have set IP Forwarding enabled on the gw0 of vsw1, and add routes on the host to support forwarding packets destined at some special IP (10.96.0.1 in my example) to the vnic which is attached on vsw2

Tried to print OVS kernel logs, we saw that the packet is marked as invalid in conntrack by this code . A wonder is the request data (packet) is dis-contiguous in the memory buffer as it was routed on the Windows host before entering OVS, and the existing OVSext assumes the packet data must be contiguous.

According to the Microsoft official document, it looks Windows suggested that networking drivers support header-data split after NDIS 6.0, but OVSext doesn’t have the related support.

Is it possible to modify OVSext driver to support it?
@acolombier
Copy link

I am also experiencing this on Windows Server 2022

@igsilya
Copy link
Member

igsilya commented Mar 22, 2024

Hi. Thanks for the report!

I can be wrong, but it looks like the TCP conntrack handler is actually the only place that is not handling non-contiguous data. If that's true, it should not be hard to fix. Could you try the following change in your setup: igsilya/ovs@3a4f491 ?

Note: only compile-tested in CI, I don't have a windows setup to do any actual testing.

ovsrobot pushed a commit to ovsrobot/ovs that referenced this issue Jun 6, 2024
@igsilya @ovsrobot
datapath-windows: Fix parsing of split buffers in OvsGetTcpHeader.
9323fd9 
NdisGetDataBuffer() is called without providing a buffer to copy packet
data in case it is not contiguous.  So, it fails in some scenarios
where the packet is handled by the general network stack before OVS
and headers become split in multiple buffers.

Use existing helpers to retrieve the headers instead, they are using
OvsGetPacketBytes() which should be able to handle split data.

It might be a bit slower than getting direct pointers that may be
provided by NdisGetDataBuffer(), but it's better to optimize commonly
used OvsGetPacketBytes() helper in the future instead of optimizing
every single caller separately.  And we're still copying the TCP
header anyway.

Fixes: 9726a01 ("datapath-windows: Implement locking in conntrack NAT.")
Reported-at: openvswitch/ovs-issues#323
Signed-off-by: Ilya Maximets <[email protected]>
Signed-off-by: 0-day Robot <[email protected]>
ovsrobot pushed a commit to ovsrobot/ovs that referenced this issue Jul 15, 2024
@pweisong @ovsrobot
datapath-windows: Merge split dis-continuous net-buf.
70ffe65 
NdisGetDataBuffer() is called without providing a buffer to copy packet
data in case it is not contiguous.  So, it fails in some scenarios
where the packet is handled by the general network stack before OVS
and headers become split in multiple buffers.

In the fix it will supply the stack buffer to copy packet data when
call NdisGetDataBuffer().

In the conntrack Action process, it will do OvsPartialCopyNBL firstly
with the size of layers l7offsets. If the header is split the header
will be merged to one continuous buffer.

But IPV6 traffic is not handed in this case.

Reported-at: openvswitch/ovs-issues#323
Signed-off-by: Wilson Peng <[email protected]>
Signed-off-by: 0-day Robot <[email protected]>
ovsrobot pushed a commit to ovsrobot/ovs that referenced this issue Jul 17, 2024
@pweisong @ovsrobot
datapath-windows: Merge split dis-continuous net-buf.
6941a76 
NdisGetDataBuffer() is called without providing a buffer to copy packet
data in case it is not contiguous.  So, it fails in some scenarios
where the packet is handled by the general network stack before OVS
and headers become split in multiple buffers.

In the fix it will supply the stack buffer to copy packet data when
call NdisGetDataBuffer().

In the conntrack Action process, it will do OvsPartialCopyNBL firstly
with the size of layers l7offsets. If the header is split the header
will be merged to one continuous buffer.

But IPV6 traffic is not handed in this case.

Reported-at: openvswitch/ovs-issues#323
Signed-off-by: Wilson Peng <[email protected]>
Signed-off-by: 0-day Robot <[email protected]>
ovsrobot pushed a commit to ovsrobot/ovs that referenced this issue Aug 5, 2024
@pweisong @ovsrobot
datapath-windows: Merge split dis-continuous net-buf.
2c4616b 
NdisGetDataBuffer() is called without providing a buffer to copy packet
data in case it is not contiguous.  So, it fails in some scenarios
where the packet is handled by the general network stack before OVS
and headers become split in multiple buffers.

In the fix it will supply the stack buffer to copy packet data when
call NdisGetDataBuffer().

In the conntrack Action process, it will do OvsPartialCopyNBL firstly
with the size of layers l7offsets. If the header is split the header
will be merged to one continuous buffer.

But IPV6 traffic is not handed in this patch to merge the split
dis-continuous net-buf.
Reported-at: openvswitch/ovs-issues#323

Signed-off-by: Wilson Peng <[email protected]>
Signed-off-by: 0-day Robot <[email protected]>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
3 participants
@wenyingd @acolombier @igsilya