CODEWITHSUNDEEP
pythonluawiresharkmininetopenflow
Q.H.
Q.H.

Reputation: 1466

Openflow Multipart Request Error Message: OFPBRC_BAD_LEN (6)

Long story short, I have a project that requires me to create a controller from scratch in python and handle requests from switches created through a mininet topology following the Open Flow Protocol.

Helpful Open Flow Protocol resources:

My code is available here on github for cloning and full transparency:

The issue I am running into is that I am unable to send a multipart-request message for the port stats description (search PortDesc on this link). I do not know why this is the case, but when I view the packet data in wireshark I get a "Range is out of bounds" error. I haven't been able to figure out why this is the case. Here are a few screenshots of the packet data:

Wireshark captures: Bytes where I created the multipart request Openflow multipart request mess Full screenshot of the openflow protocol

Lua error messages: Lua error message part 1 Lua error message part 2

Bad Request Error Message Response: Bad request error message response enter image description here Something to note here is that the code says OFPBRC_BAD_LEN (6), but the length of bytes sent in the multi-part request are of size 16.

A classmate that sent their packet data correctly has said that they were using the same packing structure that I am, except theirs is successful (see the python struct documentation). I don't know what the issue could be with mine and I am running out of ideas to check. Any pointers would be greatly appreciated.

TL;DR: I am unable to send a multipart request and even though I am adhering to the request specifications, results keep returning with an error code. Error in wireshark says "Range out of bounds" and I do not know how else to structure my request to correct this error message.

Upvotes: 1

Views: 464

Answers (1)

Q.H.
Q.H.

Reputation: 1466

I solved my problem, but I don't think I have an answer as to what the problem was. First I'll start with my solution, and then talk about what I believe the problem is.

Solution:

As you can see in the screenshots above, I was sending OpenFlow packets in the version 1.5 protocol, which is the newest version, but visiting openflow message layer documentation only shows documentation up to 1.4.

Ontop of that, the latest version of multipart request that the documentation shows is 1.3.1. Even when I send a multipart request for Open Flow Protocol version 1.5 it wasn't showing up as the OpenFlowProtocol, instead as a regular TCP packet. I did the following 3 things:

  1. In my topology file, where I create the switch, I was initializing the switches as s1 = self.addSwitch( 's1'). What I added to this statement was the protocol parameter: s1 = self.addSwitch( 's1', protocols='OpenFlow14').

  2. For good measure I also added protocols specification to the mininet command in the console: sudo mn --custom mytopo.py --topo mytopo --controller=remote,ipaddr=127.0.0.1,port=6653,protocols=OpenFlow14

  3. I also changed how I was packing the requests, so instead of specifying version 1.5 (which is a '06' in the packet header), I packed it as 1.4 (which is a '05' in the packet header). req = struct.pack('!BBHI',5,5,8,0) (ex. for the feature_request message sent to the switch).

These steps solved the issue I was running into and I was able to get a stats_reply from the switch.

Problem (or what I think the problem is):

I believe the problem was that AS OF RIGHT NOW, Open Flow Version 1.5 doesn't have support yet for the multipart request, as evidenced by when sending a multipart request for the port description, it shows a regular TCP protocol instead of the OpenFlow protocol.

Upvotes: 1

Related Questions