| Commit message (Collapse) | Author | Age | Files | Lines | |
|---|---|---|---|---|---|
| * | datapath-windows: Alg support for ftp and tftp in conntrack | ldejing | 2022-09-20 | 1 | -1/+29 |
| | | | | | | | | | | | | | | | | | | | | | | 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: Add IPv6 conntrack support on Windows. | ldejing | 2022-04-22 | 1 | -8/+37 |
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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 CTA_HELP and CTA_TUPLE_MASTER | Jinjun Gao | 2020-06-30 | 1 | -1/+4 |
| | | | | | | | | | | 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: Use spinlock instead of RW lock for ct entry | Anand Kumar | 2018-06-24 | 1 | -12/+9 |
| | | | | | | | | | | | | | | | | | | | | This patch mainly changes a ndis RW lock for conntrack entry to a spinlock along with some minor refactor in conntrack. Using spinlock instead of RW lock as RW locks causes performance hits when acquired/released multiple times. - Use NdisInterlockedXX wrapper api's instead of InterlockedXX. - Update 'ctTotalRelatedEntries' using interlocked functions. - Move conntrack lock out of NAT module. Testing: Verified loading/unloading the driver with driver verified enabled. Ran TCP/UDP and ICMP traffic. 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 bugs in cleaner threads | Shashank Ram | 2017-09-28 | 1 | -1/+5 |
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Conntrack, Conntrack-related, Stt, and IP fragmentation have cleaner threads that run periodically to clean up their respective tables. During driver unload, OvsExtDetach() calls into routines that are meant for explicitly cleaning these tables up and freeing the resources associated with these threads. If during driver unload, these cleaner threads run immediately after the resources are freed, such as locks used by these threads, then the cleaner threads result in a kernel crash since they try to acquire locks that have already been freed. For eg, OvsIpFragmentEntryCleaner() caused a kernel crash because it tried to acquire a lock that was already freed by OvsCleanupIpFragment(). The fix is to simply exit the cleaner thread if the lock associated with the thread is not initialized, because the only way the threads can run when the lock is invalid is when the lock has been freed up during driver unload. Testing done: Verified that cleaner threads run as expected without crashing during driver unload. Signed-off-by: Shashank Ram <rams@vmware.com> Acked-by: Anand Kumar <kumaranand@vmware.com> Signed-off-by: Gurucharan Shetty <guru@ovn.org> | ||||
| * | datapath-windows: Add annotation for OvsCtRelatedEntryCleaner | Alin Serdean | 2017-08-02 | 1 | -3/+4 |
| | | | | | | | | | | | Make the function `OvsCtRelatedEntryCleaner` aware it is a kstart_routine. Also, the function is not compliant with the coding standard. Signed-off-by: Alin Gabriel Serdean <aserdean@cloudbasesolutions.com> Signed-off-by: Ben Pfaff <blp@ovn.org> Acked-by: Shashank Ram <rams@vmware.com> | ||||
| * | datapath-windows: Conntrack - Introduce support for tracking related connections | Sairam Venugopal | 2016-12-20 | 1 | -0/+299 |
| Introduce a new table to track related connections. This table will be used to track FTP data connections based on the control connection. There is a new Conntrack-ftp.c to parse incoming FTP messages to determine the related data ports. It creates a new entry in the related connections tracker table. If there is a matching FTP data connection, then the state for that connection is marked as RELATED. Signed-off-by: Sairam Venugopal <vsairam@vmware.com> Acked-by: Alin Gabriel Serdean <aserdean@cloudbasesolutions.com> Signed-off-by: Gurucharan Shetty <guru@ovn.org> | |||||
 |
index : delta/openvswitch.git | |
| github.com: openvswitch/ovs.git |
| summaryrefslogtreecommitdiff |