Re: [Ryu-devel] Trouble parsing DHCP packets

[Jeff R. <je...@cs...>]

Thanks Benny for checking back with me! I haven't actually been able to
test it yet, I've been out of town and now dealing with other higher
priority issues. I'll definitely let you know once I get back to it though.

Thanks,
Jeff


On Tue Oct 28 2014 at 8:10:13 PM Benjamin Eggerstedt <
ben...@gm...> wrote:

> 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 <je...@cs...> 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 <
>> ben...@gm...> 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 <je...@cs...>
>>> 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 <je...@cs...>
>>>> 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 <
>>>>> ben...@gm...> 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 <je...@cs...>
>>>>>> 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
>>>>>>> Ryu...@li...
>>>>>>> https://lists.sourceforge.net/lists/listinfo/ryu-devel
>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>