Re: [Ryu-devel] Flow removed handler fails , Cannot parse header in OF version 1.5

[rahul b]

Hi Iwase,

Yes, i intend to use, OF 1.5 only.
Thanks for your help on this issue.!

Regards,
Rahul




On Tuesday, December 5, 2017, Iwase Yusuke  wrote:

> Hi Rahul,
>
> Could you keep the Ryu-devel mailing list?
>
> Well... if you keep this change on only your local, I think it has no side
> effect with the OpenFlow 1.3-1.5.
> It seems to replace the parser for OFPT_FLOW_REMOVED message as expected.
> With the OpenFlow 1.0-1.2, it might have some problems, but you intend to
> use
> only 1.5, right?
>
> Thanks,
> Iwase
>
>
> On 2017年12月05日 00:35, rahul b wrote:
>
>> Hi Iwase,
>> Thanks for taking your time to explain the problem.
>>
>> Flow removed handler is  a very critical piece for me, So i am planning
>> to put in a hack in *"ryu/ofproto/ofproto_parser.py" *as follows.
>>
>>   if(msg_type == 11):
>>  LOG.info("Overriding the Parser Version for  ofp_type 11")
>> *msg_parser = _MSG_PARSERS.get(4)  # use OF 1.3 parser*
>> else:
>>  msg_parser = _MSG_PARSERS.get(version)
>>
>> with this hack, i am able to decode the ofp_type 11 message.
>>
>> I Wanted to know as per your knowledge do you think this could cause any
>> side effects/errors in any other features.?
>>
>> Thanks & Regards,
>> Rahul
>>
>>
>> On Mon, Dec 4, 2017 at 10:12 AM, Iwase Yusuke > > wrote:
>>
>> Hi Rahul,
>>
>> I manually decoded the binary data OVS sent, OVS does not seem to
>> follow the
>> OFPT_FLOW_REMOVED message format which the OpenFlow Spec 1.5 defines.
>>
>> For example, I received the following message on my environment;
>> ===
>> Encountered an error while parsing OpenFlow packet from switch. This
>> implies
>> the switch sent a malformed OpenFlow packet. version 0x06 msg_type 11
>> msg_len 72 xid 0 buf 0x06 0x0b 0x00 0x48 0x00 0x00 0x00 0x00 0x00
>> 0x00 0x00
>> 0x00 0x00 0x00 0x00 0x00 0x00 0x01 0x02 0x00 0x00 0x00 0x00 0x25 0x0d
>> 0xb5
>> 0x85 0x80 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x03
>> 0x00
>> 0x00 0x00 0x00 0x00 0x00 0x00 0xee 0x00 0x01 0x00 0x16 0x80 0x00 0x00
>> 0x04
>> 0x00 0x00 0x00 0x01 0x80 0x00 0x06 0x06 0xfe 0x97 0x30 0x28 0x44 0xad
>> 0x00 0x00
>> ===
>>
>> "buf 0x06 0x0b 0x00 ..." shows the binary data which Ryu received
>> from OVS.
>> And the OpenFlow Spec 1.5 defines the the OFPT_FLOW_REMOVED message
>> like;
>> ===
>> struct ofp_flow_removed {
>>struct ofp_header {
>>  uint8_t version;  /* OFP_VERSION. */
>>  uint8_t type; /* One of the OFPT_ constants. */
>>  uint16_t length;  /* Length including this ofp_header. */
>>  uint32_t xid; /* Transaction id associated with this packet.
>>   Replies use the same id as was in the
>> request
>>   to facilitate pairing. */
>>} header;
>>uint8_t table_id; /* ID of the table */
>>uint8_t reason;   /* One of OFPRR_*. */
>>uint16_t priority;/* Priority level of flow entry. */
>>uint16_t idle_timeout;/* Idle timeout from original flow mod.
>> */
>>uint16_t hard_timeout;/* Hard timeout from original flow mod.
>> */
>>uint64_t cookie;  /* Opaque controller-issued identifier.
>> */
>>struct ofp_match match;   /* Description of fields. Variable size.
>> */
>>//struct ofp_stats stats; /* Statistics list. Variable size. */
>> };
>> ===
>>
>> If follows the above format;
>> ===
>> struct ofp_header {
>>0x06 version
>>0x0b type (= OFPT_FLOW_REMOVED(11))
>>0x00 0x48 length
>>0x00 0x00 0x00 0x00 xid
>> }
>> 0x00 table_id
>> 0x00 reason
>> 0x00 0x00 priority
>> 0x00 0x00 idle_timeout
>> 0x00 0x00 hard_timeout
>> // "0x00 0x01 0x02 0x00" is a part of cookie ...? match ...?
>>...(snip)...
>> ===
>>
>> Please confirm OVS supports the OFPT_FLOW_REMOVED message with
>> OpenFlow 1.5.
>> To follow the OpenFlow Spec 1.5, it is required to support "EXT-334",
>> it might
>> be on the TODOs of OVS project.
>> https://github.com/openvswitch/ovs/blob/master/Documentation
>> /topics/openflow.rst#openflow-15-only
>> > n/topics/openflow.rst#openflow-15-only>
>>
>> I read some source code of OVS, the OFPT_FLOW_REMOVED message is not
>> updated
>> from the format of OpenFlow 1.1...
>> https://github.com/openvswitch/ovs/blob/99cf99597ffa9f09e66d
>> 646d04de8d1c7e6d52c8/lib/ofp-util.c#L3306
>> > d646d04de8d1c7e6d52c8/lib/ofp-util.c#L3306>
>>
>>
>> Thanks,
>> Iwase
>>
>> On 2017年12月01日 23:38, rahul b wrote:
>>
>> Hi i am using,
>>
>> (Open vSwitch) 2.7.4
>> DB Schema 7.14.0
>>
>> Openflow version 1.5
>>
>>  

Re: [Ryu-devel] Flow removed handler fails , Cannot parse header in OF version 1.5

[Iwase Yusuke]

Hi Rahul,

Could you keep the Ryu-devel mailing list?

Well... if you keep this change on only your local, I think it has no side
effect with the OpenFlow 1.3-1.5.
It seems to replace the parser for OFPT_FLOW_REMOVED message as expected.
With the OpenFlow 1.0-1.2, it might have some problems, but you intend to use
only 1.5, right?

Thanks,
Iwase


On 2017年12月05日 00:35, rahul b wrote:

Hi Iwase,
Thanks for taking your time to explain the problem.

Flow removed handler is  a very critical piece for me, So i am planning to put 
in a hack in *"ryu/ofproto/ofproto_parser.py" *as follows.


  if(msg_type == 11):
         LOG.info("Overriding the Parser Version for  ofp_type 11")
*msg_parser = _MSG_PARSERS.get(4)  # use OF 1.3 parser*
else:
         msg_parser = _MSG_PARSERS.get(version)

with this hack, i am able to decode the ofp_type 11 message.

I Wanted to know as per your knowledge do you think this could cause any side 
effects/errors in any other features.?


Thanks & Regards,
Rahul


On Mon, Dec 4, 2017 at 10:12 AM, Iwase Yusuke > wrote:


Hi Rahul,

I manually decoded the binary data OVS sent, OVS does not seem to follow the
OFPT_FLOW_REMOVED message format which the OpenFlow Spec 1.5 defines.

For example, I received the following message on my environment;
===
Encountered an error while parsing OpenFlow packet from switch. This implies
the switch sent a malformed OpenFlow packet. version 0x06 msg_type 11
msg_len 72 xid 0 buf 0x06 0x0b 0x00 0x48 0x00 0x00 0x00 0x00 0x00 0x00 0x00
0x00 0x00 0x00 0x00 0x00 0x00 0x01 0x02 0x00 0x00 0x00 0x00 0x25 0x0d 0xb5
0x85 0x80 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x03 0x00
0x00 0x00 0x00 0x00 0x00 0x00 0xee 0x00 0x01 0x00 0x16 0x80 0x00 0x00 0x04
0x00 0x00 0x00 0x01 0x80 0x00 0x06 0x06 0xfe 0x97 0x30 0x28 0x44 0xad 0x00 
0x00
===

"buf 0x06 0x0b 0x00 ..." shows the binary data which Ryu received from OVS.
And the OpenFlow Spec 1.5 defines the the OFPT_FLOW_REMOVED message like;
===
struct ofp_flow_removed {
   struct ofp_header {
     uint8_t version;  /* OFP_VERSION. */
     uint8_t type;     /* One of the OFPT_ constants. */
     uint16_t length;  /* Length including this ofp_header. */
     uint32_t xid;     /* Transaction id associated with this packet.
                          Replies use the same id as was in the request
                          to facilitate pairing. */
   } header;
   uint8_t table_id;         /* ID of the table */
   uint8_t reason;           /* One of OFPRR_*. */
   uint16_t priority;        /* Priority level of flow entry. */
   uint16_t idle_timeout;    /* Idle timeout from original flow mod. */
   uint16_t hard_timeout;    /* Hard timeout from original flow mod. */
   uint64_t cookie;          /* Opaque controller-issued identifier. */
   struct ofp_match match;   /* Description of fields. Variable size. */
   //struct ofp_stats stats; /* Statistics list. Variable size. */
};
===

If follows the above format;
===
struct ofp_header {
   0x06 version
   0x0b type (= OFPT_FLOW_REMOVED(11))
   0x00 0x48 length
   0x00 0x00 0x00 0x00 xid
}
0x00 table_id
0x00 reason
0x00 0x00 priority
0x00 0x00 idle_timeout
0x00 0x00 hard_timeout
// "0x00 0x01 0x02 0x00" is a part of cookie ...? match ...?
   ...(snip)...
===

Please confirm OVS supports the OFPT_FLOW_REMOVED message with OpenFlow 1.5.
To follow the OpenFlow Spec 1.5, it is required to support "EXT-334", it 
might
be on the TODOs of OVS project.

https://github.com/openvswitch/ovs/blob/master/Documentation/topics/openflow.rst#openflow-15-only



I read some source code of OVS, the OFPT_FLOW_REMOVED message is not updated
from the format of OpenFlow 1.1...

https://github.com/openvswitch/ovs/blob/99cf99597ffa9f09e66d646d04de8d1c7e6d52c8/lib/ofp-util.c#L3306




Thanks,
Iwase

On 2017年12月01日 23:38, rahul b wrote:

Hi i am using,

(Open vSwitch) 2.7.4
DB Schema 7.14.0

Openflow version 1.5

On deleting a flow i am encountering this error, this is a message sent
in response to the flow rule being removed.

However  the flow deletion is going successfully, but Ryu is not able to
parse this message i believe.


Encountered an error while parsing OpenFlow packet from switch. This
implies the switch sent a malformed OpenFlow packet. version 0x06
msg_type 11 msg_len 72 xid 0 buf 0x06 0x0b 0x00 0x48 0x00 0x00 0x00 0x00
0x00 0x00 0x00 0x00 0x00 0x00 0x07 0xd0 0x00 0x64 0x02 0x00 0x00 

Re: [Ryu-devel] Flow removed handler fails , Cannot parse header in OF version 1.5

[Iwase Yusuke]

Hi Rahul,

I manually decoded the binary data OVS sent, OVS does not seem to follow the
OFPT_FLOW_REMOVED message format which the OpenFlow Spec 1.5 defines.

For example, I received the following message on my environment;
===
Encountered an error while parsing OpenFlow packet from switch. This implies the 
switch sent a malformed OpenFlow packet. version 0x06 msg_type 11 msg_len 72 xid 
0 buf 0x06 0x0b 0x00 0x48 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 
0x00 0x00 0x01 0x02 0x00 0x00 0x00 0x00 0x25 0x0d 0xb5 0x85 0x80 0x00 0x00 0x00 
0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x03 0x00 0x00 0x00 0x00 0x00 0x00 0x00 
0xee 0x00 0x01 0x00 0x16 0x80 0x00 0x00 0x04 0x00 0x00 0x00 0x01 0x80 0x00 0x06 
0x06 0xfe 0x97 0x30 0x28 0x44 0xad 0x00 0x00

===

"buf 0x06 0x0b 0x00 ..." shows the binary data which Ryu received from OVS.
And the OpenFlow Spec 1.5 defines the the OFPT_FLOW_REMOVED message like;
===
struct ofp_flow_removed {
  struct ofp_header {
uint8_t version;  /* OFP_VERSION. */
uint8_t type; /* One of the OFPT_ constants. */
uint16_t length;  /* Length including this ofp_header. */
uint32_t xid; /* Transaction id associated with this packet.
 Replies use the same id as was in the request
 to facilitate pairing. */
  } header;
  uint8_t table_id; /* ID of the table */
  uint8_t reason;   /* One of OFPRR_*. */
  uint16_t priority;/* Priority level of flow entry. */
  uint16_t idle_timeout;/* Idle timeout from original flow mod. */
  uint16_t hard_timeout;/* Hard timeout from original flow mod. */
  uint64_t cookie;  /* Opaque controller-issued identifier. */
  struct ofp_match match;   /* Description of fields. Variable size. */
  //struct ofp_stats stats; /* Statistics list. Variable size. */
};
===

If follows the above format;
===
struct ofp_header {
  0x06 version
  0x0b type (= OFPT_FLOW_REMOVED(11))
  0x00 0x48 length
  0x00 0x00 0x00 0x00 xid
}
0x00 table_id
0x00 reason
0x00 0x00 priority
0x00 0x00 idle_timeout
0x00 0x00 hard_timeout
// "0x00 0x01 0x02 0x00" is a part of cookie ...? match ...?
  ...(snip)...
===

Please confirm OVS supports the OFPT_FLOW_REMOVED message with OpenFlow 1.5.
To follow the OpenFlow Spec 1.5, it is required to support "EXT-334", it might
be on the TODOs of OVS project.
https://github.com/openvswitch/ovs/blob/master/Documentation/topics/openflow.rst#openflow-15-only

I read some source code of OVS, the OFPT_FLOW_REMOVED message is not updated
from the format of OpenFlow 1.1...
https://github.com/openvswitch/ovs/blob/99cf99597ffa9f09e66d646d04de8d1c7e6d52c8/lib/ofp-util.c#L3306


Thanks,
Iwase

On 2017年12月01日 23:38, rahul b wrote:

Hi i am using,

(Open vSwitch) 2.7.4
DB Schema 7.14.0

Openflow version 1.5

On deleting a flow i am encountering this error, this is a message sent in 
response to the flow rule being removed.


However  the flow deletion is going successfully, but Ryu is not able to parse 
this message i believe.



Encountered an error while parsing OpenFlow packet from switch. This implies the 
switch sent a malformed OpenFlow packet. version 0x06 msg_type 11 msg_len 72 xid 
0 buf 0x06 0x0b 0x00 0x48 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x07 
0xd0 0x00 0x64 0x02 0x00 0x00 0x00 0x00 0x00 0x00 0x0f 0x42 0x40 0x00 0x00 0x00 
0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 
0x00 0x00 0x01 0x00 0x12 0x80 0x00 0x0a 0x02 0x08 0x06 0x80 0x00 0x2c 0x04 0xc0 
0xa8 0x01 0x0a 0x00 0x00 0x00 0x00 0x00 0x00

Traceback (most recent call last):
   File "/usr/local/lib/python2.7/dist-packages/ryu/ofproto/ofproto_parser.py", 
line 67, in msg

     msg = msg_parser(datapath, version, msg_type, msg_len, xid, buf)
   File 
"/usr/local/lib/python2.7/dist-packages/ryu/ofproto/ofproto_v1_5_parser.py", 
line 59, in msg_parser

     return parser(datapath, version, msg_type, msg_len, xid, buf)
   File 
"/usr/local/lib/python2.7/dist-packages/ryu/ofproto/ofproto_v1_5_parser.py", 
line 1561, in parser

     msg.match = OFPMatch.parser(msg.buf, offset)
   File 
"/usr/local/lib/python2.7/dist-packages/ryu/ofproto/ofproto_v1_5_parser.py", 
line 773, in parser

     n, value, mask, field_len = ofproto.oxm_parse(buf, offset)
   File "/usr/local/lib/python2.7/dist-packages/ryu/ofproto/oxx_fields.py", line 
193, in _parse

     field_len) = _parse_header_impl(mod, buf, offset)
   File "/usr/local/lib/python2.7/dist-packages/ryu/ofproto/oxx_fields.py", line 
179, in _parse_header_impl

*assert value_len > 0*
*AssertionError*


it would be very helpful if you could look into this.

Thanks,
Rahul


--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot



___
Ryu-devel mailing list
Ryu-devel@lists.sourceforge.net