[Ryu-devel] [PATCH v3] ofp_event: Timestamp when OpenFlow event was generated

This patch introduces "timestamp" attribute for OpenFlow event classes which shows when that event was generated by Datapath instance and nearly equivalent to when Ryu finished receiving the message contained in that event instance. Suggested-by: Matthew Hayes

Re: [Ryu-devel] [PATCH] packet/icmpv6: Fix parsing undefined nd_option fails

Thank you Fujimoto-san /Shivaram ::Sent from my mobile device:: > On Aug 1, 2017, at 9:39 PM, Fujimoto Satoshi > wrote: > > Hi, Shivaram > > Oops, I overlooked about it. > > It is needed for not only avoiding infinite loop, but also complying RFC. > For the

Re: [Ryu-devel] [PATCH] packet/icmpv6: Fix parsing undefined nd_option fails

Hi, Shivaram Oops, I overlooked about it. It is needed for not only avoiding infinite loop, but also complying RFC. For the 'length' field in options, RFC4861 says that: The value 0 is invalid. Nodes MUST silently discard an ND packet that contains an option with length zero. So

Re: [Ryu-devel] [PATCH v2] manager: Option to enable timestamp

Hi Fujita-San, On 2017年08月02日 10:30, FUJITA Tomonori wrote: On Tue, 25 Jul 2017 13:23:10 +0900 IWASE Yusuke wrote: This patch introduces a new option "--with-timestamp" which enable to get timestamp when Ryu received the OpenFlow message. Suggested-by: Matthew

Re: [Ryu-devel] [PATCH] packet/icmpv6: Fix parsing undefined nd_option fails

Hello, The patch from Bill was suggesting something like this: if cls_ is not None: option = cls_.parser(buf, offset) else: -option = buf[offset:offset + (length * 8 - 2)] +assert length > 0 # avoid infinite loop when

[Ryu-devel] [PATCH] packet/icmpv6: Fix parsing undefined nd_option fails

The length of nd_option is units of 8 octets. Currently, for nd_options which is undefined in the ICMPv6 packet library, the parser assumes that the length is [8 * length - 2]. It causes fails while parsing these options. This patch fixes it to parse such options correctly. Signed-off-by:

[Ryu-devel] 4.16 released

Hi, Here's a new release. = FUJITA Tomonori (1): Ryu 4.16 IWAMOTO Toshihiro (1): ofproto: Avoid emitting illegal instruction sets IWASE Yusuke (5): bgp_sample_conf: absolute_import to suppress warnings ofproto: Handle OFPErrorExperimenterMsg unit/ofproto: Adopt

Re: [Ryu-devel] [PATCH v2] manager: Option to enable timestamp

On Tue, 25 Jul 2017 13:23:10 +0900 IWASE Yusuke wrote: > This patch introduces a new option "--with-timestamp" which enable to > get timestamp when Ryu received the OpenFlow message. > > Suggested-by: Matthew Hayes > Signed-off-by: IWASE

Re: [Ryu-devel] Bug in ryu/lib/icmpv6.py

Hi, Shivaram Bill (CCed) isolated the problem to be inryu/lib/packet/icmpv6.py and provided a possible fix which works - https://list.waikato.ac.nz/pipermail/faucet-dev/2017-August/000223.html It looks good! I will make a patch for this. There will be a time lag before the patch is merged

Re: [Ryu-devel] Fields 'OUTPUT' and 'in_port' REST Ryu

Hi, Nicholas What you want to know is the meanings of these field in 'Add a flow entry' API, right? http://ryu.readthedocs.io/en/latest/app/ofctl_rest.html#add-a-flow-entry 'in_port' is used in 'match' field. It specifies an incoming port. If 'in_port' is specified to 2, the flow matches the

[Ryu-devel] Bug in ryu/lib/icmpv6.py

Hello, In trying to resolve a SSL connectivity issue per https://list.waikato.ac.nz/pipermail/faucet-dev/2017-August/000200.html we found a bug in Ryu packet parser code - please see the entire thread Bill (CCed) isolated the problem to be in ryu/lib/packet/icmpv6.py and provided a possible fix

[Ryu-devel] Fields 'OUTPUT' and 'in_port' REST Ryu

Hi guys! I don't understand what means the field 'actions: OUTPUT' and 'in_port' in REST Ryu. I would like to know what is the host destination and the host sender. Thank a lot! Nicholas -- Check out the vibrant tech

Re: [Ryu-devel] Modify simple switch app to show flow stats - IP TCP/UDP Protocols

Thank you very much. On Mon, Jul 31, 2017 at 2:12 AM, Fujimoto Satoshi < satoshi.fujimo...@gmail.com> wrote: > Hi, Boyan > > get_protocol() returns None if the argument doesn't match to the packet. > So, I guess Ryu might catch a packet other than TCP or UDP, such as SCTP. > > If you doesn't