Hi, Hirasawa-san

I'm glad to hear that.
I was going to make patch after confirming improvement on your environment anyway,
so I will send my patch to Ryu soon.

Thanks,
Fujimoto

On 2018年03月29日 10:28, Takayoshi Hirasawa wrote:
Fujimoto-san

Thank you for your patch.
I tried it and confirmed improvement of ryu's behavior.

This behavior may cause switch fabric down by external attack packet made by 
openflow channel, but does this patch apply to Ryu original script?

Thank you,
Hirasawa

----------------------------------------------
Takayoshi Hirasawa
NTT NS Lab.
Tel: 0422-59-7294 / Fax: 0422-59-4656
Email: hirasawa.takayo...@lab.ntt.co.jp
      : takayoshi.hirasawa...@hco.ntt.co.jp
-----------------------------------------^-^--


-----Original Message-----
From: Fujimoto Satoshi [mailto:satoshi.fujimo...@gmail.com]
Sent: Tuesday, March 06, 2018 11:48 AM
To: hirasawa.takayo...@lab.ntt.co.jp
Cc: ryu-devel@lists.sourceforge.net
Subject: Re: [Ryu-devel] ryu freeze when ryu picks up segment packet

Hi, Hirasawa-san

Sorry for late reply.

In parsing OpenFlow packets,
Ryu checks its TCP header and predicts like that "this packet contains
OpenFlow data".

However, if these packets are segmented, succeeding body does not have
OpenFlow header, it has only segmented OpenFlow body.
Then, Ryu tries to parse OpenFlow header for that body.
This is the cause of the problem.

I wrote the patch to cease parsing when the result of parsing for header
is invalid.
Could you try this?


diff --git a/ryu/lib/packet/openflow.py b/ryu/lib/packet/openflow.py
index e211994..2d4a0d9 100644
--- a/ryu/lib/packet/openflow.py
+++ b/ryu/lib/packet/openflow.py
@@ -46,6 +46,8 @@ class openflow(packet_base.PacketBase):
           from ryu.ofproto import ofproto_protocol

           (version, msg_type, msg_len, xid) = ofproto_parser.header(buf)
+        if version not in ofproto_protocol._versions or msg_len !=
len(buf):
+            raise struct.error

           msg_parser = ofproto_parser._MSG_PARSERS.get(version)
           if msg_parser is None:


Thanks,
Fujimoto

On 2018年02月15日 20:04, Takayoshi Hirasawa wrote:
Fujimoto-san

Sorry for my late reply.

I send the script which we use to debug Ryu packet library.
Could you try this script? If this causes errors, there is something
wrong with Ryu in your environment.
      $ python display_pcap.py ryu-ovs-loopback.pcap
=> I tried this script and confirmed that there is no errors.

* Could you tell me which version of Ryu you are using?
=> I used ryu 4.20.

* Could you confirm that any traceback was logged by Ryu?
=> Sorry, I didn’t know what I should check.
     When ryu picks up segment packet and hung up, no log message is
displayed
on the terminal.
     Could you tell me if there are checkpoints concerning ryu behavior?

Thank you,
hirasawa

----------------------------------------------
Takayoshi Hirasawa
NTT NS Lab.
Tel: 0422-59-7294 / Fax: 0422-59-4656
Email: hirasawa.takayo...@lab.ntt.co.jp
       : takayoshi.hirasawa...@hco.ntt.co.jp
-----------------------------------------^-^--


-----Original Message-----
From: Fujimoto Satoshi [mailto:satoshi.fujimo...@gmail.com]
Sent: Monday, December 04, 2017 4:19 PM
To: cmdcr...@gmail.com; ryu-devel@lists.sourceforge.net
Subject: Re: [Ryu-devel] ryu freeze when ryu picks up segment packet

Hi, Hirasawa-san

I've found that it's hard to reproduce your situation.
In my environment, Packet-in including segmented packets did not cause
any problem.

I send the script which we use to debug Ryu packet library.
Could you try this script? If this causes errors, there is something
wrong with Ryu in your environment.
      $ python display_pcap.py ryu-ovs-loopback.pcap

And...
* Could you tell me which version of Ryu you are using?
* Could you confirm that any traceback was logged by Ryu?


Thanks,
Fujimoto


On 2017年11月30日 13:49, Takayoshi Hirasawa wrote:


        Hi, Fujimoto-san

        Thank you for your reply.

        I attached three capture data, interface of VM which onos is running
on, loopback interface of  VM which ryu & ryu-ovs is runnning on and
interface of VM which onos-ovs is running on.

        we could confirm onos's request "OFPT_MULTIPART_REQUEST" to
onos-ovs
(onos-vm-interface:No.50, ryu-ovs-loopback:No.137,
onosovs-vm-interface:No.61,) but we could not confirm onos-ovs's reply
"OFPT_MULTIPART_REPLY" at onos VM
interface(onosovs-vm-interface:No.62-64,
ryu-ovs-loopback:No.142,143,145,146,148.)  Reply-packet seems to be
picked up to ryu as packet-in operation, but ryu seems not to release
it.
        this behavior is always observed when ryu pick up the segmented
packet. when i changed mtu of ryu&ryu-ovs VM's interface, this
behavior was observed too by the other smaller packet than the above
big packet  which onos-ovs output.

        (i'm sorry if an environment figure was broken which i wrote in
the
previous message. ryu controller is connected to ryu-ovs.)

        Thanks
        hirasawa


        2017-11-30 8:54 GMT+09:00 Fujimoto Satoshi
<satoshi.fujimo...@gmail.com <mailto:satoshi.fujimo...@gmail.com> >:


                Hi, Hirasawa-san

                Thanks for your reporting!

                I want to confirm and inspect the problem in my environment,
                so could you send me the packets that causes the problem?

                Thanks
                Fujimoto


                On 2017年11月29日 18:20, Takayoshi Hirasawa wrote:


                        Hello

                        We are worried about ryu hanging up when certain
packets are
packet-in to ryu.

                        I am considering an architecture that controls
openflow channel
with ryu and OVS.
                        ryu-ovs picks up all packets to ryu by packet-in
operation, and
re-releases it from ryu-ovs after looking up the destination at ryu.

                        Specifically, it has the following structure.
                        (this time, we control openflow channel between
ovs
and ONOS
controller by ryu&ryu-ovs.)


|ryu|

||

|| ryu-OFchannel

||
                        |ONOS|
<===============|ryu-ovs|================> |ONOS-OVS|
                                        ONOS-OFchannel
ONOS-OFchannel


                        When connecting ONOS-OVS, we confirmed the
connection of
ONOS-OFchannel at first.
                        However, when packets exceeding the MTU of ryu-ovs
came from
ONOS-OVS, they segmented in the TCP layer and packeted in to ryu, the
ryu freezed.
                        In addition, the CPU & memory usage rate of
ryu-manager is close to
100%.
                        ONOS-OFchannel, ryu-OFchannel and subsequent
connection became
disconnected.

                        As a result of checking with packet capture, the
segmented packet
correctly packet-in from ryu-ovs to ryu, but it seems that ryu does
not respond from the moment when the segmented packet packet-in.

                        How can we solve this?

                        I will attach a python script (rebuilt version of
simple_switch_13) that I am running on ryu.
                        Thank you.






        --------------------------------------------------------------
----------------
                        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
<mailto:Ryu-devel@lists.sourceforge.net>

        https://lists.sourceforge.net/lists/listinfo/ryu-devel
<https://lists.sourceforge.net/lists/listinfo/ryu-devel>






        --------------------------------------------------------------
----------------
        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
<mailto:Ryu-devel@lists.sourceforge.net>
        https://lists.sourceforge.net/lists/listinfo/ryu-devel






----------------------------------------------------------------------
--------
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
https://lists.sourceforge.net/lists/listinfo/ryu-devel

----------------------------------------------------------------------
--------
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
https://lists.sourceforge.net/lists/listinfo/ryu-devel


------------------------------------------------------------------------------
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
https://lists.sourceforge.net/lists/listinfo/ryu-devel

------------------------------------------------------------------------------
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
https://lists.sourceforge.net/lists/listinfo/ryu-devel

Reply via email to