Hi Aravind,
Please note that OF v1.3.4 introduced the "new IANA TCP port of 6653" and
most switch vendors implemented OF v1.3.1.
I wouldn't be surprised if your application would work right away if you'd
stick to the "old standard".
Benny
On Sat, Dec 27, 2014 at 7:04 PM, Aravindhan Dhanasekaran <adha...@ncsu.edu>
wrote:
> On 12/27/2014 10:48 AM, Benjamin Eggerstedt wrote:
> > Hi Aravind,
> >
> > I see that the TCP ports differ from the "working" and "non-working"
> example
> > (6633 vs 6653). Did you try to take a packet capture with Wireshark?
> > If the communication stops so suddenly, it feels like coming from such a
> topic.
> >
> > -Benny
>
> Hi Benny,
>
> Yes. The non-working mode uses port 6653.
>
> I just a captured the control packets between the switch and the
> controller.
> Looks like, the controller is sending "features request" message after
> receiving
> a 'hello' packet from the switch. The switch isn't responding with a
> "features
> reply" though.
>
> The switch logs shows the receipt of the "features request" message, but
> nothing
> about the reply. I'll follow up with the switch folks.
>
> Thanks,
> /Aravind
>
> 47 Dec 27 12:53:58|00047|vconn|DBG|tcp:20.0.0.2:6653: sent (Success):
> hello
> 48 Dec 27 12:53:58|00048|poll_loop|DBG|[POLLIN] on fd 6: 0x4213b9 0x44dcfa
> 0x429b1a 0x422dbf 0x411c 10 0x4112ee
> 49 Dec 27 12:53:58|00049|ofl_msg_u|WARN|Received message has wrong
> version.
> 50 Dec 27 12:53:58|00050|vconn|DBG|tcp:20.0.0.2:6653: received:
> 51 00000000 05 00 00 08 d4 d2 48 6b-
> 52
> 53 Dec 27 12:53:58|00051|vconn|DBG|tcp:20.0.0.2:6653: negotiated OpenFlow
> version 0x04 (we support versions 0x04 to 0x04 inclusive, peer no
> later than
> version 0x05)
> 54 Dec 27 12:53:58|00052|rconn|INFO|tcp:20.0.0.2:6653: connected
> 55 Dec 27 12:53:58|00053|rconn|DBG|tcp:20.0.0.2:6653: entering ACTIVE
> 56 Dec 27 12:53:58|00054|vconn|DBG|tcp:20.0.0.2:6653: received: feat_req
>
> >
> > On Fri, Dec 26, 2014 at 11:20 PM, Aravindhan Dhanasekaran <
> adha...@ncsu.edu
> > <mailto:adha...@ncsu.edu>> wrote:
> >
> > Hello,
> > I'm using OpenFlow reference implementation v1.3 switch
> (CPqD/Ericsson) and
> > Ryu controller.
> >
> > My Ryu controller app is based on the L2 forwarding switch example.
> Whenever
> > I start my controller, it receives the 'hello' message from the
> switch and
> > goes to config mode. It just freezes in the config mode; it's not
> sending
> > the switch features request message.
> >
> > But, it works perfectly when used in Mininet environment. I'm seeing
> this
> > issue in a physical setup.
> >
> > See below for Ryu logs (physical/mininet environment) and commands
> used to
> > execute the switch and controller.
> >
> > Any help would be appreciated.
> >
> > Thanks,
> > /Aravind
> >
> >
> > Topology
> > ========
> >
> > controller (20.0.0.2/eth1 <http://20.0.0.2/eth1>) <---------->
> switch
> > (20.0.0.1/eth1 <http://20.0.0.1/eth1>)
> > ^
> > |
> > |
> > |
> > v
> > datapath (2 ports - eth3,
> eth6)
> >
> > Commands Used
> > =============
> > sudo udatapath/ofdatapath -i eth3,eth6 ptcp:6653 -d abcdefabcdef
> > sudo secchan/ofprotocol ptcp:6653 tcp:20.0.0.2:6653 <
> http://20.0.0.2:6653>
> > --fail closed --log-file=/tmp/ofp.log
> > ryu-manager --ofp-listen-host 20.0.0.2 --ofp-tcp-listen-port 6653
> --verbose
> > fpm_firewall.py
> >
> > Controller Logs (physical setup)
> > ================================
> > $ ryu-manager --ofp-listen-host 20.0.0.2 --ofp-tcp-listen-port 6653
> > --verbose fpm_firewall.py
> > loading app fpm_firewall.py
> > loading app ryu.controller.ofp_handler
> > instantiating app ryu.controller.ofp_handler of OFPHandler
> > instantiating app fpm_firewall.py of fpm_firewall
> > BRICK ofp_event
> > PROVIDES EventOFPPacketIn TO {'fpm_firewall': set(['main'])}
> > PROVIDES EventOFPSwitchFeatures TO {'fpm_firewall':
> set(['config'])}
> > CONSUMES EventOFPEchoRequest
> > CONSUMES EventOFPHello
> > CONSUMES EventOFPErrorMsg
> > CONSUMES EventOFPSwitchFeatures
> > CONSUMES EventOFPPortDescStatsReply
> > BRICK fpm_firewall
> > CONSUMES EventOFPPacketIn
> > CONSUMES EventOFPSwitchFeatures
> > connected socket:<eventlet.greenio.GreenSocket object at 0x305bdd0>
> > address:('20.0.0.1', 38321)
> > hello ev <ryu.controller.ofp_event.EventOFPHello object at 0x3064390>
> > move onto config mode
> >
> > Controller Logs (mininet setup)
> > ===============================
> > $ ryu-manager fpm_firewall.py --verbose
> > loading app fpm_firewall.py
> > loading app ryu.controller.ofp_handler
> > instantiating app ryu.controller.ofp_handler of OFPHandler
> > instantiating app fpm_firewall.py of fpm_firewall
> > BRICK ofp_event
> > PROVIDES EventOFPPacketIn TO {'fpm_firewall': set(['main'])}
> > PROVIDES EventOFPSwitchFeatures TO {'fpm_firewall':
> set(['config'])}
> > CONSUMES EventOFPPortDescStatsReply
> > CONSUMES EventOFPEchoRequest
> > CONSUMES EventOFPSwitchFeatures
> > CONSUMES EventOFPHello
> > CONSUMES EventOFPErrorMsg
> > BRICK fpm_firewall
> > CONSUMES EventOFPPacketIn
> > CONSUMES EventOFPSwitchFeatures
> > connected socket:<eventlet.greenio.GreenSocket object at 0x2c07590>
> > address:('127.0.0.1', 43124)
> > hello ev <ryu.controller.ofp_event.EventOFPHello object at 0x2c07ad0>
> > move onto config mode
> > EVENT ofp_event->fpm_firewall EventOFPSwitchFeatures
> > switch features ev version: 0x4 msg_type 0x6 xid 0x1735277a
> >
>
> OFPSwitchFeatures(auxiliary_id=0,capabilities=79,datapath_id=1,n_buffers=256,n_tables=64)
> > <my app specific log messages>
> > ...
> > move onto main mode
>
>
------------------------------------------------------------------------------
Dive into the World of Parallel Programming! The Go Parallel Website,
sponsored by Intel and developed in partnership with Slashdot Media, is your
hub for all things parallel software development, from weekly thought
leadership blogs to news, videos, case studies, tutorials and more. Take a
look and join the conversation now. http://goparallel.sourceforge.net
_______________________________________________
Ryu-devel mailing list
Ryu-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ryu-devel
