From: Wilson Peng
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
OvsGetTcp or OvsGetPacketBytes in other
patches after
The needed testing is done. Not sure if this kind of strategy is accepted?
Regards
Wilson
On Wed, Jul 17, 2024 at 8:10 PM Ilya Maximets wrote:
> On 7/17/24 13:42, Wilson Peng via dev wrote:
> > From: Wilson Peng
> >
> &
From: Wilson Peng
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
From: Wilson Peng
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
From: Wilson Peng
v2-v3 change: Remove the unneeded sanity check and just correct 3 failure
for function ObReferenceObjectByHandle, zoneInfo allocated failed and OvsNatInit
is failed on OvsInitConntrack.
While deploying Tanzu Kubernetes(Antrea based solution) in Broadcom customer,
Sometimes it i
From: Wilson Peng
v2-v3 change: Remove the unneeded sanity check and just correct the failure
when OvsNatInit is called failed.
While deploying Tanzu Kubernetes(Antrea based solution) in Broadcom customer,
Sometimes it is found that the kernel thread OvsConntrackEntryCleaner is not
Started after
From: Wilson Peng
v2-v3 change: Remove the unneeded sanity check and just correct the failure
when OvsNatInit is called failed.
While deploying Tanzu Kubernetes(Antrea based solution) in Broadcom customer,
Sometimes it is found that the kernel thread OvsConntrackEntryCleaner is not
Started after
From: Wilson Peng
v2-v3 change: Remove the unneeded sanity check and just correct the failure
when OvsNatInit is called failed.
While deploying Tanzu Kubernetes(Antrea based solution) in Broadcom customer,
Sometimes it is found that the kernel thread OvsConntrackEntryCleaner is not
Started after
Hi, Simon,
Below list why it would go into deadlock,
1). 1st place OvsCtExecute_()->OvsProcessConntrackEntry(). entry->parent
= parentEntry;(here parentEntry == entry)
2). After it return back from OvsProcessConntrackEntry(), it goes to the
lines below,(Still on function OvsCtExecute_())
iginal conntrack entry
(port1-->69) and lead to conntrack_entry parent be equal to itself.
Only ftp/tftp traffic processing will have parent-child logic.
Regards
Wilson
On Wed, Jun 5, 2024 at 8:32 PM Simon Horman wrote:
> On Wed, Jun 05, 2024 at 01:35:52PM +0800, Wilson Peng v
iginal conntrack entry
(port1-->69) and lead to conntrack_entry parent be equal to itself.
Only ftp/tftp traffic processing will have parent-child logic.
Regards
Wilson
On Wed, Jun 5, 2024 at 8:32 PM Simon Horman wrote:
> On Wed, Jun 05, 2024 at 01:35:52PM +0800, Wilson Peng v
From: Wilson Peng
It is found the TFTP reply packet with source port 69 will trigger host hang
And the possible coredump.
According to part 4 in TFTP RFC https://datatracker.ietf.org/doc/html/rfc1350,
The TFTP reply packet should use a new source-port(not 69) to connect to
Client.
Upon this TFT
From: Wilson Peng
It is found the TFTP reply packet with source port 69 will trigger host hang
And the possible coredump.
According to part 4 in TFTP RFC https://datatracker.ietf.org/doc/html/rfc1350,
The TFTP reply packet should use a new source-port(not 69) to connect to
Client.
Upon this TFT
From: Wilson Peng
It is found the TFTP reply packet with source port 69 will trigger host hang
And the possible coredump.
According to part 4 in TFTP RFC https://datatracker.ietf.org/doc/html/rfc1350,
The TFTP reply packet should use a new source-port(not 69) to connect to
Client.
Upon this TFT
From: Wilson Peng
It is found the TFTP reply packet with source port 69 will trigger host hang
And the possible coredump.
According to part 4 in TFTP RFC https://datatracker.ietf.org/doc/html/rfc1350,
The TFTP reply packet should use a new source-port(not 69) to connect to
Client.
Upon this TFT
From: Wilson Peng
It is found the TFTP reply packet with source port 69 will trigger host hang
And the possible coredump.
According to part 4 in TFTP RFC https://datatracker.ietf.org/doc/html/rfc1350,
The TFTP reply packet should use a new source-port(not 69) to connect to
Client.
Upon this TFT
From: Wilson Peng
While deploying Tanzu Kubernetes(Antrea based solution) in Broadcom customer,
Sometimes it is found that the kernel thread OvsConntrackEntryCleaner is not
started
After the Windows node is rebooted on unexpected condition. It could be also
observed a similar issue in local Ant
From: Wilson Peng
While deploying Tanzu Kubernetes(Antrea based solution) in Broadcom customer,
Sometimes it is found that the kernel thread OvsConntrackEntryCleaner is not
started
After the Windows node is rebooted on unexpected condition. It could be also
observed a similar issue in local Ant
From: Wilson Peng
While deploying Tanzu Kubernetes(Antrea based solution) in Broadcom
customer,
Sometimes it is found that the kernel thread OvsConntrackEntryCleaner is not
started
After the Windows node is rebooted on unexpected condition. It could be also
observed a similar issue in loca
Hi Simon,
Thanks for the comments and I have uploaded new patch with the
Updated notations in the patch. And also, I have updated the error log
Combined with the debug diff in the related reported issue
https://github.com/openvswitch/ovs-issues/issues/262
Regards
Wilson
From: dev on behalf of
Hi Alin,
Thanks for the comments. V2 version is sent out and it corrects the name
Off issue and rename the added variables. As this is bug fix, please help apply
It back to branch 3.0-2.14 also.
Regards
Wilson
From: dev on behalf of alinserd...@gmail.com
Date: Wednesday, November 9, 2022 at 02
Hi, Ilya,
Really thanks for the guidance and solution. New code diff could work on my
testing. New v3 patch according to your comments
is also submitted and the test result is also pasted in the v3 patch.
Regards
Wilson
From: dev on behalf of Ilya Maximets
Date: Tuesday, October 25, 2022 at
Hi, Ilya,
Thanks for the comments. V2 patch is sent out for review. And
It is also verified on Windows with the v2 patch.
Regards
Wilson
From: Ilya Maximets
Date: Thursday, October 20, 2022 at 19:31
To: Wilson Peng , d...@openvswitch.org
Cc: i.maxim...@ovn.org , Wilson Peng
Subject: Re: [o
Alin,
And help check the new fix patch below, it could be applied to
Mater and branch-3.0. It could make Geneve V6 tunnel could be
Working for checksum offload enabled case.
[ovs-dev,ovs-dev,v1,1/1] datapath-windows: Correct Geneve IPV6 header checksum
parameter
https://patchwork.ozlabs.org/proj
From: Wilson Peng
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_S
25 matches
Mail list logo
