Hi again, Fujimoto No, I did not run Ryu with sudo. It was a clean virtualenv python installation, where I installed Ryu and its dependencies.
I don't know what to do anymore :/ I will try to see if I missed anything. Once again, thank you for the assistance. On 19 October 2017 at 02:01, Fujimoto Satoshi <[email protected]> wrote: > Hi, Carlos > > Thanks for your information! > I tried running your application, however it worked well in my environment. > I didn't get any "unknown barrier xid" message. > > By any chance, do you run your application with "sudo"? > You patched and reinstalled Ryu in virtualenv (I confirmed from your log > file), > however if you run the application with "sudo", > the Ryu in system global environment will be used, it is not patched. > > Please confirm that you don't run your application with "sudo". > If you ran with "sudo", > * Please try to run without "sudo", or > * Please reinstall Ryu in system global environment after patching > > Thanks, > Fujimoto > > > On 2017年10月18日 18:28, Carlos Ferreira wrote: > > It did not work. > I have attached two files. The reinstallation log so that you can > check if I executed the commands correctly, and a reproducible example > (ArchSDN_test.py). > Beware, my application is two complex for me to put it in an e-mail > (several modules and files). Because of that, the ArchSDN_test.py only > contains the code which is executed when a Switch connects. From my > side, I'm able to see the issue at the console. > > Once again, thank you for your support. > Carlos Ferreira > > On 18 October 2017 at 01:47, Fujimoto Satoshi > <[email protected]> wrote: > > Hi, Carlos > > Please confirm that you've reinstalled Ryu after applying the patch. > $ pip uninstall Ryu > $ pip install -r tools/pip-requires > $ python setup.py install > > After reinstallation, it should work fine. > If this does not work, could you send me your application? > > > Thanks, > Fujimoto > > > On 2017年10月18日 09:22, Carlos Ferreira wrote: > > Hello again, Fujimoto, > > I have tried your patch in a clean Python3 virtualenv, and the issue > still remains. Although my code properly setups the OF Switch, the log > still shows the "unknown barrier xid" message. > > Is it supposed to be like this? > > Thank you for your support! > Carlos Ferreira > > > > On 17 October 2017 at 02:36, Fujimoto Satoshi > <[email protected]> wrote: > > Hi, Carlos > > I've submitted a patch which enables to send a single OFPBarrierRequest: > [PATCH] app/ofctl: Enable to send single BarrierRequest > https://sourceforge.net/p/ryu/mailman/message/36079164/ > > With this, you can make a waiting point as follows: > > for ofp_port in ports: > if 0 <= ofp_port.port_no < ofp.OFPP_MAX: > datapath.send_msg( > ofp_parser.OFPPortMod( > datapath=datapath, > port_no=ofp_port.port_no, > hw_addr=ofp_port.hw_addr, > config=ofp.OFPPC_PORT_DOWN, > mask=ofp.OFPPC_PORT_DOWN, > advertise=0 > ) > ) > api.send_msg(myRyuApp, ofp_parser.OFPBarrierRequest(datapath), > reply_cls=ofp_parser.OFPBarrierReply) > > Could you try with this patch? > > Thanks, > Fujimoto > > > > On 2017年10月16日 19:10, Carlos Ferreira wrote: > > Thank you for your support Fujimoto > > I wanted to send an OFPBarrierRequest because my intention was to have > a point where my Python code waits. > > For example, I wanted to send messages to the switch to disable all > ports, and in the end, I send the BarrierRequest to ensure that all > ports are down before continuing. > > This is my current code: > > # Stage 1 -> Disable all switching ports > for ofp_port in ports: > if 0 <= ofp_port.port_no < ofp.OFPP_MAX: > datapath.send_msg( > ofp_parser.OFPPortMod( > datapath=datapath, > port_no=ofp_port.port_no, > hw_addr=ofp_port.hw_addr, > config=ofp.OFPPC_PORT_DOWN, > mask=ofp.OFPPC_PORT_DOWN, > advertise=0 > ) > ) > ctrl_send_msg(ofp_parser.OFPBarrierRequest(datapath), > reply_cls=ofp_parser.OFPBarrierReply) > > > Am I doing this right? > > Carlos Ferreira > > > On 16 October 2017 at 03:19, Fujimoto Satoshi > <[email protected]> wrote: > > Hi, Carlos > > I think you've called api.send_msg() correctly, > however, when you call api.send_msg(), the controller sends an > OFPBarrierRequest in this function: > > https://github.com/osrg/ryu/blob/master/ryu/app/ofctl/service.py#L141-L142 > > After this, the controller will receive an OFPBarrierReply and inspect it > in > this function: > https://github.com/osrg/ryu/blob/master/ryu/app/ofctl/service.py#L145 > > This function will be called when it received OFPBarrierReplies. > > So, > > api.send_msg(myRyuApp, > > ofp_parser.OFPBarrierRequest(datapath),reply_cls=ofp_parser.OFPBarrierReply) > > this will sends two OFPBarrierRequests, and the controller will receive > two > replies. > Then, the controller will mistake which packet should be inspected, and > error occurs. > > In the other words, I think you don't need to make and send an > OFPBarrierRequest by yourself, > because api.send_msg() will take care of the consistency of message order > by > using OFPBarrierRequests. > Or, is there a reason why you have to manage it? > > Thanks, > Fujimoto > > > On 2017年10月14日 02:15, Carlos Ferreira wrote: > > Update: > > I noticed that the call to api.send_msg with a Barrier Message wasn't > blocking at all. > It was blocking in the next call for an OFPFlowMod. > > But I still receive the "unknown barrier xid 103043043" at the logs. > What is going on? Is my application really waiting for the Barrier > Message Reply before advancing? > > Carlos > > On 13 October 2017 at 17:12, Carlos Ferreira <[email protected]> > wrote: > > Hello > > I'm trying to use the Ryu synchrounous API to send and wait for the > execution of a Barrier message. > > I'm using the same implementation presented in: > > > http://ryu.readthedocs.io/en/latest/app/ofctl.html#ryu.app.ofctl.api.send_msg > > For some reason unknown to me, calling > > "api.send_msg(myRyuApp, ofp_parser.OFPBarrierRequest(datapath), > reply_cls=ofp_parser.OFPBarrierReply)" > > will lock and not return, while at the console, a "unknown barrier xid > 103043043" will be printed. > > Am I calling api.send_msg correctly? > > Thank you for the assistance > Carlos Ferreira > > > ------------------------------------------------------------------------------ > 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 > [email protected] > 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 > [email protected] > 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 > [email protected] > https://lists.sourceforge.net/lists/listinfo/ryu-devel > > -- Carlos Miguel Ferreira Researcher at Telecommunications Institute Aveiro - Portugal Work E-mail - [email protected] Skype & GTalk -> [email protected] LinkedIn -> http://www.linkedin.com/in/carlosmferreira ------------------------------------------------------------------------------ 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 [email protected] https://lists.sourceforge.net/lists/listinfo/ryu-devel
