I have news.
It seems that the error that was logged, was related to an error
message being received by ryu, as a result of an OFPGroupMod message
previously sent by the controller.
I have logged this in debug mode:
EventOFPErrorMsg received.
version=0x4, msg_type=0x1, msg_len=0x1c, xid=0xb6ba2dd6
`-- msg_type: OFPT_ERROR(1)
OFPErrorMsg(type=0x1, code=0x1,
data=b'\x04\x0f\x00\x10\xb6\xba\x2d\xd6\x00\x02\x00\x00\xff\xff\xff\xfc')
|-- type: OFPET_BAD_REQUEST(1)
|-- code: OFPBRC_BAD_TYPE(1)
`-- data: version=0x4, msg_type=0xf, msg_len=0x10, xid=0xb6ba2dd6
`-- msg_type: OFPT_GROUP_MOD(15)
EVENT ofp_event->ofctl_service EventOFPBarrierReply
unknown error xid 3065654742
The ErrorMsg xid (in hex) is equal to the unknown error logged right after.
I have confirmed this by dissecting the OpenFlow packet using Wireshark.
This error msg came from a Zodiac FX OF Switch.
My application sent this OFPGroupMod message:
datapath.send_msg( # Removes all groups registered in this switch.
ofp_parser.OFPGroupMod(
datapath=datapath,
command=ofp.OFPGC_DELETE,
group_id=ofp.OFPG_ALL,
)
)
I honestly do not understand why the switch is answering with an error...
Carlos Ferreira
On 19 October 2017 at 10:29, Carlos Ferreira <carlosmf...@gmail.com> wrote:
> 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
> <satoshi.fujimo...@gmail.com> 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
>> <satoshi.fujimo...@gmail.com> 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
>> <satoshi.fujimo...@gmail.com> 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
>> <satoshi.fujimo...@gmail.com> 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 <carlosmf...@gmail.com>
>> 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
>> 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
