Bleep bloop. Greetings Darrell Ball, I am a robot and I have tried out your
patch.
Thanks for your contribution.
I encountered some error that I wasn't expecting. See the details below.
git-am:
fatal: corrupt patch at line 307
Repository lacks necessary blobs to fall back on 3-way merge.
Cann
Tests are added to cover out of order fragments, overlapping fragments
and multiple extension headers in the case of IPv6.
Signed-off-by: Darrell Ball
---
tests/system-kmod-macros.at | 16
tests/system-traffic.at | 200 +++
tests/system-use
Signed-off-by: Darrell Ball
---
NEWS| 2 +
lib/conntrack.c | 114 +---
lib/conntrack.h | 13 ++
lib/ct-dpif.c | 24 +++
lib/ct-dpif.h | 13 ++
lib/dpctl.c | 62 +++
The ipv4 fragmentation check is broken and allows fragments through.
There were fragile and poorly maintainable checks in extract_l3_ipv*
designed to save a few cycles. The checks make assumptions about what
sanity checks may have been done and could be skipped based on inferring
from the value of
I sent a more complete V2.
Darrell
On Wed, Jun 27, 2018 at 6:49 PM, Darrell Ball wrote:
> Non-distributed and distributed gateway load balancing is broken.
> Recent changes for port unreachable handling broke the associated
> unsnat functionality.
>
> Fixes: 86558ac2e476 ("OVN: add UDP port un
Non-distributed and distributed gateway load balancing is broken.
Recent changes for port unreachable handling broke the associated
unsnat functionality. The fix approach is check for gateway
contexts and accept packets directed to gateway router IPs.
Fixes: 86558ac2e476 ("OVN: add UDP port unre
On Sat, Jun 23, 2018 at 05:16:32AM -0700, William Tu wrote:
>
> Discussion
> ==
> We are still actively working on finishing the feature, currently
> the basic forwarding and tunnel feature work, but still under
> heavy debugging and development. The purpose of this RFC is to
> get some e
Non-distributed and distributed gateway load balancing is broken.
Recent changes for port unreachable handling broke the associated
unsnat functionality.
Fixes: 86558ac2e476 ("OVN: add UDP port unreachable support to OVN logical
router.")
Fixes: 159932c9e4ea ("OVN: add TCP port unreachable supp
The separator line always starts with three dashes on a line, optionally
followed by either white-space, OR a single space and a filename. The
regex would previously match on any three dashes in a row. This means
that a patch (such as [1]) would trigger the parser state machine to
advance beyond
On Wed, Jun 27, 2018 at 2:09 PM, Mark Michelson wrote:
> On 06/26/2018 10:22 PM, Han Zhou wrote:
>
>> On Wed, Jun 20, 2018 at 11:04 PM, Ben Pfaff wrote:
>>
>>>
>>> To make ovn-controller recompute incrementally, we need accurate
>>> dependencies for each function that reads or writes a table. I
> On Jun 25, 2018, at 11:23 AM, Ben Pfaff wrote:
>
> This can't cause a crash and doesn't seem relevant to normal operation.
>
> Reported-at: https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=9044
> Signed-off-by: Ben Pfaff
Acked-by: Justin Pettit
Thanks for fixing all these issues tha
> On Jun 21, 2018, at 3:53 PM, Ben Pfaff wrote:
>
> The port_add() function checks whether the port about to be added to the
> dpif is already present and adds it only if it is not. This duplicates a
> check also present (and necessary) in each dpif and races with it as well.
> When a dpif has
On kernel versions (for example, 3.10) where upstream provides GRE
functionality but no ERSPAN, GRE can fail to initialize. Because
there is no ERSPAN feature in kernel, openvswitch kernel module will
try to register its own IPPROTO_GRE, instead of using the upstream
GRE functionality. But GRE coul
> On Jun 25, 2018, at 11:50 AM, Ben Pfaff wrote:
>
> The length check was wrong for immediate arguments to "learn" actions.
>
> Reported-at: https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=9047
> Signed-off-by: Ben Pfaff
> ---
> lib/ofp-actions.c | 2 +-
> 1 file changed, 1 insertion(+),
> On Jun 23, 2018, at 10:29 AM, Ben Pfaff wrote:
>
> Shifting a 16-bit signed int 16 bits is technically undefined behavior.
> This fixes the problem. (In practice this should be harmless in this
> case.)
>
> Reported-at; https://oss-fuzz.com/v2/testcase-detail/4730143510626304
> Signed-off-b
> On Jun 25, 2018, at 12:45 PM, Ben Pfaff wrote:
>
> Shifting a 16-bit signed int 16 bits is technically undefined behavior.
> This fixes the problem. (In practice this should be harmless in this
> case.)
>
> Reported-at: https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=9049
> Signed-off
> On Jun 25, 2018, at 1:07 PM, Ben Pfaff wrote:
>
> Reported-at: https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=9052
> Signed-off-by: Ben Pfaff
Acked-by: Justin Pettit
--Justin
___
dev mailing list
d...@openvswitch.org
https://mail.openvs
Thanks for the patch. It doesn't seem to apply cleanly against master. Can
you please respin it?
Also, the note about backporting it to 2.9 is helpful, but can you move it to a
place where it won't be part of the commit message?
--Justin
> On Jun 25, 2018, at 11:33 AM, Darrell Ball wrote:
Hi Aaron,
Thanks for your comments!
On Wed, Jun 27, 2018 at 1:12 PM, Aaron Conole wrote:
>
> Qiuyu Xiao writes:
>
> > This patch adds CA-cert based authentication to the ovs-monitor-ipsec
> > daemon. With CA-cert based authentication enabled, OVS approves IPsec
> > tunnel if the peer has a cert
Hi Aaron,
I made some changes to the interface of the ovs-monitor-ipsec
configuration, that is why the tests all failed. I am waiting for Ansis'
review for the patch. If he agrees the change, I will change the test
script as well. That will fix this.
BTW, 0-day robot is really cool! Sorry to trig
Qiuyu Xiao writes:
> This patch adds CA-cert based authentication to the ovs-monitor-ipsec
> daemon. With CA-cert based authentication enabled, OVS approves IPsec
> tunnel if the peer has a cert signed by a trusted CA and the identity of
> the peer cert is as expected. Belows are the major change
Thanks for the patch. It's really cool to see IPSec being
re-integrated. Just a few quick comments inline.
Qiuyu Xiao writes:
> From: Ansis Atteka
>
> This patch reintroduces ovs-monitor-ipsec daemon that
> was previously removed by commit 2b02d770 ("openvswitch:
> Allow external IPsec tunnel
Qiuyu Xiao writes:
> This patch series reintroduce IPsec support for OVS tunneling and adds new
> features to prepare for the OVN IPsec support. The new features are:
>
> 1) Add CA-cert based authentication support to ovs-monitor-ipsec.
> 2) Enable ovs-pki to generate x.509 version 3 certificate.
Bleep bloop. Greetings Qiuyu Xiao, I am a robot and I have tried out your
patch.
Thanks for your contribution.
I encountered some error that I wasn't expecting. See the details below.
checkpatch:
WARNING: Line is 80 characters long (recommended limit is 79)
#60 FILE: Documentation/howto/ipsec
Bleep bloop. Greetings Qiuyu Xiao, I am a robot and I have tried out your
patch.
Thanks for your contribution.
I encountered some error that I wasn't expecting. See the details below.
checkpatch:
WARNING: Line is 85 characters long (recommended limit is 79)
#372 FILE: debian/openvswitch-ipsec
This patch modifies ovs-pki to generate x.509 version 3 certificate.
Compared with the x.509 v1 certificate generated by ovs-pki, version 3
certificate adds subjectAltName field and sets its value the same as
common name (CN). The main reason for this change is to enable
strongSwan IKE daemon to ex
This patch adds CA-cert based authentication to the ovs-monitor-ipsec
daemon. With CA-cert based authentication enabled, OVS approves IPsec
tunnel if the peer has a cert signed by a trusted CA and the identity of
the peer cert is as expected. Belows are the major changes and the
reasons:
1) Added
From: Ansis Atteka
This patch reintroduces ovs-monitor-ipsec daemon that
was previously removed by commit 2b02d770 ("openvswitch:
Allow external IPsec tunnel management.")
The reason for removal at the time was that there were IPsec
flavoured tunnel types, like ipsec_gre, that consumed for
thems
Hi Shashank,
libunbound also supports windows. I think this is one of reasons we
selected libunbound.
Best,
Yifeng
On Tue, Jun 26, 2018 at 7:27 PM, Shashank Ram wrote:
>
>
> On Tue, Jun 26, 2018 at 7:08 PM Yifeng Sun wrote:
>
>> This patch is a simple implementation for the proposal discussed
This patch series reintroduce IPsec support for OVS tunneling and adds new
features to prepare for the OVN IPsec support. The new features are:
1) Add CA-cert based authentication support to ovs-monitor-ipsec.
2) Enable ovs-pki to generate x.509 version 3 certificate.
Ansis Atteka (1):
ipsec: r
Thanks Aaron
I think this is a valid error.
I had 2 patch series touching common lines from the same working branch; I
intended to check the git context boundaries, but forgot :-)
I will roll up the 2 series.
Darrell
On Wed, Jun 27, 2018 at 8:06 AM, Aaron Conole wrote:
> Hi Darrell,
>
> 0-day
---
Este correo electrónico ha sido comprobado en busca de virus por AVG.
http://www.avg.com
___
dev mailing list
d...@openvswitch.or
On Wed, Jun 27, 2018 at 05:02:31PM +0200, Eelco Chaudron wrote:
>
>
> On 27 Jun 2018, at 16:09, Ben Pfaff wrote:
>
> >On Wed, Jun 27, 2018 at 01:24:25PM +0200, Eelco Chaudron wrote:
> >>In field deployments of OVS (mostly in combination with OpenStack) we
> >>see that the 2K default MAC forwardi
On Wed, Jun 27, 2018 at 6:48 AM, Roi Dayan wrote:
>
>
> On 26/06/2018 20:43, John Hurley wrote:
>> A LAG slave cannot be added directly to an OvS bridge, nor can a OvS
>> bridge port be added to a LAG dev. However, LAG masters can be added to
>> OvS.
>>
>> Use TC blocks to indirectly offload slave
Hi Darrell,
0-day Robot writes:
> Bleep bloop. Greetings Darrell Ball, I am a robot and I have tried out your
> patch.
> Thanks for your contribution.
>
> I encountered some error that I wasn't expecting. See the details below.
>
>
> checkpatch:
> ERROR: Too many signoffs; are you missing Co-
On Mon, Jun 25, 2018 at 08:46:45PM -0700, Pravin Shelar wrote:
> On Mon, Jun 25, 2018 at 8:55 AM, Florian Westphal wrote:
> > These versions deal with the l3proto/l4proto details internally.
> > It removes only caller of nf_ct_get_tuple, so make it static.
> >
> > After this, l3proto->get_l4proto(
On 27 Jun 2018, at 16:09, Ben Pfaff wrote:
On Wed, Jun 27, 2018 at 01:24:25PM +0200, Eelco Chaudron wrote:
In field deployments of OVS (mostly in combination with OpenStack) we
see that the 2K default MAC forwarding table is too small.
On average this tables is around 5k entries, hence this
Bleep bloop. Greetings Ian Stokes, I am a robot and I have tried out your
patch.
Thanks for your contribution.
I encountered some error that I wasn't expecting. See the details below.
checkpatch:
WARNING: Comment with 'xxx' marker
#506 FILE: lib/netdev-dpdk.c:591:
* XXX: this is a re
0-day Robot writes:
> Bleep bloop. Greetings Eelco Chaudron, I am a robot and I have tried out
> your patch
> with message ID
> Thanks for your contribution.
I'm disabling the distcheck output until the tests can run consistently
on the system.
___
On Wed, Jun 27, 2018 at 01:24:25PM +0200, Eelco Chaudron wrote:
> In field deployments of OVS (mostly in combination with OpenStack) we
> see that the 2K default MAC forwarding table is too small.
>
> On average this tables is around 5k entries, hence this patch to
> increase the default value to
This commit re-introduces the concept of shared mempools as the default
memory model for DPDK devices. Per port mempools are still available but
must be enabled explicitly by a user.
OVS previously used a shared mempool model for ports with the same MTU
and socket configuration. This was replaced
On Wed, Jun 27, 2018 at 03:11:07PM +0530, rakesh kumar wrote:
> Thanks Ben,
>
>
> *OVS doesn't do anything special with it. It treats it like any
> otherfield.*
>
> Could you please elaborate the above mentioned point.
>
> My intention here was to know how OVS Queue the traffic(*Packets*) at
On Wed, Jun 27, 2018 at 10:52:06AM +0100, Ian Stokes wrote:
> On 6/25/2018 7:56 PM, 0-day Robot wrote:
> >Bleep bloop. Greetings Ian Stokes, I am a robot and I have tried out your
> >patch.
> >Thanks for your contribution.
> >
> >I encountered some error that I wasn't expecting. See the details
On Wed, Jun 27, 2018 at 09:17:16AM -0400, Aaron Conole wrote:
> Ben Pfaff writes:
>
> > On Tue, Jun 26, 2018 at 08:58:38AM -0400, Aaron Conole wrote:
> >> The scissors line is always three dashes on a line. The regex would
> >> previously match on any three dashes in a row.
> >>
> >> This means
Ben Pfaff writes:
> On Tue, Jun 26, 2018 at 08:58:38AM -0400, Aaron Conole wrote:
>> The scissors line is always three dashes on a line. The regex would
>> previously match on any three dashes in a row.
>>
>> This means that a patch (such as [1]) would trigger the parser state
>> machine to adv
On 27 Jun 2018, at 12:09, Lam, Tiago wrote:
> On 26/06/2018 11:31, Eelco Chaudron wrote:
>>
>>
>> On 22 Jun 2018, at 21:04, Lam, Tiago wrote:
>>
>>> On 18/06/2018 12:50, Eelco Chaudron wrote:
On 11 Jun 2018, at 18:21, Tiago Lam wrote:
> Most helper functions in dp-packet
Bleep bloop. Greetings Eelco Chaudron, I am a robot and I have tried out your
patch
with message ID
Thanks for your contribution.
I encountered a 'make distcheck' failure. See the details below.
2613: mcast - check multicasts to trunk ports are not duplicated ok
2614: mcast - delete the port md
In field deployments of OVS (mostly in combination with OpenStack) we
see that the 2K default MAC forwarding table is too small.
On average this tables is around 5k entries, hence this patch to
increase the default value to the next power of 2, i.e. 8K.
This increase in size does not automaticall
On 26/06/2018 13:28, Eelco Chaudron wrote:
>
>
> On 22 Jun 2018, at 21:04, Lam, Tiago wrote:
>
>> On 18/06/2018 12:55, Eelco Chaudron wrote:
>>>
>>>
>>> On 11 Jun 2018, at 18:21, Tiago Lam wrote:
>>>
In its current implementation dp_packet_shift() is also unaware of
multi-seg mbufs (th
On 26/06/2018 11:31, Eelco Chaudron wrote:
>
>
> On 22 Jun 2018, at 21:04, Lam, Tiago wrote:
>
>> On 18/06/2018 12:50, Eelco Chaudron wrote:
>>>
>>>
>>> On 11 Jun 2018, at 18:21, Tiago Lam wrote:
>>>
Most helper functions in dp-packet assume that the data held by a
dp_packet is contigu
On 26/06/2018 14:23, Eelco Chaudron wrote:
>
>
> On 22 Jun 2018, at 21:02, Lam, Tiago wrote:
>
>> Hi Eelco,
>>
>> On 18/06/2018 12:18, Eelco Chaudron wrote:
>>>
>>>
>>> On 11 Jun 2018, at 18:21, Tiago Lam wrote:
>>>
>>
>> [snip]
>>
Performance notes
=
In order to t
On 6/25/2018 7:56 PM, 0-day Robot wrote:
Bleep bloop. Greetings Ian Stokes, I am a robot and I have tried out your
patch.
Thanks for your contribution.
I encountered some error that I wasn't expecting. See the details below.
checkpatch:
== Checking d0b5c881a538 ("dpdk: Support both shared a
Thanks Ben,
*OVS doesn't do anything special with it. It treats it like any
otherfield.*
Could you please elaborate the above mentioned point.
My intention here was to know how OVS Queue the traffic(*Packets*) at port
which are coming from datapath(kernel space), it would really help me if
yo
On 6/26/2018 9:30 PM, Aaron Conole wrote:
Hi Ian,
Ian Stokes writes:
This commit re-introduces the concept of shared mempools as the default
memory model for DPDK devices. Per port mempools are still available but
must be enabled explicitly by a user.
OVS previously used a shared mempool mod
54 matches
Mail list logo
