summaryrefslogtreecommitdiff
path: root/datapath-windows
Commit message (Collapse)AuthorAgeFilesLines
* datapath-windows: Check the condition to reset pseudo header checksum on Rx sideWilson Peng2022-11-241-4/+23
| | | | | | | | | | | | | | | If ovs node running on Windows is processing NAT action on the RX side, it will reset pseudo header checksum only if the L4 checksum is same as the calculated pseudo header checksum before NAT action. Without the fix, if the L4 header checksum is filled with a pseudo header checksum (sourceip, dstip, protocol, tcppayloadlen+tcpheaderlen) OVS will still do the checksum update(replace some IP and port and recalculate the checksum). It will lead to incorrect L4 header checksum. Reported-at:https://github.com/openvswitch/ovs-issues/issues/265 Signed-off-by: Wilson Peng <pweisong@vmware.com> Signed-off-by: Alin-Gabriel Serdean <aserdean@ovn.org>
* datapath-windows: Fix icmp related error code.ldejing2022-09-202-3/+7
| | | | | | | | | | | | | When icmp error code send back to sender, currently ovs ct can't create conntrack for the error code properly, this patch mainly fix the bug. icmp error code test case: 1) packet too big. 2) network unreachable 3) parameter problem Signed-off-by: ldejing <ldejing@vmware.com> Signed-off-by: Alin-Gabriel Serdean <aserdean@ovn.org>
* datapath-windows: support meter action initial versionldejing2022-09-209-1/+679
| | | | | | | | | | | | | | | | | | | | | | | | | | | | This patch implemented meter action, currently, meter only support drop method and only support one band. The overall implementation is, when a packet comes in, it will first lookup meter according to the meter id, then get the band->rates and delta time since last access the same meter from the meter struct. Add the multiply result(band->rates * delta_time) to bucket, finally bucket minus the packet size, if the result larger than zero, allow the packet go through, otherwise deny the packet go through. Test case: 1. Setting the size meter size 3M, then the bandwidth was limit around 3M; ovs-ofctl -O OpenFlow13 add-meter br-test meter=2,kbps,\ band=type=drop,rate=3000 ovs-ofctl add-flow br-test "table=0,priority=1,ip \ actions=meter:2,normal" -O OpenFlow13 2. Setting the meter size 8M, then the bandwidth was limit around 8M; ovs-ofctl -O OpenFlow13 add-meter br-test meter=2,\ kbps,band=type=drop,rate=8000 ovs-ofctl add-flow br-test "table=0,priority=1,ip\ actions=meter:2,normal" -O OpenFlow13 Signed-off-by: ldejing <ldejing@vmware.com> Signed-off-by: Alin-Gabriel Serdean <aserdean@ovn.org>
* datapath-windows: Add IPv6 conntrack ip fragment support on windowsldejing2022-09-2011-58/+1402
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Implementation on Windows: IPv6 conntrack ip fragment feature use a link list to store ip fragment. When ipv6 fragment module receives a fragment packet, it will store length of the fragment, until to the received length equal to the packet length before fragmented, it will reassemble fragment packet to a complete packet and send the complete packet to conntrack module. After conntrack processed the packet, fragment module will divide the complete packet into small fragment and send it to destination. Currently, ipv6 was implemented in a indenpent module, for the reason it can reduce the risk of introduce bug to ipv4 fragmenb module. Testing Topology: On the Windows VM runs on the ESXi host, two hyper-v ports attached to the ovs bridge; one hyper-v port worked as client and the other port worked as server. Testing Case: 1.UdpV6 a) UdpV6 fragment with multiple ipv6 extension fields. b) UdpV6 fragment in normal scenario. c) UdpV6 fragment in nat scenario. 2.IcmpV6 a) IcmpV6 fragment in normal scenario. b) IcmpV6 fragment in nat scenario. Signed-off-by: ldejing <ldejing@vmware.com> Signed-off-by: Alin-Gabriel Serdean <aserdean@ovn.org>
* datapath-windows: Alg support for ftp and tftp in conntrackldejing2022-09-206-78/+211
| | | | | | | | | | | | | | | | | | | | | This patch mainly support alg field in ct action when process ftp/tftp traffic. Tftp with alg mainly parse the tftp packet (IPv4/IPv6), extract connect info from the tftp packet and create the related connection. For ftp, previous version has supported process of ftp traffic. However, previous version regard traffic from or to port 21 as ftp traffic, this is incorrect in some scenario. This version adds alg field in ct for ftp traffic, we could use ct(alg=ftp) to process any ftp traffic from/to any port. IPv4/IPv6. Test cases: 1) ftp ipv4/ipv6 use alg field in the normal and nat scenario. 2) tftp ipv4/ipv6 use alg field in the normal and nat scenario. Signed-off-by: ldejing <ldejing@vmware.com> Signed-off-by: Alin-Gabriel Serdean <aserdean@ovn.org>
* datapath-windows: Correct Geneve IPV6 header checksum parameterWilson Peng2022-09-201-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | In the recent upstream OVS Geneve IPV6 tunnel coding job, it is only supportting the case when the uplink offload (UDP v6 offload parameter setting on the network adapter configuration) is disabled. For Geneve IPV6 header setting, it needs set Transmit.IpHeaderChecksum in NDIS_TCP_IP_CHECKSUM_NET_BUFFER_LIST_INFO to be 0. Elsewise we could observe the found issue on the report page. After this patch, even the uplink UDP v6 offload is enabled(On WindowsServer 2019) by default the IPV6 Geneve tunnel could send/receive packets without issues now. I have tested four kinds of network adapter drivers( E1000e ,vmxnet3 and physical network adapter "Intel(R) Ethernet 10G X710 rNDC " and "Mellanox ConnectX-5 Adapter”. On the default offload setting for the network adapter(Windows server2019) the IPV6 Geneve tunnel could be setup. This patch needs to be applied to master and branch-3.0. Test topo, Setup one IPV6 Geneve Tunnel between 1 Windows VM and 1 Ubuntu server. Windows VM(Windows server2019), vif0( 6000::2/40.1.1.10) vif1(5000:ed4d::2) ------ Ubuntu VM Eth2(5000:ed4d::9), name space ns1 with interface ns1_link(6000::9/40.1.1.2) WinVM: ovs-vsctl.exe add-port br-int bms-tun0 -- set interface bms-tun0 type=geneve options:key=flow options:csum=true options:local_ip="5000:ed4d::2" options:remote_ip="5000:ed4d::9" options:tos=inherit Ubuntu VM:ovs-vsctl add-port br-int dst_tunnel -- set interface dst_tunnel type=geneve options:local_ip="5000:ed4d::1" options:remote_ip="5000:ed4d::2" Reported-at: https://github.com/openvswitch/ovs-issues/issues/260 Signed-off-by: Wilson Peng <pweisong@vmware.com> Signed-off-by: Alin-Gabriel Serdean <aserdean@ovn.org>
* make: Remove the Linux datapath.Greg Rose2022-07-151-1/+1
| | | | | | | | | | | | | | | | Update the necessary make and configure files to remove the Linux datapath and then remove the datapath. Move datapath/linux/compat/include/linux/openvswitch.h to include/linux/openvswitch.h because it is needed to generate header files used by the userspace switch. Also remove references to the Linux datapath from auxiliary files and utilities since it is no longer supported. Signed-off-by: Greg Rose <gvrose8192@gmail.com> Reviewed-by: David Marchand <david.marchand@redhat.com> Signed-off-by: Ilya Maximets <i.maximets@ovn.org>
* datapath-windows: Update layers for multiple tunnels processingWilson Peng2022-06-223-2/+23
| | | | | | | | | | | | | | | | | | | While testing OVS-windows for multiple IPV6 Geneve tunnels on Windows2019VM, for the broadcast/mutlicast packets, it needs to flood out via configured multiple Geneve tunnels. Then in some flow pipeline processing, it may have at least two tunnel processing in OVS_ACTION_ATTR_SET action. When processing the second tunnel setting it may need flush out the packet out via tunnel before setting new tunnel parameter in tunKey. We found in this case, after flushing out the packet out via tunnel, the related layers pointer does not update. In our test setup on Windows2019VM, it will cause BSOD which is triggered in other Windows processes. We suspect it may be related to memory overwriting. When we apply the fix in the patch, no BSOD is observed on the same VM and same packet/tunnel settting. Another thing needs to be mentioned is for multiple Geneve IPv4 tunnels, the same kind broadcase/multicast packet will not cause BSOD. Signed-off-by: Wilson Peng <pweisong@vmware.com> Signed-off-by: Alin-Gabriel Serdean <aserdean@ovn.org>
* datapath-windows: Fix GRE/VxLAN/STT Tunnel RX.William Tu2022-06-223-16/+0
| | | | | | | | | | | | GRE/Vxlan/STT tunnel RX is broken due to incorrecly checking the 'tunKey->dst.si_family != AF_INET', which is actually set later after parsing the GRE header. Removing such chunk makes tunnel works. Fixes: edb2335861d6 ("datapath-windows: Add IPv6 Geneve tunnel support in Windows") Cc: Alin-Gabriel Serdean <aserdean@ovn.org> Signed-off-by: William Tu <u9012063@gmail.com> Signed-off-by: Alin-Gabriel Serdean <aserdean@ovn.org>
* Carefully release NBL in Windowshxie2022-05-251-9/+88
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | OvsExtSendNBLComplete always release NBLs with flag SINGL_SOURCE, this is an efficient way, which requires all the NBLs having the same source port, when cloned/fragment NBLs are released, the parent NBLs will be released as well, the problem is that a parent NBL may have a different source port from the cloned/fragment NBL, so releasing the parent NBLs with flag SINGLE_SOURCE is not corrct, see: https://github.com/microsoft/hcsshim/issues/1056 When this happens, commands 'Get-NetAdapter' and 'Get-HnsEndpoint' in the Windows node show that one net-adapter/hns-endpoint is in 'disconnected' state, meanwhile, following processes are affected, ecah of them has one thread pending on a lock: vmcompute.exe containerd.exe antrea-agent.exe To fix this issue, we may check SourcePortId in each parent NBLs before released. A simple way to reprodue this issue: 1, Enable encap mode 2, create 2 nodes, nodeA and nodeB 3, create podA with image k8s.gcr.io/e2e-test-images/agnhost:2.21 on nodeA, run 'iperf/iperf.exe -s -p 9000 -D' 4, create podB with same image on nodeB, run command 'iperf/iperf.exe -c <podA-ip> -p 9000' 5, delete podB 6, run 'Get-NetAdapter' on nodeB, you will find the leaked net adapter. Signed-off-by: Hongsheng Xie <hxie@vmware.com> Signed-off-by: Alin-Gabriel Serdean <aserdean@ovn.org>
* datapath-windows: Add IPv6 conntrack support on Windows.ldejing2022-04-2215-97/+793
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Implementation on Windows: Currently, IPv4 conntrack was supported on the windows platform. In this patch we have implemented ipv6 conntrack functions according to the current logic of the IPv4 conntrack. This implementation has included TcpV6(nat and normal scenario), UdpV6(nat and normal scenario), IcmpV6 conntrack of echo request/reply packet and FtpV6(nat and normal scenario). Testing Topology: On the Windows VM runs on the ESXi host, two hyper-v ports attached to the ovs bridge; one hyper-v port worked as client and the other port worked as server. Testing Case: 1. TcpV6 a) Tcp request/reply conntrack for normal scenario. In this scenario, 20::1 as client, 20::2 as server, it will generate following conntrack entry: (Origin(src=20::1, src_port=1555, dst=20::2, dst_port=1556), reply(src=20::2,src_port=1556,dst=20::1,dst_port=1555),protocol=tcp) b) Tcp request/reply conntrack for nat scenario. In this scenario, 20::1 as client, 20::10 as floating ip, 21::3 as server, it will generate following conntrack entry: (Origin(src=20::1, src_port=1555, dst=20::10, dst_port=1556), reply(src=21::3, src_port=1556, dst=20::1, dst_port= 1555),protocol=tcp) 2. UdpV6 a) Udp request/reply conntrack for normal scenario. (Origin(src=20::1, src_port=1555, dst=20::2, dst_port=1556), reply(src=20::2,src_port=1556,dst=20::1,dst_port=1555),protocol=udp) b) Udp request/reply conntrack for nat scenario. (Origin(src=20::1, src_port=1555, dst=20::10, dst_port=1556), reply(src=21::3, src_port=1556, dst=20::1, dst_port= 1555),protocol=udp) 3. IcmpV6: a) Icmpv6 request/reply conntrack for normal scenario. Currently Icmpv6 only support to construct conntrack for echo request/reply packet, take (20::1 -> 20::2) for example, it will generate following conntrack entry: (origin(src = 20::1, dst=20::2), reply(src=20::2, dst=20::1), protocol=icmp) b) Icmp request/reply conntrack for dnat scenario, for example (20::1->20::10->21::3), 20::1 is client, 20::10 is floating ip, 21::3 is server ip. It will generate flow like below: (origin(src=20::1, dst=20::10), reply(src=21::3, dst=20::1), protocol=icmp) 4. FtpV6 a) Ftp request/reply conntrack for normal scenario. In this scenario, take 20::1 as client, 20::2 as server, it will generate two conntrack entries: Ftp active mode (Origin(src=20::1, src_port=1555, dst=20::2, dst_port=21), reply(src=20::2, src_port=21, dst=20::1, dst_port=1555), protocol=tcp) (Origin(src=20::2, src_port=20, dst=20::1, dst_port=1556), reply(src=20::1, src_port=1556, dst=20::2, dst_port=20), protocol=tcp) Ftp passive mode (Origin(src=20::1, src_port=1555, dst=20::2, dst_port=21), reply(src=20::2,src_port=21,dst=20::1,dst_port=1555),protocol=tcp) (Origin(src=20::1, src_port=1556, dst=20::2, dst_port=1557), reply(src=20::2,src_port=1557, dst=20::1, dst_port=1556) protocol=tcp) b) Ftp request/reply conntrack for nat scenario. Ftp passive mode, In this secnario, 20::1 as client, 20::10 as floating ip, 21::3 as server ip. It will generate following flow: (Origin(src=20::1, src_port=1555, dst=20::10, dst_port=21), reply(src=21::3, src_port=21, dst=20::1, dst_port= 1555),protocol=tcp) (Origin(src=20::1, src_port=1556, dst=20::10, dst_port=1557), reply(src=21::3, src_port=1557, dst=20::1, dst_port= 1556),protocol=tcp) 5. Regression test for IpV4 in Antrea project (about 60 test case) Future work: 1) IcmpV6 redirect packet conntrack. 2) IpV6 fragment support on Udp. 3) Support napt for IPv6. 4) FtpV6 active mode for nat. Signed-off-by: ldejing <ldejing@vmware.com> Signed-off-by: Alin-Gabriel Serdean <aserdean@ovn.org>
* datapath-windows: Add IPv6 Geneve tunnel support in WindowsWilson Peng2022-04-1021-431/+918
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | In the first step OVS Windows will support IPv6 tunnel(Geneve IPv6 tunnel). Implementation on Windows ------------------------- 1. For the IPv6 tunnel support,  OvsIPTunnelKey will replace original OvsIPv4TunnelKey in the related flow context handing. 2. The related src and dst address will be  changed to SOCKADDR_INET type from UINT32. 3. For the IPv6 tunnel,  one node running OVS-Windows could encapsulate IPv4/IPv6 Packets via IPV6 Geneve Tunnel, and the node could also encapsulate IPv4/IPv6 packet Via IPv4 Geneve tunnel. 4. Related IPHelper data structure will be adapted to support IPv6 Tunnel. In the IPHelper part the related Windows API(such as GetUnicastIpAddressTable/GetBestRoute2/GetIpNetEntry2/ ResolveIpNetEntry2) and Windows data structure(MIB_IPFORWARD_ROW2/MIB_IPNET_ROW2/IP_ADDRESS_PREFIX) Have already supported both IPv4 and IPV6. Now OVS Windows has been adjusted some functions And data structured to support IPV6 tunnel also. 5. OVS_TUNNEL_KEY_ATTR_IPV6_SRC and OVS_TUNNEL_KEY_ATTR_IPV6_DST filed will be supported in OVS-Windows kernel for IPV6 tunnel. Testing done. ------------------------- Related topo, 1 Windows VM(Win2019) and 2 Ubuntu 16.04 server. Both VMs Are running on one ESX host. 1. Setup one IPV6 Geneve Tunnel between 1 Windows VM and 1 Ubuntu server. Windows VM, vif0( 6000::2/40.1.1.10) vif1(5000::2)—— Ubuntu VM Eth2(5000::9), name space ns1 with interface ns1_link_peer(6000::9/40.1.1.2) Related tunnnel, ovs-vsctl.exe add-port br-int bms-tun0 -- set interface bms-tun0 type=Geneve options:csum=true options:key=flow options:local_ip="5000::2" options:remote_ip=flow In this topo, traffic from Vif0(Win) to ns1_link_peer(Ubuntu) will be gone through the Geneve tunnel (5000::2—>5000::9) for both IPv4 traffic(40.1.1.10-->40.1.1.2) and IPv6 traffic(6000::2—>6000::9) 2. Setup one IPV4 Geneve Tunnel between Windows VM and 1 Ubuntu server. Windows VM, vif0( 6000::2/40.1.1.10) vif1(50.1.1.11)—— Ubuntu, Eth2(50.1.1.9), name space ns1 with interface ns1_link_peer(6000::19/40.1.1.9) Related tunnnel, ovs-vsctl.exe -- set Interface bms-tun0 type=geneve options:csum=true options:key=flow options:local_ip="50.1.1.11" options:remote_ip=flow In this topo, traffic from Vif0(Win) to ns1_link_peer(Ubuntu) will be gone through the Geneve Tunnel (50.1.1.11—>50.1.1.9) for both IPv4 traffic(40.1.1.10-->40.1.1.9) and IPv6 traffic(6000::2—>6000::19). 3.Regression test for IpV4 in Antrea project (about 60 test case) is PASS Future Work ----------- Add other type IPv6 tunnel support for Gre/Vxlan/Stt. Signed-off-by: Wilson Peng <pweisong@vmware.com> Signed-off-by: Alin-Gabriel Serdean <aserdean@ovn.org>
* datapath-windows: Fix NXM_OF_IP_TOS issueFrank Guo2022-02-231-0/+9
| | | | | | | | | | | | | | | Currenlty Ovs-windows can not change tos using NXM_OF_IP_TOS, this patch fixes it. 1, test with the following flow : ovs-ofctl.exe add-flow br-int "table=0,priority=300,in_port=antrea-gw0,icmp actions=mod_nw_tos:28,load:0x1->NXM_NX_REG0[0..3],resubmit(,SpoofGuard)" 2, capture packet trace on destination side : 02:23:30.625049 IP (tos 0x1c, ttl 128, id 15237, offset 0, flags [none], proto ICMP (1), length 60) 192.168.250.1 > 192.168.248.1: ICMP echo request, id 1, seq 10, length 40 Reported-at:openvswitch/ovs-issues#244 Signed-off-by: Frank Guo <frankg@vmware.com> Acked-by: Mike Pattrick <mkp@redhat.com> Signed-off-by: Alin-Gabriel Serdean <aserdean@ovn.org>
* datapath-windows: Pickup Ct tuple as CT lookup key in function ↵Wilson Peng2022-01-204-10/+34
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | OvsCtSetupLookupCtx CT marks which are loaded in non-first commit will be lost in ovs-windows.In linux OVS, the CT mark setting with same flow could be set successfully. Currenlty Ovs-windows will create one new CT with the flowKey(Extracted from the packet itself) If the packet is already done DNAT action after the 1st round flow processing. So the ct-mark Set on previous Conntrack will be lost.In the fix, it will make use of CT tuple src/dst address stored in the flowKey if the value is not zero and zone in the flowKey is same as the input zone. In the fix, it is also to adjust function OvsProcessDeferredActions to make it clear. //DNAT flow cookie=0x1040000000000, duration=950.326s, table=EndpointDNAT, n_packets=0, n_bytes=0, priority=200,tcp,reg3=0xc0a8fa2b,reg4=0x20050/0x7ffff actions=ct(commit,table=AntreaPolicyEgressRule,zone=65520,nat(dst=192.168.250.43:80),exec(load:0x1->NXM_NX_CT_MARK[2]) // Append ct_mark flow cookie=0x1000000000000, duration=11980.701s, table=SNATConntrackCommit, n_packets=6, n_bytes=396, priority=200,ct_state=+new+trk,ip,reg0=0x2 00/0x200,reg4=0/0xc00000 actions=load:0x3->NXM_NX_REG4[22..23],ct(commit,table=SNATConntrackCommit,zone=65520,exec(load:0x1->NXM_NX_CT_MARK[4 ],load:0x1->NXM_NX_CT_MARK[5])) // SNAT flow cookie=0x1000000000000, duration=11980.701s, table=SNATConntrackCommit, n_packets=6, n_bytes=396, priority=200,ct_state=+new+trk,ip,reg0=0x6 00/0x600,reg4=0xc00000/0xc00000 actions=ct(commit,table=L2Forwarding,zone=65521,nat(src=192.168.250.1),exec(load:0x1->NXM_NX_CT_MARK[2])) Reported-at:https://github.com/openvswitch/ovs-issues/issues/237 Signed-off-by: Wilson Peng <pweisong@vmware.com> Signed-off-by: Alin-Gabriel Serdean <aserdean@ovn.org>
* datapath-windows: Reset flow key after Ipv4 fragments are reassembledWilson Peng2021-11-151-1/+18
| | | | | | | | | | | 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> Signed-off-by: Alin-Gabriel Serdean <aserdean@ovn.org>
* datapath-windows:Reset PseudoChecksum value only for TX direction offload caseWilson Peng2021-10-281-4/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | | | While testing OVS-windows flows for the DNAT/SNAT action, the checksum in TCP header is set incorrectly when TCP offload is enabled by default. As a result,the packet will be dropped on the Windows VM when processing the packet from Linux VM which has included correct checksum at first. On the Windows VM, it has gone through two NAT actions and OVS Windows kernel will reset the checksum to PseudoChecksum and then it will lose the original correct checksum value which is set outside. Back to the Nat TCP/UDP checksum value reset logic,it should reset it TCP checksum To be PseudoChecksum value only on Tx direction for TCP Offload case. For the packet From the outside, OVS Windows Kernel does not need reset the TCP/UDP checksum as It should be the job of the received network driver to get out a correct checksum Value. >>>sample flow on default configuration on both Windows VM and Linux VM (src=192.168.252.1,dst=10.110.225.146)-->dnat/snat-> (src=169.254.169.253, Dst=10.176.26.107) Without the fix the return back packet(src=10.176.26.107, Dst=169.254.169.253) will have the correct TCP checksum. After the reverse NAT Actions, it will be changed to be packet (src=10.110.225.146, Dst=192.168.252.1) But with incorrect TCP checksum 0xa97a which is The PseudoChecksum. Related packet is put on the reported issue below. Reported-at:https://github.com/openvswitch/ovs-issues/issues/231 Signed-off-by: Wilson Peng <pweisong@vmware.com> Signed-off-by: Alin-Gabriel Serdean <aserdean@ovn.org>
* datapath-windows: add layers when adding the deferred actionsWilson Peng2021-10-193-6/+25
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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 <pweisong@vmware.com> Signed-off-by: Alin-Gabriel Serdean <aserdean@ovn.org>
* datapath-windows: Add file digest algorithm for signtoolAlin-Gabriel Serdean2021-10-112-1/+39
| | | | | | | | | | This patch specifies the file digest algorithm for signtool on the package and ovsext VS projects. Fixes broken appveyor build. Signed-off-by: Alin-Gabriel Serdean <aserdean@ovn.org> Acked-by: Aaron Conole <aconole@redhat.com>
* datapath-windows:adjust Offset when processing packet in POP_VLAN actionwilsonpeng2021-09-301-3/+15
| | | | | | | | | | | | | | 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> Signed-off-by: Alin-Gabriel Serdean <aserdean@ovn.org>
* datapath-windows:Correct checksum for DNAT actionWilson Peng2021-07-211-0/+12
| | | | | | | | | | | | | | | | | | While testing OVS-windows flows for the DNAT action, the checksum In TCP header is set incorrectly when TCP offload is enabled by Default. As a result, the packet will be dropped on receiver linuxVM. >>>sample flow default configuration on both Windows VM and Linux VM (src=40.0.1.2,dst=10.150.0.1) --dnat--> (src=40.0.1.2,dst==30.1.0.2) Without the fix for some TCP packet(40.0.1.2->30.1.0.2 with payload len 207) the TCP checksum will be pseduo header checksum and the value is 0x01d6. With the fix the checksum will be 0x47ee, it could be got the correct TCP checksum on the receiver Linux VM. Signed-off-by: Wilson Peng<pweisong@vmware.com> Signed-off-by: Anand Kumar<kumaranand@vmware.com> Acked-by: Alin-Gabriel Serdean <aserdean@ovn.org> Signed-off-by: Alin-Gabriel Serdean <aserdean@ovn.org>
* datapath-windows: Specify external include pathsAlin Gabriel Serdean2021-06-171-0/+17
| | | | | | | | | | | | | | | | VStudio 16.10 adds usermode includes before including the driver kit ones. Bug tracked at: https://developercommunity.visualstudio.com/t/error-lnk2019-unresolved-external-symbol-stdio-com/1434674 Fixes appveyor build reported by forcing external includes. Reported-by: Ilya Maximets <i.maximets@ovn.org> Reported-by: Frank Wagner <frank.wagner@dbosoft.eu> Reported-at: https://github.com/openvswitch/ovs-issues/issues/209#issuecomment-861385852 Reported-at: https://github.com/openvswitch/ovs-issues/issues/211 Signed-off-by: Alin Gabriel Serdean <aserdean@ovn.org> Acked-by: Ilya Maximets <i.maximets@ovn.org>
* datapath_windows: Add datapath_windows targetAlin Gabriel Serdean2020-10-041-0/+4
| | | | | | | | It is useful to build the latest supported version of the driver using the `make` command. Signed-off-by: Alin Gabriel Serdean <aserdean@ovn.org> Acked-by: Ilya Maximets <i.maximets@ovn.org>
* Remove duplicate include fileYi Li2020-09-221-1/+0
| | | | | | | Found by checkincludes.pl Signed-off-by: Yi Li <yili@winhong.com> Signed-off-by: Alin Gabriel Serdean <aserdean@cloudbasesolutions.com>
* datapath-windows: Update flow key in SET actionJinjun Gao2020-07-292-7/+27
| | | | | | | | | | The flow key is not updated when process OVS_ACTION_ATTR_SET action. It will impact follow-up actions, such as, conntrack module cannot find created conntrack entry if passing old flow key to it. Reported-by: Rui Cao <rcao@vmware.com> Signed-off-by: Jinjun Gao <jinjung@vmware.com> Signed-off-by: Alin Gabriel Serdean <aserdean@cloudbasesolutions.com>
* datapath-windows: Reset ct_mark/ct_label to support ALGJinjun Gao2020-07-281-32/+54
| | | | | | | | | | | The ct_mark/ct_label setting on related connection keep the same behavior with Linux datapath. If one CT entry has parent/master entry, its ct_mark and ct_label should inherit from the corresponding part of parent/master entry at initialization. Signed-off-by: Jinjun Gao <jinjung@vmware.com> Acked-by: Alin Gabriel Serdean <aserdean@ovn.org> Signed-off-by: Alin Gabriel Serdean <aserdean@cloudbasesolutions.com>
* datapath-windows: Add CTA_HELP and CTA_TUPLE_MASTERJinjun Gao2020-06-303-8/+48
| | | | | | | | | Add helper and master if existing to a conntrack entry: 1, For CTA_HELP, only support FTP/TFTP; 2, For CTA_TUPLE_MASTER, only support FTP. Signed-off-by: Jinjun Gao <jinjung@vmware.com> Signed-off-by: Alin Gabriel Serdean <aserdean@ovn.org>
* datapath-windows, conntrack: Fix conntrack new stateRui Cao2020-06-274-5/+17
| | | | | | | | | | | | | | | | On windows, if we send a connection setup packet in one direction twice, it will make the connection to be in established state. The same issue happened in Linux userspace conntrack module and has been fixed. This patch port the following previous fixes to windows datapath to fix the issue: - a867c010ee9183885ee9d3eb76a0005c075c4d2e - ac23d20fc90da3b1c9b2117d1e22102e99fba006 Acked-by: Yi-Hung Wei <yihung.wei@gmail.com> Signed-off-by: Rui Cao <rcao@vmware.com> Signed-off-by: William Tu <u9012063@gmail.com>
* datapath-windows: Append tunnel info to upcall for correct templateAmber Hu via dev2020-02-105-7/+44
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Formerly, there is no tunnel information appended in the upcall’s packet data, which is expected by IPFIX in userspace to calculate the template for exporting the sampled flow record of on egress tunnel port. To fix this, during performing OvsOutputUserspaceAction(), we would check whether it is initiated by the sampling on egress tunnel which would be indicated by the attribute as OVS_USERSPACE_ATTR_EGRESS_TUN_PORT in the nested attribute list. If so, we would append the tunKey in OvsForwardingContext indexed by OVS_PACKET_ATTR_EGRESS_TUN_KEY to the upcall. Besides, at this point, the source transport port and source ip address are not available in the structure, so we have to fill it in the way how the packet would be capsulated during performing OvsEncapGeneve(), which is following the OvsOutputUserspaceAction() unfortunately. I have tested the IPFIX functionality with the change, we could see the template is correct and the expected tunnel information could be packed in the IPFIX packet finally. The traffic for test is generated by PING utility. >From d727d051c9a44a4a93e5ee5f3da3ca9b125aad29 Mon Sep 17 00:00:00 2001 From: Amber Hu <qhu@vmware.com> Date: Thu, 30 Jan 2020 18:01:32 -0800 Subject: [PATCH v3] datapath-windows: Append tunnel info to upcall for correct template Signed-off-by: Amber Hu <qhu@vmware.com> Acked-by: Alin Gabriel Serdean <aserdean@ovn.org> Signed-off-by: Alin Gabriel Serdean <aserdean@ovn.org>
* datapath-windows: Do not delete internal port on OID_SWITCH_NIC_DISCONNECTJinjun Gao2019-12-091-3/+9
| | | | | | | | | | | | | | | | | | | According to the microsoft doc: https://docs.microsoft.com/en-us/windows-hardware/drivers/network/hyper-v-extensible-switch-port-and-network-adapter-states Below OID request sequence is validation: OID_SWITCH_NIC_CONNECT -> OID_SWITCH_NIC_DISCONNECT ^ | | V OID_SWITCH_NIC_CREATE <- OID_SWITCH_NIC_DELETE In above sequence, the windows extensible switch interface assumes the OID_SWITCH_PORT_CREATE has issued and the port has been created successfully. If delete the internal port in HvDisconnectNic(), HvCreateNic() will fail when received OID_SWITCH_NIC_CREATE late because there is no corresponding port. Signed-off-by: Jinjun Gao <jinjung@vmware.com> Signed-off-by: Alin Gabriel Serdean <aserdean@ovn.org>
* ct-dpif, dpif-netlink: Add conntrack timeout policy supportYi-Hung Wei2019-09-262-2/+120
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This patch first defines the dpif interface for a datapath to support adding, deleting, getting and dumping conntrack timeout policy. The timeout policy is identified by a 4 bytes unsigned integer in datapath, and it currently support timeout for TCP, UDP, and ICMP protocols. Moreover, this patch provides the implementation for Linux kernel datapath in dpif-netlink. In Linux kernel, the timeout policy is maintained per L3/L4 protocol, and it is identified by 32 bytes null terminated string. On the other hand, in vswitchd, the timeout policy is a generic one that consists of all the supported L4 protocols. Therefore, one of the main task in dpif-netlink is to break down the generic timeout policy into 6 sub policies (ipv4 tcp, udp, icmp, and ipv6 tcp, udp, icmp), and push down the configuration using the netlink API in netlink-conntrack.c. This patch also adds missing symbols in the windows datapath so that the build on windows can pass. Appveyor CI: * https://ci.appveyor.com/project/YiHungWei/ovs/builds/26387754 Signed-off-by: Yi-Hung Wei <yihung.wei@gmail.com> Acked-by: Alin Gabriel Serdean <aserdean@ovn.org> Signed-off-by: Justin Pettit <jpettit@ovn.org>
* datapath-windows: Fix updating ct label when mask is specifiedAnand Kumar2019-08-191-0/+1
| | | | | | | | | | When an existing label needs to be changed by specifing bits to be updated using mask, instead of updating only the masked bits, new label was getting overridden. This patch fixes this issue. Signed-off-by: Anand Kumar <kumaranand@vmware.com> Acked-by: Alin Gabriel Serdean <aserdean@ovn.org> Signed-off-by: Alin Gabriel Serdean <aserdean@ovn.org>
* datapath-windows: Copy mru information when cloning a nbl.Anand Kumar2019-05-201-7/+8
| | | | | | | | | | When a nbl is cloned, mru value stored in the original nbl context is lost, which skips refragemting the cloned nbls. This patch fixes it. Signed-off-by: Anand Kumar <kumaranand@vmware.com> Signed-off-by: Alin Gabriel Serdean <aserdean@ovn.org>
* datapath-windows: Add Win10Analyze targetAlin Gabriel Serdean2019-05-097-4/+159
| | | | | | | | | | | | | | | | This patch adds a new target called `Win10Analyze` to the driver solution. It enables us to trigger static analysis over the Win10 target. Since the location of the ruleset of drivers is somewhat random starting from 1803: https://www.osr.com/blog/2018/05/21/wdk-1803-ca/ Commit the ruleset inside our repository. This is the same ruleset used for 8,8.1 and 10. Signed-off-by: Alin Gabriel Serdean <aserdean@ovn.org> Acked-by: Anand Kumar <kumaranand@vmware.com>
* datapath-windows: Do not send out nbls when cloned nbls are being accessedAnand Kumar2019-04-253-1/+20
| | | | | | | | | | | | | | | | | | | As per MSDN documentation, "As soon as a filter driver calls the NdisFSendNetBufferLists function, it relinquishes ownership of the NET_BUFFER_LIST structures and all associated resources. A filter driver should never try to examine the NET_BUFFER_LIST structures or any associated data after calling NdisFSendNetBufferLists". https://docs.microsoft.com/en-us/windows-hardware/drivers/ddi/content/ndis/nf-ndis-ndisfsendnetbufferlists When freeing up memory of a cloned nbl, parent's nbl and context is being accessed, which is incorrect can cause BSOD. With this patch, original nbl is sent out only when cloned nbl is done with packet processing and its memory is freed. Signed-off-by: Anand Kumar <kumaranand@vmware.com> Acked-by: Alin Gabriel Serdean <aserdean@ovn.org> Signed-off-by: Alin Gabriel Serdean <aserdean@ovn.org>
* datapath-windows: Fix vlan key getting stored in host byte order.Anand Kumar via dev2019-04-091-2/+2
| | | | | | | Update flowkey to set vlan information in network byte order. Signed-off-by: Anand Kumar <kumaranand@vmware.com> Signed-off-by: Alin Gabriel Serdean <aserdean@ovn.org>
* datapath-windows: Add guards around IpHelper adapter binding callsSairam Venugopal via dev2019-04-032-3/+33
| | | | | | | | | | | | Protect internal adapter up/down calls with a dispatch lock. It was observed that the InternalAdapter bind calls could happen out of order thereby causing encap packets to not be sent properly. Add assert around the IpHelper bind calls to ensure Up/Down gets called only for the appropriate vports. Signed-off-by: Sairam Venugopal <vsairam@vmware.com> Signed-off-by: Alin Gabriel Serdean <aserdean@ovn.org>
* datapath-windows: Address memory allocation issues for OVS_BUFFER_CONTEXTAnand Kumar via dev2019-04-031-7/+4
| | | | | | | | | | | | | | | | | | With current implementation, when nbl pool is allocated, context size is specified as 64 bytes, while the OVS_BUFFER_CONTEXT size is only 32 bytes. Since context size is never changed, additional memory is not required. This patch makes it simpler to allocate memory for OVS_BUFFER_CONTEXT so that it is always aligned to MEMORY_ALLOCATION_ALIGNMENT. This is acheived by updating "value" field in the context structure, so that number of elements in array is always a multiple of MEMORY_ALLOCATION_ALIGNMENT. Also change the DEFAULT_CONTEXT_SIZE to accomodate OVS_BUFFER_CONTEXT size. Signed-off-by: Anand Kumar <kumaranand@vmware.com> Acked-by: Alin Gabriel Serdean <aserdean@ovn.org> Signed-off-by: Alin Gabriel Serdean <aserdean@ovn.org>
* datapath-windows: Add annotations to find vport functionsAlin Gabriel Serdean2019-03-132-1/+11
| | | | | | | | | Add annotations to find vport functions to check if the dispatch lock is held. Signed-off-by: Alin Gabriel Serdean <aserdean@ovn.org> Acked-by: Anand Kumar <kumaranand@vmware.com> Acked-by: Sairam Venugopal <vsairam@vmware.com>
* datapath-windows: Guard vport usage in user.cAlin Gabriel Serdean2019-03-131-8/+8
| | | | | | | | When using a vport we need to guard its usage with the dispatch lock. Signed-off-by: Alin Gabriel Serdean <aserdean@ovn.org> Acked-by: Anand Kumar <kumaranand@vmware.com> Acked-by: Sairam Venugopal <vsairam@vmware.com>
* datapath-windows: Fix race condition during port creationSairam Venugopal2019-03-131-2/+1
| | | | | | | | | | Hold the dispatch lock until port-add operations are completed. Found by inspection. Signed-off-by: Sairam Venugopal <vsairam@vmware.com> Acked-by: Alin Gabriel Serdean <aserdean@ovn.org> Signed-off-by: Alin Gabriel Serdean <aserdean@ovn.org>
* datapath-windows: Fix potential deadlock in event subscriptionSairam Venugopal2019-03-131-2/+1
| | | | | | | | | | | | | | Move the EventQueue lock acquisition after the dispatchLock to prevent a potential deadlock in port creation pipeline. There could be a case where a port event could try to take up the Dispatch Lock before the Event Queue lock and the subscription queue event could take up the event queue lock before the dispatch lock. Found while testing with Driver Verifier enabled. Signed-off-by: Sairam Venugopal <vsairam@vmware.com> Acked-by: Alin Gabriel Serdean <aserdean@ovn.org> Signed-off-by: Alin Gabriel Serdean <aserdean@ovn.org>
* datapath-windows: Fix nbl cleanup when memory allocation failsSairam Venugopal2019-03-131-3/+2
| | | | | | | | | | | | | StartNblIngressError should be called only when an NBL hasn't been modified. In this case the nbl context was initialized. Rely on existing packet completion mechanism to cleanup the NBL. Found while testing with DriverVerifier with limited memory setting enabled. Signed-off-by: Sairam Venugopal <vsairam@vmware.com> Acked-by: Anand Kumar <kumaranand@vmware.com> Signed-off-by: Alin Gabriel Serdean <aserdean@ovn.org>
* datapath-windows: Add support for 'OVS_KEY_ATTR_ENCAP' key attribute.Anand Kumar2019-01-284-16/+144
| | | | | | | | | | | | | | | | | Add a new structure in l2 header to accomodate vlan header, based of commit "d7efce7beff25052bd9083419200e1a47f0d6066 datapath: 802.1AD Flow handling, actions, vlan parsing, netlink attributes" Also reset vlan header in flow key, after deleting vlan tag from nbl With this change a sample vlan flow would look like, eth(src=0a:ea:8a:24:03:86,dst=0a:cd:fa:4d:15:5c),in_port(3),eth_type(0x8100), vlan(vid=2239,pcp=0),encap(eth_type(0x0800),ipv4(src=13.12.11.149,dst=13.12.11.107, proto=1,tos=0,ttl=128,frag=no),icmp(type=8,code=0)) Signed-off-by: Anand Kumar <kumaranand@vmware.com> Acked-by: Alin Gabriel Serdean <aserdean@ovn.org> Signed-off-by: Alin Gabriel Serdean <aserdean@ovn.org>
* datapath-windows: Fix race condition when deleting internal portsAlin Gabriel Serdean2018-12-281-1/+1
| | | | | | | | | | | We need to hold the port lock until all the operations with a port are completed. Found by inspection. Signed-off-by: Alin Gabriel Serdean <aserdean@ovn.org> Acked-by: Ben Pfaff <blp@ovn.org> Acked-by: Anand Kumar <kumaranand@vmware.com>
* datapath-windows: Use layers info to extract IP header in IpFragmentAnand Kumar2018-12-215-53/+41
| | | | | | | | | | - Rely on layers l3Offset field to get offset of IP header. - Aslo fix passing 'newNbl' to IP fragment which is not required. - Fixed including a header file twice. Signed-off-by: Anand Kumar <kumaranand@vmware.com> Acked-by: Alin Gabriel Serdean <aserdean@ovn.org> Signed-off-by: Alin Gabriel Serdean <aserdean@ovn.org>
* datapath-windows: Fix invalid reference in Buffermgmt.cSairam Venugopal2018-11-151-2/+4
| | | | | | | | | | | | OVS_BUFFER_CONTEXT gets cleared as part of NdisFreeNetBufferListContext function call. This causes an invalid reference error. Found while testing with driver verifier enabled. Signed-off-by: Sairam Venugopal <vsairam@vmware.com> Acked-by: Anand Kumar <kumaranand@vmware.com> Acked-by: Alin Gabriel Serdean <aserdean@ovn.org> Signed-off-by: Alin Gabriel Serdean <aserdean@ovn.org>
* datapath-windows: Remove IP neighbor entries when internal adapter is down.Anand Kumar2018-10-241-18/+18
| | | | | | | | | | | | | Remove the IP neighboring entries when adapter is down, so that when 'OVS_IPHELPER_INSTANCE' is deleted, no stale entries are present Also fix accessing iphelper instance without acquiring the lock. Signed-off-by: Anand Kumar <kumaranand@vmware.com> Acked-by: Alin Gabriel Serdean <aserdean@ovn.org> Tested-by: Alin Gabriel Serdean <aserdean@ovn.org> Signed-off-by: Alin Gabriel Serdean <aserdean@ovn.org>
* datapath-windows: Move OVS_IPHELPER_INSTANCE to IpHelper.hSairam Venugopal2018-10-022-39/+38
| | | | | | | | | | | | Move the IPHelper Instance to the main header file and update the usage to explicitly point to POVS_IPHELPER_INSTANCE instead of PVOID. Also rename the ipn->context to ipn->instance to make it more readable. Found by inspection. Signed-off-by: Sairam Venugopal <vsairam@vmware.com> Acked-by: Alin Gabriel Serdean <aserdean@ovn.org> Signed-off-by: Alin Gabriel Serdean <aserdean@ovn.org>
* treewide: Fix spelling of "receive".Ben Pfaff2018-09-272-3/+3
| | | | | Signed-off-by: Ben Pfaff <blp@ovn.org> Acked-by: Justin Pettit <jpettit@ovn.org>
* datapath-windows: Fix payload length calculation in Conntrack.hAlin Gabriel Serdean2018-09-201-2/+1
| | | | | | | | | | The payload calculation in OvsGetTcpHeader is wrong: `ntohs(ipHdr->tot_len) - expr` instead of `ntohs((ipHdr->tot_len) - expr)`. We already have a macro for that calculation defined in NetProto.h so use it. Signed-off-by: Alin Gabriel Serdean <aserdean@ovn.org> Acked-by: Anand Kumar <kumaranand@vmware.com>
View Lorry Controller Status