Re: [Ryu-devel] Upgrading Ryu

The message you are receiving implies that the ryu-manager command cannot find where the needed modules it relies on are located. My best guess was the location I suggested in the PYTHONPATH, based on where ryu-manager had been installed. You will need to determine where the packages were

Re: [Ryu-devel] Upgrading Ryu

Try: export PYTHONPATH=$PYTHONPATH:/usr/local/lib/python2.7/site-packages Then, try: /usr/local/bin/ryu-manager Best, Victor -- Victor J. Orlikowski <> vjo@[cs.]duke.edu On Aug 30, 2016, at 8:42 AM, Túlio Pascoal > wrote:

Re: [Ryu-devel] Upgrading Ryu

Rather than: ./bin/ryu-manager What happens when you try: /usr/local/bin/ryu-manager ? Based on the output below, ryu is being installed into /usr/local... Best, Victor -- Victor J. Orlikowski <> vjo@[cs.]duke.edu > On Aug 30, 2016, at 8:36 AM, Túlio Pascoal wrote:

[Ryu-devel] [PATCH] Validate OpenFlow message length in header, to prevent controller receive loop DoS

Sigh. Re-submitting, with correct subject. When the controller receive loop currently accepts an OpenFlow message, it does not validate the message length. As a result, a malicious or malfunctioning switch could cause send a message that would result in the receive loop making no forward

[Ryu-devel] [PATCH] Handle SSL socket timeouts in controller gracefully

When the controller receive loop currently accepts an OpenFlow message, it does not validate the message length. As a result, a malicious or malfunctioning switch could cause send a message that would result in the receive loop making no forward progress. This patch ensures that the message

Re: [Ryu-devel] [Bug Report] Ryu hangs on "zero" length OpenFlow messages

On Aug 23, 2016, at 11:16 AM, Samuel Jero wrote: > I have now been able to test your patch against Ryu 4.5 with our > automated testing system. It does eliminate the infinite loop and > associated controller load, allowing the controller to continue to > operate and process

Re: [Ryu-devel] [Bug Report] Ryu hangs on "zero" length OpenFlow messages

On Aug 16, 2016, at 1:27 PM, Samuel Jero wrote: > > Sorry for the delay. Unfortunately, I won't be able to test your patch until > early next week. I'm busy finishing up an internship and moving back half way > across the country. Samuel, I hope that your move proceeded

Re: [Ryu-devel] BGPSpeaker - shutdown error. Why is this happening?

So, no - I don't think so. Based on the error message, it looks as though something in your environment is trying to start up the OpenFlow controller code in Ryu - and finding the controller port to already be bound. The shutdown() method you're calling in the BGP protocol code wouldn't even

Re: [Ryu-devel] BGPSpeaker - shutdown error. Why is this happening?

Ah...that may explain it. Is the simple switch in the same Ryu instance? Or another one? Or both? Reason I ask: something else is already using the OpenFlow port. The code you're running is trying to bind that port, and cannot (because of something else having it open). If you're trying to run

Re: [Ryu-devel] BGPSpeaker - shutdown error. Why is this happening?

On Aug 18, 2016, at 6:47 PM, Paulo Sérgio wrote: > > Right after the shutdown method call, it returns the following error: > failed to write to socket > Connection lost as protocol is no longer active > hub: uncaught exception: Traceback (most recent call last): > File

Re: [Ryu-devel] [Bug Report] Ryu hangs on "zero" length OpenFlow messages

On Aug 16, 2016, at 1:27 PM, Samuel Jero wrote: > > Sorry for the delay. Unfortunately, I won't be able to test your patch until > early next week. I'm busy finishing up an internship and moving back half way > across the country. NP - thanks for letting me know! It lets me

Re: [Ryu-devel] [Bug Report] Ryu hangs on "zero" length OpenFlow messages

On Aug 13, 2016, at 3:03 PM, Victor Orlikowski <v...@duke.edu> wrote: > > Nice catch! > If you would, can you please try the attached patch against Ryu 4.5, and see > if it resolves the issue for you? > It works "as expected" in my test environment. Hi there..

Re: [Ryu-devel] [Bug Report] Ryu hangs on "zero" length OpenFlow messages

On Aug 13, 2016, at 11:24 AM, Samuel Jero wrote: > > I'm part of a team of academic researchers working on automatically testing > SDN systems (the combination of switches and controllers) to find malicious > attacks. Using the system we have developed, which focuses

[Ryu-devel] [PATCH] Clean up stale Datapath objects in the ofctl_service application

A quick patch to clean up stale Datapath objects in the ofctl_service application. Signed-off-by: Victor J. Orlikowski --- diff --git a/ryu/app/ofctl/service.py b/ryu/app/ofctl/service.py index 0ca00c7..19aebd4 100644 --- a/ryu/app/ofctl/service.py +++ b/ryu/app/ofctl/service.py

[Ryu-devel] [PATCH] Ensure that send() and send_msg() in controller return status to calling applications...

When a Datapath disconnects, an application may not know about it until it attempts to send a message to that Datapath. Ryu's core will detect the failure to send, and will close the Datapath object - but has no way of letting the application know that it did so. With this patch, send_msg()

Re: [Ryu-devel] KeyboardInterrupt (ctrl-c) and RYU

Looks good to me, but I have not run it. ;) A couple of questions/comments: 1) I presume you have verified that all uses of "LOG" have been changed to "logger"? Given the scoping, It appears you should have gotten them all. 2) I would re-write the commit message thus: Currently, ryu-manager

Re: [Ryu-devel] KeyboardInterrupt (ctrl-c) and RYU

er desired default priority), that notes that Ctrl-C was received and applications are terminating. Best, Victor -- Victor J. Orlikowski <> vjo@[cs.]duke.edu > On Jul 20, 2016, at 11:20 AM, Victor Orlikowski <v...@duke.edu> wrote: > > Suggest just silently swallowing the

Re: [Ryu-devel] KeyboardInterrupt (ctrl-c) and RYU

Suggest just silently swallowing the KeyboardInterrupt (with a "pass"), since the finally block will cover the close(). Best, Victor -- Victor J. Orlikowski <> vjo@[cs.]duke.edu > On Jul 20, 2016, at 10:27 AM, "alan_ford...@keysight.com" > wrote: > >except

Re: [Ryu-devel] Testing Ryu with (updated) cbench

On May 19, 2016, at 6:08 PM, Victor J. Orlikowski wrote: > > A quick mailing list search suggests that there was a patch submitted, back > in 2013, to have all of Ryu be able to be run under cProfile; it doesn't > appear to have been committed. > It might make sense, though, to

Re: [Ryu-devel] Testing Ryu with (updated) cbench

On May 19, 2016, at 5:39 PM, André Mantas wrote: > > I think there's some misunderstanding here. As I've said, "the 1.0 version of > simple_switch" ONLY replies and works with the original version of cbench > (not my modified version). The original cbench version uses

Re: [Ryu-devel] Testing Ryu with (updated) cbench

On May 19, 2016, at 2:03 PM, André Mantas wrote: > > I'm updating cbench to emulate OpenFlow 1.4 switches (instead of 1.0) and I > just tested it against Ryu. > I noticed that there's a "cbench.py" app that I suppose it is to be used when > benchmarking Ryu. As I'm new

Re: [Ryu-devel] Error in executing the hub switching 13

On May 18, 2016, at 10:44 PM, Iwase Yusuke wrote: > > Thanks a lot! > I overlooked. No problem. ;) Best, Victor -- Victor J. Orlikowski <> vjo@[cs.]duke.edu -- Mobile security can be

Re: [Ryu-devel] Error in executing the hub switching 13

On May 18, 2016, at 10:30 PM, Iwase Yusuke wrote: > >> root@ubuntu:~# ovs-vsctl set Bridge s1 protcols=OpenFlow13 >> ovs-vsctl: Bridge does not contain a column whose name matches "protcols" I think this is simpler still: Try: protocols not: protcols Note the

Re: [Ryu-devel] PyPI has 4.0 as latest version?

On May 13, 2016, at 10:06 AM, FUJITA Tomonori wrote: > > Oops, sorry. Now both should be there. Thanks! Best, Victor -- Victor J. Orlikowski <> vjo@[cs.]duke.edu -- Mobile security can be enabling, not

Re: [Ryu-devel] [PATCH] Bump version requirement for oslo.config

On May 13, 2016, at 10:15 AM, FUJITA Tomonori wrote: > > Nice, thanks a lot! NP; thanks for applying it! Best, Victor -- Victor J. Orlikowski <> vjo@[cs.]duke.edu -- Mobile security can be enabling,

[Ryu-devel] PyPI has 4.0 as latest version?

Folks, Looks like PyPI is showing 4.0 as the latest version available; did 4.1 and 4.2 get missed? Thanks, Victor -- Victor J. Orlikowski <> vjo@[cs.]duke.edu -- Mobile security can be enabling, not merely

[Ryu-devel] [PATCH] Bump version requirement for oslo.config

Bump the version of oslo.config required in the pip-requires, since we started using the "min" parameter to IntOpt as of commit 1625117fbb33c0a490f0ce97510e4cdff936acea. The "min" parameter has only been available since the 1.15.0 version of oslo.config. >From

Re: [Ryu-devel] Proxy between OF1.0 and OF1.3?

On Apr 25, 2016, at 9:55 AM, Jerônimo Bezerra wrote: > > So, do you think I should purse this approach? > Sorry for the delayed response! I've been swamped with quite a bit. If you're *only* dealing with switches that have a single table - I think you *might* have a shot

Re: [Ryu-devel] Ryu 4.2 released

On May 10, 2016, at 4:13 AM, Jong Hun HAN wrote: > > File "/root/ryu_forked/ryu/ryu/controller/controller.py", line 72, in > > help='Maximum number of unreplied echo requests before datapath is > disconnected.') > File

Re: [Ryu-devel] (no subject)

On May 4, 2016, at 11:14 AM, ‫Eman Bany salameh‬ ‫‬ wrote: > > File > "/usr/local/lib/python2.7/dist-packages/ryu/ofproto/ofproto_v1_3_parser.py", > line 842, in __getitem__ > return dict(self._fields2)[key] > KeyError: 'ipv4_src' > > > what is the problem of

Re: [Ryu-devel] بخصوص: بخصوص: بخصوص: بخصوص: The idle_timeout Does Not Be Taken

That explains why your flow isn't timing out - but why OpenVSwitch isn't honoring your request to set an idle_timeout is somewhat mystifying. I would suggest looking at how the mininet folks advise you to use WireShark, here: http://mininet.org/walkthrough/ Use WireShark to see if the FlowMod

Re: [Ryu-devel] بخصوص: بخصوص: بخصوص: The idle_timeout Does Not Be Taken

On May 3, 2016, at 5:56 PM, ‫Eman Bany salameh‬ ‫‬ wrote: > > mininet> s1 ovs-ofctl dump-flows s1 You probably want: sh ovs-ofctl dump-flows s1 Best, Victor -- Victor J. Orlikowski <> vjo@[cs.]duke.edu

Re: [Ryu-devel] بخصوص: بخصوص: The idle_timeout Does Not Be Taken

On May 3, 2016, at 5:25 PM, ‫Eman Bany salameh‬ ‫‬ wrote: > > mod = parser.OFPFlowMod(datapath=datapath, buffer_id=buffer_id, > command=ofproto.OFPFC_ADD, >cookie=0, idle_timeout=2, > hard_timeout=0, >

Re: [Ryu-devel] بخصوص: The idle_timeout Does Not Be Taken

On May 3, 2016, at 4:22 PM, ‫Eman Bany salameh‬ ‫‬ wrote: > > I am using mininet with ovs-switch Ah - so, oddities with idle timeouts relating to how a given vendor implements timeouts will not apply in this case. How are you specifying the idle timeout? Do you mind

Re: [Ryu-devel] The idle_timeout Does Not Be Taken

On May 3, 2016, at 4:14 PM, ‫Eman Bany salameh‬ ‫‬ wrote: > > I want the flow to be removed from the table after 2 seconds from being idle, > so I set idle_timeout = 2. Although I didn't use the flow, it remains forever > in the table. This means that the value of

Re: [Ryu-devel] Proxy between OF1.0 and OF1.3?

Jeronimo, Long time since we met in person, at the I2 gathering (presuming you're the same Jeronimo from FIU). ;) Am I correct in presuming that you're trying to making a OF version-adapting proxy? A la FlowSpace Firewall or Flowvisor, but capable of translating from one version of OF to

[Ryu-devel] [PATCH] Handle SSL socket timeouts in controller gracefully

Eventlet throws a subclass of IOError on SSL read timeout. Without this patch, the read() loop exits on having received this normally innocuous event, causing unnecessary disconnect/reconnect cycles for switches. Thanks to Andy Hill for discovering this issue, and the initial version of this

Re: [Ryu-devel] [PATCH] controller: handle SSL socket timeouts

On Apr 19, 2016, at 7:17 PM, FUJITA Tomonori wrote: > >> Fujita-San - do you need me to re-submit the patch with a sign-off, etc.? > > Yes, please. You got it, in a separate email. ;) Best, Victor -- Victor J. Orlikowski <> vjo@[cs.]duke.edu

Re: [Ryu-devel] [PATCH] controller: handle SSL socket timeouts

On Apr 19, 2016, at 1:35 PM, Andy Hill wrote: > > Thanks for the feedback Victor. > > > I tried the patch and it works. Thanks for taking the time to try it, Andy. ;) Fujita-San - do you need me to re-submit the patch with a sign-off, etc.? Best, Victor -- Victor J.

Re: [Ryu-devel] [PATCH 1/8] Stability improvements to the core of Ryu; should be applied in order.

Iwamoto-San, Thank you! My apologies for not having followed up on this bugfix yet; I have been busy at work with other tasks. We have been using Ryu (and my application based on it) to drive our on-campus OpenFlow overlay network (using Arista and Cisco hardware), and have recently used the

Re: [Ryu-devel] [PATCH] controller: handle SSL socket timeouts

On Apr 12, 2016, at 7:33 PM, Andy Hill wrote: > > While testing ryu in an environment using a controller with SSL we saw > frequent disconnect/reconnects. > > This patch helps the issue for us. > How does the following work for you, instead? diff --git

Re: [Ryu-devel] [PATCH] controller: handle SSL socket timeouts

Glad it helps - but why not have the ssl.SSLError caught in its own except block? As long as the ssl.SSLError is handled before the EOFError/IOError, you should be fine, and the logic will be clearer. Best, Victor -- Victor J. Orlikowski <> vjo@[cs.]duke.edu > On Apr 12, 2016, at 7:34 PM,

Re: [Ryu-devel] [PATCH 8/8] Stability improvements to the core of Ryu; should be applied in order.

NM; you addressed this below. I see that, after re-reading your message. The queue being full doesn't necessarily bother me as a problem - but is an interesting idea to have it have the option of returning when full (rather than blocking). The callback function might be very useful; I like

Re: [Ryu-devel] [PATCH 8/8] Stability improvements to the core of Ryu; should be applied in order.

That sounds fine - but, what I meant was, when the send_q for a Datapath has been set to "None" - when a Datapath is shutting down - there might still be apps waiting to enqueue an asynchronous send. If that queue doesn't exist - a False should be returned from the send()/send_msg() to let the

Re: [Ryu-devel] [PATCH 8/8] Stability improvements to the core of Ryu; should be applied in order.

On Mar 1, 2016, at 11:40 PM, Victor Orlikowski <v...@duke.edu> wrote: > > Ah; OK. > > So, since we were trying to close file descriptors properly, there's one of > two ways to accomplish that: > 1) Have an echo request loop that does it automatically (and

[Ryu-devel] [PATCH] Cleanups to controller.py

A set of minor cleanups. 1) Remove the unused import of MAIN_DISPATCHER from ryu.controller.handler. 2) Remove the extraneous "close_requested" variable. 3) Ensure use of equality instead of identity for testing against DEAD_DISPATCHER. 4) Alter the exit condition for the _send_loop.

Re: [Ryu-devel] [PATCH 8/8] Stability improvements to the core of Ryu; should be applied in order.

@[cs.]duke.edu > On Mar 1, 2016, at 8:41 PM, Victor Orlikowski <v...@duke.edu> wrote: > > As of today, send() on a Datapath does not return an error to the application > that calls it. > The be

Re: [Ryu-devel] [PATCH 1/8] Stability improvements to the core of Ryu; should be applied in order.

No problem! I've got some more *minor* cleanups upcoming (removing the close_requested variable, and similar) - but that needs testing first, before I submit it. None of what I plan to submit, however, should significantly change functionality (or anything user exposed). Best, Victor --

Re: [Ryu-devel] [PATCH 8/8] Stability improvements to the core of Ryu; should be applied in order.

So... How would the core know when an application's record of a Datapath object is stale? I modeled these changes, to a certain degree, after what the dpset and topology applications do; none of these samples use either of those, so I did the simplest thing possible to do something similar,

Re: [Ryu-devel] [PATCH 1/8] Stability improvements to the core of Ryu; should be applied in order.

I normally do "git commit -m" from the command line - so I did not necessarily notice the commit message length; my apologies. I'm not quite sure what to do about correcting them after the fact, though. That said, that's not related to the content of the patch, right? Ditto re: the subject of

Re: [Ryu-devel] [PATCH 1/8] Stability improvements to the core of Ryu; should be applied in order.

Thank you, Fujita-San! Best, Victor -- Victor J. Orlikowski <> vjo@[cs.]duke.edu > On Feb 29, 2016, at 6:30 PM, FUJITA Tomonori > wrote: > > Thanks, I've fixed up these points: -- Site24x7

[Ryu-devel] [PATCH 8/8] Stability improvements to the core of Ryu; should be applied in order.

Update applications to remember and close() old Datapaths that may not longer be valid. Signed-off-by: Victor J. Orlikowski --- ryu/app/cbench.py | 8 ryu/app/ofctl/service.py | 2 ++ ryu/app/simple_switch.py | 7 ++-

[Ryu-devel] [PATCH 7/8] Stability improvements to the core of Ryu; should be applied in order.

A spate of typo fixes. Signed-off-by: Victor J. Orlikowski --- ryu/base/app_manager.py | 4 ++-- ryu/controller/controller.py | 8 ryu/lib/hub.py | 34 +- 3 files changed, 23 insertions(+), 23 deletions(-) diff --git

[Ryu-devel] [PATCH 6/8] Stability improvements to the core of Ryu; should be applied in order.

Add a new feature: an echo request loop, which implements a liveness check for connected Datapaths. This feature is off by default, but can be enabled by setting the config file option maximum_unreplied_echo_requests to a positive integer value. Signed-off-by: Victor J. Orlikowski

[Ryu-devel] [PATCH 5/8] Stability improvements to the core of Ryu; should be applied in order.

Change socket-timeout from being a CLI option to being a config file option, since this should not *normally* need to be set on the command line. Signed-off-by: Victor J. Orlikowski --- ryu/controller/controller.py | 8 ++-- 1 file changed, 6 insertions(+), 2 deletions(-)

[Ryu-devel] [PATCH 4/8] Stability improvements to the core of Ryu; should be applied in order.

Clean up socket close() handling still more. Also, temporarily work around a bug in eventlet's Queue.put() by wrapping the send_q with a semaphore. Signed-off-by: Victor J. Orlikowski --- ryu/controller/controller.py | 62 ++-- 1 file

[Ryu-devel] [PATCH 3/8] Stability improvements to the core of Ryu; should be applied in order.

Wrap handler calls in the event loop in a try/except, and log exceptions, in order to prevent an exception from terminating the execution of the event loop. Wrapper name also added to hub.py for GreenletExit. Signed-off-by: Victor J. Orlikowski --- ryu/base/app_manager.py | 12

[Ryu-devel] [PATCH 2/8] Stability improvements to the core of Ryu; should be applied in order.

Use a slightly lighter Queue implementation, that does not include an internal counter. Signed-off-by: Victor J. Orlikowski --- ryu/lib/hub.py | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/ryu/lib/hub.py b/ryu/lib/hub.py index 5621147..ce5e150 100644 ---

[Ryu-devel] [PATCH 1/8] Stability improvements to the core of Ryu; should be applied in order.

Protect events queue with a semaphore, due to a discovered bug in eventlet queue put(). This is a temporary workaround until eventlet is fixed. Signed-off-by: Victor J. Orlikowski --- ryu/base/app_manager.py | 3 +++ 1 file changed, 3 insertions(+) diff --git

Re: [Ryu-devel] [PATCH v5] Stability improvements to the core of Ryu, without requiring user application changes

On Feb 26, 2016, at 12:12 AM, IWAMOTO Toshihiro wrote: > > I think it's optional but separating these things into different > patches is good. Also please write commit messages that concisely > describe the changes and your problem, not changelog from older > patchsets.

Re: [Ryu-devel] [PATCH v5] Stability improvements to the core of Ryu, without requiring user application changes

> On Feb 26, 2016, at 12:12 AM, IWAMOTO Toshihiro wrote: > > From the eventlet code, acquire() has no chance to return other than > True. I think such an assert statement with a side-effect should be > avoided in general. Things will break when someone decides to turn

[Ryu-devel] A question, affecting the stability patch...

Folks, As of right now, the stability patch is, I believe, *nearly* "good enough." Something occurred to me, though, as I considered the interactions of classes implementing RyuApp. A given handler, in a given RyuApp, is acting in response to a *single* event that has been consumed from the

[Ryu-devel] [PATCH v5] Stability improvements to the core of Ryu, without requiring user application changes

A few more minor changes: 1) Place an assertion on one of the semaphore acquire() calls. 2) Clean up some naming and structure for greater clarity; one of the name changes is a reversion of an earlier name change in an accepted patch. 3) I thought of another couple of corner cases.

[Ryu-devel] [PATCH v4] Stability improvements to the core of Ryu, without requiring user application changes

Minor change: since I am not using PriorityQueue anymore, it does not need to be present in hub.py. Signed-off-by: Victor J. Orlikowski diff --git a/ryu/base/app_manager.py b/ryu/base/app_manager.py index 3d5d895..ed60857 100644 --- a/ryu/base/app_manager.py +++

Re: [Ryu-devel] [PATCH v2] Stability improvements to the core of Ryu, without requiring user application changes

I have not yet. I had planned to submit a patch upstream, but wanted to get this resolved first, especially since the eventlet community does not seem terribly responsive. I will be *glad* to remove the semaphores, once eventlet has been fixed upstream (possibly by me). Until then, the

[Ryu-devel] [PATCH v3] Stability improvements to the core of Ryu, without requiring user application changes

After extensive testing in the lab, I have established that the timeouts used for queue get() operations are not strictly necessary. Therefore, I am removing them, per Iwamoto-san's request. The semaphore protecting put(), however, *is* required. I have also reverted back to a simple queue,

Re: [Ryu-devel] [PATCH v2] Stability improvements to the core of Ryu, without requiring user application changes

his change, and that it is better to make the correct change now (so as to make the behavior correct, and further decrease the likelihood of causing any issues with user applications). Best, Victor -- Victor J. Orlikowski <> vjo@[cs.]duke.edu > On Feb 22, 2016, at 10:46 PM, Victor Orliko

Re: [Ryu-devel] [PATCH v2] Stability improvements to the core of Ryu, without requiring user application changes

On Feb 22, 2016, at 10:18 PM, IWAMOTO Toshihiro wrote: > > on an unrelated note, have you considered going for true > multi-threading (Python's native threading for example) as eventlet > cannot make use of multiple CPUs? > True multi-threading in Python isn't really,

Re: [Ryu-devel] [PATCH v2] Stability improvements to the core of Ryu, without requiring user application changes

I await them eagerly. ;) Do note - the changes to how I use the PriorityQueue are required by, and specified in, the documentation for the heapq module. Best, Victor -- Victor J. Orlikowski <> vjo@[cs.]duke.edu > On Feb 22, 2016, at 9:31 PM, IWAMOTO Toshihiro wrote: >

[Ryu-devel] [PATCH] Stability improvements to the core of Ryu, without requiring user application changes

After re-examining the logic in controller.py, I have removed some of the complexity in the socket closure logic. This code has passed testing in the lab using the following tests: 1) tcpkill 'port 6633' 2) iptables -I INPUT -p tcp -m tcp --dport 6633 -j DROP Each of the above are performed

[Ryu-devel] [PATCH v2] Stability improvements to the core of Ryu, without requiring user application changes

After re-examining the code again and re-testing, I have simplified the patch still further. Signed-off-by: Victor J. Orlikowski diff --git a/ryu/base/app_manager.py b/ryu/base/app_manager.py index 3d5d895..f162cdf 100644 --- a/ryu/base/app_manager.py +++

[Ryu-devel] [PATCH] Stability improvements to the core of Ryu, without requiring user application changes

After more discussion with Iwamoto-San, cut things down to 2 semaphores. In doing so, it was discovered that PriorityQueues *don't* maintain FIFO ordering by default. In order to achieve FIFO ordering, a counter has to be used, per:

Re: [Ryu-devel] [PATCH] Stability improvements to the core of Ryu, without requiring user application changes

On Feb 18, 2016, at 2:27 PM, Victor Orlikowski <v...@duke.edu> wrote: > > That having been said - if we're not getting events of the same priority in > FIFO order due to the PriorityQueue - that's may not be a good thing. I will > consider it further. Trying again - se

Re: [Ryu-devel] [PATCH] Stability improvements to the core of Ryu, without requiring user application changes

On Feb 18, 2016, at 1:46 PM, Victor J. Orlikowski wrote: > > 1) Cut the number of semaphores to 2 (PacketIns and "everything else"). This isn't going to work. I tried moving to a single priority queue and 2 semaphores (PacketIns, and "everything else") in our lab environment.

Re: [Ryu-devel] [PATCH] Stability improvements to the core of Ryu, without requiring user application changes

On Feb 17, 2016, at 11:16 PM, IWAMOTO Toshihiro wrote: > I think the code is mostly okay now. > Well - that's a start. ;) >> +self.events = hub.PriorityQueue(96) >> +self._event_get_timeout = 5 >> +# The sum of the following semaphores must equal

[Ryu-devel] [PATCH] Stability improvements to the core of Ryu, without requiring user application changes

After discussion with Iwamoto-San, merge 3 queues into 1 priority queue, but address potential of priority inversion using 3 semaphores. The move to 1 queue uncovered additional events that need to be higher priority, as well. Signed-off-by: Victor J. Orlikowski diff --git

Re: [Ryu-devel] [PATCH] Stability improvements to the core of Ryu, without requiring user application changes

On Feb 16, 2016, at 7:50 PM, IWAMOTO Toshihiro wrote: > With a software switch such as openvswitch, PacketIn events may not > happen. That's true; that can *also* be the case with a hardware switch, though. > And even with your situation, in a interval where there's no

Re: [Ryu-devel] [PATCH] Stability improvements to the core of Ryu, without requiring user application changes

> On Feb 14, 2016, at 9:54 PM, IWAMOTO Toshihiro wrote: > I think you can use eventlet.queue.PriorityQueue instead of these 3 > queues. (see below) > > Let us have: > > self.events = hub.PriorityQueue(128) > No, this will not work. If the priority queue

[Ryu-devel] [PATCH] Stability improvements to the core of Ryu, without requiring user application changes

Address PEP8 violations, reported here: https://travis-ci.org/fujita/ryu/jobs/108267416 Signed-off-by: Victor J. Orlikowski diff --git a/ryu/base/app_manager.py b/ryu/base/app_manager.py index 3d5d895..b08c6c5 100644 --- a/ryu/base/app_manager.py +++ b/ryu/base/app_manager.py @@

Re: [Ryu-devel] [PATCH] Stability improvements to the core of Ryu, without requiring user application changes

Iwamoto-San, My responses are inline. On Feb 10, 2016, at 3:00 AM, IWAMOTO Toshihiro wrote: >> +self._events_sem = hub.BoundedSemaphore(self.events.maxsize) >> +self._sc_events_sem = hub.BoundedSemaphore(self.sc_events.maxsize) >> +

[Ryu-devel] [PATCH] Stability improvements to the core of Ryu, without requiring user application changes

Correcting logical and stylistic errors caught by Iwamoto-San. Signed-off-by: Victor J. Orlikowski diff --git a/ryu/base/app_manager.py b/ryu/base/app_manager.py index 3d5d895..b08c6c5 100644 --- a/ryu/base/app_manager.py +++ b/ryu/base/app_manager.py @@ -37,6 +37,7 @@ from

Re: [Ryu-devel] [PATCH] Stability improvements to the core of Ryu, without requiring user application changes

I see it; the DummyOpenFlowApp needs a handler_execution_timeout field added. Do you need me to re-submit the entire patch, or just a fix for the test case? Either way, I will address this in the morning; it's well past midnight here... ;) Best, Victor -- Victor J. Orlikowski <>

Re: [Ryu-devel] [PATCH] Stability improvements to the core of Ryu, without requiring user application changes

On Feb 10, 2016, at 1:38 AM, Victor Orlikowski <v...@duke.edu> wrote: > > Either way, I will address this in the morning; it's well past midnight > here... ;) Never mind; patch to cover the unit test incoming. It's the "MagicMock" object that doesn't have the requis

Re: [Ryu-devel] [PATCH] Stability improvements to the core of Ryu, without requiring user application changes

m.org> wrote: > > Hi, > > On Wed, 27 Jan 2016 05:38:29 + > Victor Orlikowski <v...@duke.edu> wrote: > >> Per Iwase-San’s request, here is a re-worked stabilty patch that does *not* >> require patching user applications. >> Instead, the

[Ryu-devel] [PATCH] Stability improvements to the core of Ryu, without requiring user application changes

Re-sending... Per Fujita-San's request, the echo request loop is off by default. It is easily enabled by setting the "maximum-unreplied-echo-requests" configuration option to a non-zero value. Signed-off-by: Victor J. Orlikowski diff --git a/ryu/base/app_manager.py

[Ryu-devel] [PATCH] Stability improvements to the core of Ryu, without requiring user application changes

Correcting a unit test failure. Signed-off-by: Victor J. Orlikowski diff --git a/ryu/base/app_manager.py b/ryu/base/app_manager.py index 3d5d895..eac2c42 100644 --- a/ryu/base/app_manager.py +++ b/ryu/base/app_manager.py @@ -37,6 +37,7 @@ from ryu.controller.handler import

Re: [Ryu-devel] [PATCH] Stability improvements to the core of Ryu, without requiring user application changes

On Feb 2, 2016, at 3:26 PM, FUJITA Tomonori wrote: > > I like to avoid big changes to the core feature right before a > release. So I will merge this soon for the 3.31 (or 4.0). Fair enough; thanks! As an FYI - there's a bunch of cleanups (that are not *strictly* necessary) to

Re: [Ryu-devel] [PATCH] Stability improvements to the core of Ryu, without requiring user application changes

Is there hope for this patch being integrated for 3.30, or is it going to be considered for the 3.31 cycle instead? I am glad to address any issues or concerns, if any are still present. Best, Victor -- Victor J. Orlikowski <> vjo@[cs.]duke.edu > On Jan 31, 2016, at 9:23 AM, Victor O

[Ryu-devel] Heads up, re: OFPFC_ADD...

Folks, We ran into a fun time debugging an issue w/ one of our switch vendors, and I wanted to share it, since some of the sample applications make use of the same functionality. The controller application that we are developing (based off of rest_router) was seeing PacketIn storms related to

Re: [Ryu-devel] [PATCH] Stability improvements to the core of Ryu, without requiring user application changes

On Jan 31, 2016, at 7:33 AM, FUJITA Tomonori wrote: > > I think that implementing echo requests to find a dead datapath is > great. But disabling the feature by default is better (safer). I would > not be so surprised if there are some broken switches which don't > reply to echo

[Ryu-devel] [PATCH] Stability improvements to the core of Ryu, without requiring user application changes

Per Fujita-San's request, the echo request loop is off by default. It is easily enabled by setting the "maximum-unreplied-echo-requests" configuration option to a non-zero value. Signed-off-by: Victor J. Orlikowski diff --git a/ryu/base/app_manager.py b/ryu/base/app_manager.py

Re: [Ryu-devel] [PATCH] Stability improvements to the core of Ryu, without requiring user application changes

On Jan 31, 2016, at 7:33 AM, FUJITA Tomonori wrote: > > Why we need semaphore for getting from /putting to a queue? I discovered, in testing, that eventlet synchronized queues are broken with respect to synchronization. They have missed wakeup problems that lead to them not

Re: [Ryu-devel] [PATCH v2] Ensure that usage of icmp.dest_unreach and icmp.TimeExceeded in rest_router.py complies with RFC 4884

On Jan 31, 2016, at 9:13 AM, FUJITA Tomonori wrote: > > Thanks, I see. Then only one problem remains, the following pep8 error: > > ./ryu/app/rest_router.py:1547:45: E226 missing whitespace around arithmetic > operator > ERROR: InvocationError:

Re: [Ryu-devel] [PATCH v2] Ensure that usage of icmp.dest_unreach and icmp.TimeExceeded in rest_router.py complies with RFC 4884

On Jan 31, 2016, at 7:56 AM, FUJITA Tomonori wrote: > > The above behavior works with others (OSes, switches, etc)? As you > pointed out, the current code looks broken w.r.t. the original > datagram but it works? The IP stack on most OSes is liberal in what it will accept. Yes -

[Ryu-devel] [PATCH v3] Ensure that usage of icmp.dest_unreach and icmp.TimeExceeded in rest_router.py complies with RFC 4884

Correcting a PEP8 violation, per Fujita-San's request. When using the icmp.dest_unreach and icmp.TimeExceeded classes, we should ensure that it is in compliance with RFC 4884. As such, the data_len parameter passed to the constructor of each should be interpreted in 32 bit units. Furthermore -

[Ryu-devel] [PATCH v2] Ensure that usage of icmp.dest_unreach and icmp.TimeExceeded in rest_router.py complies with RFC 4884

Sigh. Brown paper bag re-submit, to cover an "off-by-one." When using the icmp.dest_unreach and icmp.TimeExceeded classes, we should ensure that it is in compliance with RFC 4884. As such, the data_len parameter passed to the constructor of each should be interpreted in 32 bit units.

Re: [Ryu-devel] Drop Python 2.6 support

The only semi-likely case is that folks still on RHEL/CentOS 6 (for various reasons) will have to use python 2.7 from RHSCL, or upgrade to 7. Otherwise, no real impact; most other distributions have moved along from 2.6. Best, Victor -- Victor J. Orlikowski <> vjo@[cs.]duke.edu > On Jan 30,

Re: [Ryu-devel] Drop Python 2.6 support

And, upon actually *reading* the link you sent, you already covered that case. ;) Sorry for spamming with re-hashed information. Best, Victor -- Victor J. Orlikowski <> vjo@[cs.]duke.edu > On Jan 30, 2016, at 9:40 AM, Victor Orlikowski <v...@duke.edu> wrote: > > The

[Ryu-devel] [PATCH] Better validate parameters to constructors better in lib/packet/icmp.py

Re-submitting, at Fujita-San's request; patch both inline and attached. According to RFC 4884 (which supersedes RFC 792), the Destination Unreachable and Time Exceeded ICMP message get a new “length” field. This length field, for ICMPv4, is interpreted in 32 bit units. In the constructor, we

Re: [Ryu-devel] Ryu installation fails

On Jan 29, 2016, at 4:16 PM, Emmanuel Stapf wrote: > > I am using Ryu for quite a while now and I already installed it several times > on different Ubuntu 14.04 64Bit VMs that all had the same configuration. > I never had a problem with the installation but suddenly

  1   2   >