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 < [email protected]> 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 <[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
