On 08/13/2016 03:03 PM, Victor Orlikowski wrote: > On Aug 13, 2016, at 11:24 AM, Samuel Jero <sj...@purdue.edu> wrote: >> 1) When an OpenFlow message with a header whose length field is zero is >> received, Ryu hangs and becomes unresponsive. The problem appears to be an >> infinite loop in _recv_loop() in controller.py. The header length field is >> taken to be the OpenFlow message without any validation (<8 is invalid). As >> a result, no data is removed from the buffer being processed and the >> controller loops infinitely trying to process this same header. Inspection >> of the current 4.5 code suggests that this bug is still present. > 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.
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 messages from other switches. The switch that is sending messages with bad lengths will eventually be disconnected due to an unparsable message. Thanks for the quick response on this, and apologies for taking so long to test the patch. >> 2)When an OpenFlow packet_in message is received containing zero bytes of >> the triggering packet (switches can be configured to send only the first X >> bytes of a packet in the packet_in message), Ryu crashes with the following >> trace: >> hub: uncaught exception: Traceback (most recent call last): >> File "/usr/local/lib/python2.7/dist-packages/ryu/lib/hub.py", line 52, >> in _launch >> func(*args, **kwargs) >> File "/usr/local/lib/python2.7/dist-packages/ryu/base/app_manager.py", >> line 276, in _event_loop >> handler(ev) >> File "/root/ryu/ryu/app/simple_switch.py", line 61, in >> _packet_in_handler >> if eth.ethertype == ether_types.ETH_TYPE_LLDP: >> AttributeError: 'NoneType' object has no attribute 'ethertype' >> The problem appears to be that the simple_switch app, and probably others, >> assumes that there is at least an Ethernet header present, which may be an >> inaccurate assumption. Inspection of the current 4.5 code suggests that this >> code is unchanged and still contains this bug. > So... > As I understand it (from my discussions with others on the list), the > simple_switch* apps are intended to be *simple-to-understand* examples, which > *may not necessarily* be 100% robust. As a result, malformed packets or > unusual switch behaviors can crash them, quite easily. > > That having been said... > > The app_manager should no longer necessarily crash in this case, as of Ryu > 4.0. > Might I suggest re-testing with a version of Ryu that's 4.0 or newer? > You should see that such an exception will not result in a crash - but > *should* result in continued operation, with the exception logged, instead. I also retested with Ryu 4.5 and found, as you suspected, that Ryu >4.0 does not crash under this condition any more. Instead, Ryu logs an exception from the packet handler and continues operation. This allows it to correctly process other requests. --Samuel -- Samuel Jero Doctoral Student Computer Science Dependable and Secure Distributed Systems Lab Purdue University sj...@purdue.edu http://www.sjero.net
signature.asc
Description: OpenPGP digital signature
------------------------------------------------------------------------------
_______________________________________________ Ryu-devel mailing list Ryu-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/ryu-devel
