Hi,
I tried the patch. I checked that the exception was not raised.
P.S. There is a method which reformed it now because DPSet is regacy?
Thanks!
Satoshi
2013/8/2 FUJITA Tomonori <[email protected]>
> On Fri, 2 Aug 2013 14:41:51 +0900
> Satoshi Kobayashi <[email protected]> wrote:
>
> > Hi,
> >
> > I tried OpenFlow 1.3 on my application, I have noticed that it becomes an
> > error.
> > "OFP_VERSIONS = [ofproto_v1_3.OFP_VERSION]"
> >
> > The trace is following:
> > hub: uncaught exception: Traceback (most recent call last):
> > File
> >
> "/home/satoshi/.virtualenvs/ryu-2.2/lib/python2.6/site-packages/ryu/lib/hub.py",
> > line 48, in _launch
> > func(*args, **kwargs)
> > File
> >
> "/home/satoshi/.virtualenvs/ryu-2.2/lib/python2.6/site-packages/ryu/base/app_manager.py",
> > line 110, in _event_loop
> > handler(ev)
> > File
> >
> "/home/satoshi/.virtualenvs/ryu-2.2/lib/python2.6/site-packages/ryu/controller/dpset.py",
> > line 166, in switch_features_handler
> > datapath.ports = msg.ports
> > AttributeError: 'OFPSwitchFeatures' object has no attribute 'ports'
> >
> > When DPSet acquires a port information from EventOFPSwitchFeatures
> > instance, this happens. I checked the code and OpenFlow protocol spec,
> > "struct ofp_port" is not contained in "struct ofp_switch_features" in
> > version 1.3. Maybe how to acquire a port information changed to another
> > method. (Although I am not detailed about OpenFlow protocol in binary
> > level, I may misunderstand some)
>
> Yeah, With 1.3, you neee to use port desc stats.
>
> The above is a known issue and dpset.py is kinda legacy code, however,
> I guess that there are developers who use it with OF1.3.
>
> Can you try the following?
>
> diff --git a/ryu/controller/dpset.py b/ryu/controller/dpset.py
> index c172aec..0bb3b98 100644
> --- a/ryu/controller/dpset.py
> +++ b/ryu/controller/dpset.py
> @@ -163,7 +163,9 @@ class DPSet(app_manager.RyuApp):
> def switch_features_handler(self, ev):
> msg = ev.msg
> datapath = msg.datapath
> - datapath.ports = msg.ports
> + # ofp_handler.py does the following so we could remove...
> + if datapath.ofproto.OFP_VERSION < 0x04:
> + datapath.ports = msg.ports
>
> @set_ev_cls(ofp_event.EventOFPPortStatus, handler.MAIN_DISPATCHER)
> def port_status_handler(self, ev):
> diff --git a/ryu/controller/ofp_handler.py b/ryu/controller/ofp_handler.py
> index 84e4d74..642cec8 100644
> --- a/ryu/controller/ofp_handler.py
> +++ b/ryu/controller/ofp_handler.py
> @@ -191,6 +191,8 @@ class OFPHandler(ryu.base.app_manager.RyuApp):
> # while.
> if datapath.ofproto.OFP_VERSION < 0x04:
> datapath.ports = msg.ports
> + else:
> + datapath.ports = {}
>
> ofproto = datapath.ofproto
> ofproto_parser = datapath.ofproto_parser
> @@ -200,6 +202,23 @@ class OFPHandler(ryu.base.app_manager.RyuApp):
> )
> datapath.send_msg(set_config)
>
> + if datapath.ofproto.OFP_VERSION < 0x04:
> + self.logger.debug('move onto main mode')
> + ev.msg.datapath.set_state(MAIN_DISPATCHER)
> + else:
> + port_desc = datapath.ofproto_parser.OFPPortDescStatsRequest(
> + datapath, 0)
> + datapath.send_msg(port_desc)
> +
> + @set_ev_handler(ofp_event.EventOFPPortDescStatsReply,
> CONFIG_DISPATCHER)
> + def multipart_reply_handler(self, ev):
> + msg = ev.msg
> + datapath = msg.datapath
> + for port in msg.body:
> + datapath.ports[port.port_no] = port
> +
> + if msg.flags & datapath.ofproto.OFPMPF_REPLY_MORE:
> + return
> self.logger.debug('move onto main mode')
> ev.msg.datapath.set_state(MAIN_DISPATCHER)
>
>
--
Satoshi Kobayashi <[email protected]>
------------------------------------------------------------------------------
Get your SQL database under version control now!
Version control is standard for application code, but databases havent
caught up. So what steps can you take to put your SQL databases under
version control? Why should you start doing it? Read more to find out.
http://pubads.g.doubleclick.net/gampad/clk?id=49501711&iu=/4140/ostg.clktrk
_______________________________________________
Ryu-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/ryu-devel
