Hi Jeff,
I hope you're doing fine and the issue is already resolved.
I'd really like to know if it was what we expected, or something else ...
Meanwhile I used the time to dig into the Ryu Framework a little more ...
In my "virtual lab" (Mininet VM (vBox) + Ryu-GitHub) I found that there is
an initial "OFPSetConfig" by the Ryu Framework (not triggered by user
application) that sets the "miss send length" to 128 while the "Controller
Rule" (last resort send to controller) specifies "no buffer" that, what I
thought, would be equal to "send the full packet" (it is not, or all the
switch implementations fail).
Here is a potential solution for your issue, in case you didn't manage to
instruct your switch to send more data as part of the PacketIn-Event in the
meantime.
from ryu.controller import ofp_event
from ryu.controller.handler import MAIN_DISPATCHER, DEAD_DISPATCHER
from ryu.controller.handler import CONFIG_DISPATCHER
from ryu.controller.handler import set_ev_cls
from ryu.ofproto import ofproto_v1_3
# You'll obviously have more imports, just to give my context
@set_ev_cls(ofp_event.EventOFPSwitchFeatures, CONFIG_DISPATCHER)
def switch_features_handler(self, ev):
datapath = ev.msg.datapath
ofproto = datapath.ofproto
parser = datapath.ofproto_parser
# Send all non-matching traffic to controller
match = parser.OFPMatch()
actions = [parser.OFPActionOutput(ofproto.OFPP_CONTROLLER,
ofproto.OFPCML_NO_BUFFER)]
self.add_flow(datapath, 0, match, actions)
# Set a higher value for miss_send_length
req = parser.OFPSetConfig(datapath, ofproto_v1_3.OFPC_FRAG_NORMAL, 256)
datapath.send_msg(req)
This works fine with the Mininet v2.1.0+ / OVS I have, verified with "h1
ping -s 2000 h2" and I get the requested data in Wireshark.
Tomorrow night I'll try the same with my OmniSwitch 6900, to verify the
LLDP scenario I had ...
Thanks for your feedback,
Regards,
Benny
On Thu, Oct 23, 2014 at 9:40 PM, Jeff Rasley <[email protected]> wrote:
> Wonderful, thanks Benny. I'll have to look into this further but this
> definitely sounds similar to the issues I am dealing with.
>
> Jeff
>
> On Thu, Oct 23, 2014 at 3:28 PM, Benjamin Eggerstedt <
> [email protected]> wrote:
>
>> Hi Jeff,
>>
>> When I read your first mail I immediately felt reminded on the issue I'm
>> currently working on. If you create a tcpdump -s 0 -lnni ethX capture on
>> the device running Ryu, I'm almost certain that the DHCP DISCOVER in
>> question will show up as "Truncated" with regards to the "DATA" portion
>> (copy of your DHCP DISCOVER packet) of the OF PACKET IN.
>>
>> The issue, at least for the device I'm working on, is that it buffers the
>> packet properly and hence only transfers a fragment of the original packet
>> to Ryu. Ryu however starts happily to read the packet as if it is a
>> complete one thus running into a field that "should be X long, but is only
>> Y".
>>
>> However, I might be wrong on your issue - but before you spent hours on
>> analysing your code please verify that you actually get the full and intact
>> packet in the <DATA> portion of the PACKET_IN from your OF switch.
>>
>> Benny
>>
>>
>>
>>
>> On Thu, Oct 23, 2014 at 8:23 PM, Jeff Rasley <[email protected]> wrote:
>>
>>> More specifically I am getting an "error: 'unpack_from requires a buffer
>>> of at least 233 bytes'" error from the unpack call on 185 (my buffer
>>> appears to be 91 bytes long). Which makes me think that the unpack string
>>> is not representative of my DHCP Discover packet.
>>>
>>> On Thu, Oct 23, 2014 at 2:19 PM, Jeff Rasley <[email protected]>
>>> wrote:
>>>
>>>> Sorry Benny, I should have went into more detail in my previous email.
>>>> I have definitely been using the library you pointed to however it is not
>>>> actually parsing my DHCP Discover packets correctly.
>>>>
>>>> Here's a sample of some code I have reduced my problem down to:
>>>> https://gist.github.com/jeffra/aa6cf159db53f27922a2 The 4th protocol
>>>> in the list of protocols is a DHCP Discover packet. After stepping through
>>>> the parsing code in ryu.lib.packet.dhcp.parser and checking it against my
>>>> pcap of the packet I know it partially decodes the packet but is not able
>>>> to fully decode it. More specifically I am getting errors regarding the
>>>> unpack_from call on 185 but the previous unpack call on 178 works fine (and
>>>> returns the correct values).
>>>>
>>>> Any thoughts?
>>>>
>>>> On Thu, Oct 23, 2014 at 2:05 PM, Benjamin Eggerstedt <
>>>> [email protected]> wrote:
>>>>
>>>>> Hi Jeff,
>>>>>
>>>>> Looking at
>>>>> https://github.com/osrg/ryu/blob/master/ryu/lib/packet/dhcp.py I'd
>>>>> say "yes" :)
>>>>>
>>>>> Benny
>>>>>
>>>>> On Thu, Oct 23, 2014 at 7:22 PM, Jeff Rasley <[email protected]>
>>>>> wrote:
>>>>>
>>>>>> I seem to be having trouble parsing DHCP Discover packets in Ryu. I
>>>>>> see there is a test for DHCP Offer messages
>>>>>> in ryu/tests/unit/packet/test_dhcp.py. Has DHCP Discover parsing been
>>>>>> implemented?
>>>>>>
>>>>>> Thanks,
>>>>>> Jeff Rasley
>>>>>> http://cs.brown.edu/~jeffra
>>>>>>
>>>>>>
>>>>>> ------------------------------------------------------------------------------
>>>>>>
>>>>>> _______________________________________________
>>>>>> Ryu-devel mailing list
>>>>>> [email protected]
>>>>>> https://lists.sourceforge.net/lists/listinfo/ryu-devel
>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>
------------------------------------------------------------------------------
_______________________________________________
Ryu-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/ryu-devel
