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
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
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
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
On Thu, Jun 6, 2024 at 8:56 PM Simon Horman wrote:
> On Wed, Jun 05, 2024 at 09:26:02PM +0800, Wilson Peng wrote:
> > Hi, Simon,
> > In this case, for tftp packet processing, it does have a child-parent
> > processing logic just like ftp in tcp.
> > Tftp packet1
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
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
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
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
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
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
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
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
of Simon Horman
Date: Wednesday, November 9, 2022 at 02:55
To: Wilson Peng
Cc: d...@openvswitch.org
Subject: Re: [ovs-dev] [PATCH v1 1/1] netdev-windows: Add checking when
creating netdev with system type on Windows
!! External Email
On Thu, Oct 13, 2022 at 10:50:51PM +0800, Wilson Peng wrote
From: Wilson Peng
In the recent Antrea project testing, some port could not be created
on Windows.
When doing debug, our team found there is one case happening when multiple
ports are waiting for be created with correct port number.
Some system type port will be created netdev successfully
, November 8, 2022 8:01 PM
To: 'Wilson Peng' ; 'd...@openvswitch.org'
Subject: RE: [ovs-dev] [PATCH v1 1/1] datapath-windows: Check the condition
to reset pseudo header checksum on Rx side
Hi Wilson,
Thank you for the patch. Just a small nit rest looks good.
Please see below.
-Original Message
From: Wilson Peng
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
at 03:15
To: Wilson Peng , d...@openvswitch.org
Cc: i.maxim...@ovn.org
Subject: Re: [ovs-dev] [PATCH v2 1/1] lib: Correct the stats of packet_count
and byte_count on Windows
⚠ External Email
On 10/21/22 17:53, Wilson Peng wrote:
> From: Wilson Peng
>
> The stats is got via func
From: Wilson Peng
The stats(byte_count) is got via function call ofputil_decode_flow_stats_reply()
and for OpenFlow15 it will also call oxs_pull_entry__(). Currently we found on
Windows the byte_count counter is incorrect. It will get the byte_count on
OpenFlow15
handling via ntohll
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
From: Wilson Peng
The stats is got via function call ofputil_decode_flow_stats_reply() and
for OpenFlow15 it will also call oxs_pull_entry__(). Currently we found on
Windows the counter is incorrect.
From the output below, it is incorrect for the n_bytes counter via OpenFlow15 on
CMD ovs-ofctl
From: Wilson Peng
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
From: Wilson Peng
The stats is got via function call ofputil_decode_flow_stats_reply() and
for OpenFlow15 it will also call oxs_pull_entry__(). Currently we found on
Windows the counter is incorrect.
From the output below, it is incorrect for the n_bytes counter via OpenFlow15 on
CMD ovs-ofctl
From: Wilson Peng
In the recent Antrea project testing, some port could not be created
on Windows.
When doing debug, our team found there is one case happening when multiple
ports are waiting for be created with correct port number.
Some system type port will be created netdev successfully
From: Wilson Peng
In the recent Antrea project testing, some port could not be created
on Windows.
When doing debug, our team found there is one case happening when multiple
ports are waiting for be created with correct port number.
Some system type port will be created netdev successfully
From: Wilson Peng
In the recent Antrea project testing, some port could not be created
on Windows.
When doing debug, our team found there is one case happening when multiple
ports are waiting for be created with correct port number.
Some system type port will be created netdev successfully
/project/openvswitch/patch/ma0pr01mb62181e8e4b31322bcfd2900188...@ma0pr01mb6218.indprd01.prod.outlook.com/
Regards
Wilson
From: Dejing Liu
Date: Friday, August 26, 2022 at 15:28
To: Alin-Gabriel Serdean , d...@openvswitch.org
Cc: svc.ovs-community , Wilson Peng
, Frank Guo , Lina Li
Subject: Re
From: Wilson Peng
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
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
From: Wilson Peng
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
From: Wilson Peng
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
://github.com/openvswitch/ovs-issues/issues/232
Signed-off-by: Wilson Peng
---
datapath-windows/ovsext/Conntrack.c | 19 ++-
1 file changed, 18 insertions(+), 1 deletion(-)
diff --git a/datapath-windows/ovsext/Conntrack.c
b/datapath-windows/ovsext/Conntrack.c
index 2610d626a..3b2b5fd32
://github.com/openvswitch/ovs-issues/issues/232
Signed-off-by: Wilson Peng
---
datapath-windows/ovsext/Conntrack.c | 20 +++-
1 file changed, 19 insertions(+), 1 deletion(-)
diff --git a/datapath-windows/ovsext/Conntrack.c
b/datapath-windows/ovsext/Conntrack.c
index 2610d626a..8d0e55eed
ged 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
---
datapath-windows/ovsext/Actions.
From: Wilson Peng
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
Reported-at:https://github.com/openvswitch/ovs-issues/issues/229
Signed-off-by: Wilson Peng
---
datapath-windows/ovsext/Actions.c | 10 ++
datapath-windows/ovsext/Recirc.c | 18 --
datapath-windows/ovsext/Recirc.h | 3 +++
3 files changed, 25 insertions(+), 6 deletions(-)
dif
.
To be honest that looks like a bug.
We should return an error if the it is not a valid VLAN frame.
-Original Message-
From: Wilson Peng
Sent: Wednesday, September 29, 2021 5:52 PM
To: Alin-Gabriel Serdean ; ovs-dev@openvswitch.org
Subject: Re: [ovs-dev] [PATCH
From: wilsonpeng
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
Alin,
Original code diff is to avoid the case below(it will return
NDIS_STATUS_SUCCESS before
RtlMoveMemory in function OvsPopFieldInPacketBuf).
Regards
Wilson
In function OvsPopFieldInPacketBuf(..)
if (!bufferData) {
EthHdr *ethHdr = (EthHdr *)bufferStart;
/* If the frame is
/contributing/submitting-patches/
And I also subscribe the mail-list for ovs-dev, but I could not get the patch I
have submitted.
This is the first time I sent out the patch into the OVS community. Not sure
how could I go
To proceed for the patch submitting.
Regards
Wilson Peng(pweis...@vmware.com
42 matches
Mail list logo
