Add tunnel key support to CAPWAP vport. Uses the optional WSI field in a
CAPWAP header to store a 64bit key. It can also be used without keys, in which
case it is backward compatible with the old code. Documentation about the
WSI field format is in CAPWAP.txt.
Signed-off-by: Valient Gough
This improves on the previous patches by tightening packet header validation by
checking most of the header fields before parsing the packet.
Also ensures that all packets of a fragment stream have the same key by
including the key as part of the fragment queue identifier (and the hash).
Valient
Add tunnel key support to CAPWAP vport. Uses the optional WSI field in a
CAPWAP header to store a 64bit key. It can also be used without keys, in which
case it is backward compatible with the old code. Documentation about the
WSI field format is in CAPWAP.txt.
Signed-off-by: Valient Gough
Thanks Jesse. Your comment about skb_pull makes sense now. I'm
sending an updated patch which addresses your comments and fixes
fragment handling.
-- Valient
___
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev
: Valient Gough
---
datapath/CAPWAP.txt | 80 +
datapath/Makefile.am|2 +-
datapath/Modules.mk |4 +
datapath/vport-capwap.c | 218 ++-
lib/netdev-vport.c | 12 +--
vswitchd/vswitch.xml| 26 ++
6
Simon,
Below is an updated patch to add key support to CAPWAP tunnels. It is still
broken in one aspect - fragmented packet reassembly fails. It correctly
*creates* fragmented packets, as verified by Wireshark's CAPWAP implementation
which is able to reassemble fragmented streams. I have not le
phone)
On Jun 29, 2011 12:36 AM, "Simon Horman" wrote:
> From: Valient Gough
>
> Add tunnel key support to CAPWAP vport. Uses the optional WSI field in a
> CAPWAP header for storing a 64bit key. It can also be used without keys,
in
> which case it is backward compatible wi
On Mon, Mar 7, 2011 at 4:57 PM, Jesse Gross wrote:
> On Wed, Mar 2, 2011 at 1:11 PM, Valient Gough wrote:
>>
>> When testing OVS within Amazon's public EC2 cloud, I found my tests were
>> limited by being unable to use GRE tunnels (the EC2 network transfers only
>
.txt in patch below), and then a WSI field consisting of 0b80 +
[key].
Valient Gough (1):
datapath: add key support to CAPWAP tunnel
datapath/CAPWAP.txt | 80 +
datapath/vport-capwap.c | 151 --
lib/netdev-vport.c
On Mar 1, 2011, at 6:31 PM, Jesse Gross wrote:
>
> Setting TNL_F_OUT_KEY_ACTION means that the key will be provided on a
> per-flow basis using a datapath action instead of being statically
> associated with the port.
Thanks, I'm dropping this patch and will send a capwap patch for review inste
On Tue, Mar 1, 2011 at 4:36 PM, Jesse Gross wrote:
> On Tue, Mar 1, 2011 at 3:39 PM, Valient Gough wrote:
>>
>> While adding support for a tunnel with optional tunnel key, I've found
>> problems handling the key configuration. In existing tunnel code, such as
>>
below in
tunnel.c will set the ACTION flag if NO key is provided, which means a tunnel
with key support will always attempt to insert a key. Patch below.
Valient Gough (1):
datapath: fix out key action flag setting.
datapath/tunnel.c |4 ++--
1 files changed, 2 insertions(+), 2 dele
Valient Gough (1):
datapath: call tnl_ops only after setting options
datapath/tunnel.c | 12 ++--
1 files changed, 6 insertions(+), 6 deletions(-)
>From a141c2cc52c18e170bd48e265719e02b5b47b2a4 Mon Sep 17 00:00:00 2001
From: Valient Gough
Date: Thu, 24 Feb 2011 21:45:18 -0
On Thu, Feb 24, 2011 at 8:25 PM, Jesse Gross wrote:
> On Thu, Feb 24, 2011 at 7:43 PM, Valient Gough wrote:
>>
>> The call to tnl_ops->hdr_len should not occur before all options are setup.
>> If the call happens earlier, then tunnels may end up using uninitialized
>&
The call to tnl_ops->hdr_len should not occur before all options are setup.
If the call happens earlier, then tunnels may end up using uninitialized
options. This patch moves the hdr_len call after the output key setup.
diff -ur openvswitch/datapath/tunnel.c openvswitch-gre/datapath/tunnel.c
--
15 matches
Mail list logo
