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
