Hi, Thank you for sending captured packets and your snip.
I exported a single Packet-In message with the packet you pointed. The sent packet was truncated. Also, I found that the max packet size sent to controller is set to 256 bytes at the following: --- req = parser.OFPSetConfig(datapath, ofproto_v1_3.OFPC_FRAG_REASM, 256) --- http://ryu.readthedocs.io/en/latest/ofproto_v1_3_ref.html#ryu.ofproto.ofproto_v1_3_parser.OFPSetConfig Could you try with "miss_send_len=ofproto.OFPCML_NO_BUFFER"? --- req = parser.OFPSetConfig(datapath, ofproto_v1_3.OFPC_FRAG_REASM, ofproto.OFPCML_NO_BUFFER) --- This means that the switch should send all packet data to controller without truncating when no flow matched. Thanks, Iwase On 2016年12月22日 14:28, Munther Numan wrote: > Dear Mr. Iwase, > I hope you're fine and well , > > Thank you very much for your replay . > > 1- I am using Open Vswitch. > 2-Thank you very much for your explain about the flags , Actually I am not > know that before , I am just work with SDN and Ryu from some months ago , I > Just follow the below URL have some my problem : > https://sourceforge.net/p/ryu/mailman/message/32984827/ > 3- I used " OFPC_FRAG_REASM" in OpenFlow set config and not anything happen . > 4- I capture the traffic from controller side and I attached the capture in > the attached file. > 5- from the capture I see the control received whole the packet with > [OFPC_FRAG_NORMAL and OFPC_FRAG_REASM ] > 6- I am also print the packet received in controller. > 7- In attached file you can find the capture packet from controller side , > packet in function , switch feature function . > > > Thank you . > Best Regards. > > Munther Numan > Master Student > Faculty of Engineering > University Putra Malaysia > > -----Original Message----- > From: Iwase Yusuke [mailto:iwase.yusu...@gmail.com] > Sent: Wednesday, December 21, 2016 4:01 PM > To: munpro...@gmail.com > Cc: olivier.des...@gmail.com; ryu-devel@lists.sourceforge.net > Subject: Re: [Ryu-devel] bug in parsing dhcp packet > > Hi, > > > On 2016年12月20日 19:56, Munther Numan wrote: >> Dear Mr. Iwase >> I hope you're fine and well , >> >> Thank you very much for your replay . >> >> 1- I capture these DHCP packet from switch , Actually I run Wireshark in a >> switch and I select switch-eth1 the source of my captures. >> 2- I am not sure if the data send by output function or not , I am using the >> below codes for Event OFP Switch Features : >> >> @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 >> match = parser.OFPMatch() >> actions = [parser.OFPActionOutput(ofproto.OFPP_CONTROLLER, >> ofproto.OFPCML_NO_BUFFER)] >> self.add_flow(datapath, 0, match, actions) >> req = parser.OFPSetConfig(datapath, ofproto_v1_3.OFPC_FRAG_NORMAL, 256) >> datapath.send_msg(req) >> >> and when I search in Google I see same issue happened with someone and >> others people told to him to add below line in the end of E Event OFP Switch >> Features : >> req = parser.OFPSetConfig(datapath, ofproto_v1_3.OFPC_FRAG_NORMAL, 256( >> datapath.send_msg(req) >> >> and these two lines not allow to truncated the request . > > Hummm... > Fist, which switch are you using? Open vSwitch? Or else? > IIRC, OVS will handle fragmented frames automatically and you don't need to > send OFPSetConfig message explicitly, I guess. > > And, OFPC_FRAG_NORMAL does not mean "Not allow to be truncated", but just "Do > not special handling for fragments". > > OpenFlow Spec 1.3.5 "7.3.2 Switch Configuration" says: > --- > enum ofp_config_flags { > /* Handling of IP fragments. */ > OFPC_FRAG_NORMAL = 0, /* No special handling for fragments. */ > OFPC_FRAG_DROP = 1 << 0, /* Drop fragments. */ > OFPC_FRAG_REASM = 1 << 1, /* Reassemble (only if OFPC_IP_REASM set). */ > OFPC_FRAG_MASK = 3, /* Bitmask of flags dealing with frag. */ }; > --- > > If you want your switch to handle fragmented frames, I guess you should send > OFPSetConfig message with "OFPC_FRAG_REASM" flag. > > Another approach: > Could you capture packets on your controller side? > Wireshark can analyze the packet data contained in Packet-In messages, and > you can check whether the sent packet date is truncated or not. > > Thanks, > Iwase > > >> >> >> Best Regards >> Munther Numan >> Master Student >> Faculty of Engineering >> University Putra Malaysia >> >> -----Original Message----- >> From: Iwase Yusuke [mailto:iwase.yusu...@gmail.com] >> Sent: Tuesday, December 20, 2016 10:38 AM >> To: munpro...@gmail.com >> Cc: ryu-devel@lists.sourceforge.net; olivier.des...@gmail.com >> Subject: Re: [Ryu-devel] bug in parsing dhcp packet >> >> Hi, >> >> First, could you confirm on which point you get captures? >> On your host? Or on your switch? >> >> If you get these DHCP packets were captured on your host or switch, please >> confirm that the sent packet data to the controller is NOT truncated by >> "output" action in your flows. >> If "max_len" is other than "OFPCML_NO_BUFFER", the packet data sent to the >> controller might be truncated by switches. >> >> http://ryu.readthedocs.io/en/latest/ofproto_v1_3_ref.html#ryu.ofproto. >> ofproto_v1_3_parser.OFPActionOutput >> >> FYI, on my environment, DHCP packets in your pcapng file could be decoded. >> >> # Note: I converted pcapng file into pcap file for convenience $ >> python print_pcap_data.py 1-dhcp_discover_packet.pcap >> *** 1, 1481953420.361685 >> ethernet(dst='ff:ff:ff:ff:ff:ff',ethertype=2048,src='00:00:00:00:00:01 >> '), >> ipv4(csum=14742,dst='255.255.255.255',flags=0,header_length=5,identifi >> cation=0,offset=0,option=None,proto=17,src='0.0.0.0',tos=16,total_leng >> th=328,ttl=128,version=4), >> udp(csum=34166,dst_port=67,src_port=68,total_length=308), >> dhcp(boot_file=b'\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\ >> x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x0 >> 0\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\ >> x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x0 >> 0\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\ >> x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x0 >> 0\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\ >> x00\x00\x00\x00\x00\x00\x00\x00\x00\x00',chaddr='00:00:00:00:00:01',ci >> addr='0.0.0.0',flags=0,giaddr='0.0.0.0',hlen=6,hops=0,htype=1,op=1,opt >> ions=options(magic_cookie='99.130.83.99',option_list=[option(length=1, >> tag=53,value=b'\x01'), option(length=8,tag=12,value=b'sdnhubvm'), >> option(length=13,tag=55,value=b'\x01\x1c\x02\x03\x0f\x06w\x0c,/\x1ay*' >> )],options_len=64),secs=0,siaddr='0.0.0.0',sname='\x00\x00\x00\x00\x00 >> \x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x >> 00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00 >> \x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x >> 00\x00\x00\x00\x00\x00\x00',xid=559339326,yiaddr='0.0.0.0') >> >> *** 2, 1481953470.988880 >> ethernet(dst='ff:ff:ff:ff:ff:ff',ethertype=2048,src='00:00:00:00:00:01 >> '), >> ipv4(csum=14742,dst='255.255.255.255',flags=0,header_length=5,identifi >> cation=0,offset=0,option=None,proto=17,src='0.0.0.0',tos=16,total_leng >> th=328,ttl=128,version=4), >> udp(csum=52048,dst_port=67,src_port=68,total_length=308), >> dhcp(boot_file=b'\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\ >> x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x0 >> 0\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\ >> x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x0 >> 0\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\ >> x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x0 >> 0\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\ >> x00\x00\x00\x00\x00\x00\x00\x00\x00\x00',chaddr='00:00:00:00:00:01',ci >> addr='0.0.0.0',flags=0,giaddr='0.0.0.0',hlen=6,hops=0,htype=1,op=1,opt >> ions=options(magic_cookie='99.130.83.99',option_list=[option(length=1, >> tag=53,value=b'\x01'), option(length=8,tag=12,value=b'sdnhubvm'), >> option(length=13,tag=55,value=b'\x01\x1c\x02\x03\x0f\x06w\x0c,/\x1ay*' >> )],options_len=64),secs=0,siaddr='0.0.0.0',sname='\x00\x00\x00\x00\x00 >> \x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x >> 00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00 >> \x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x >> 00\x00\x00\x00\x00\x00\x00',xid=2491751989,yiaddr='0.0.0.0') >> >> *** 3, 1481953473.204261 >> ethernet(dst='ff:ff:ff:ff:ff:ff',ethertype=2048,src='00:00:00:00:00:01 >> '), >> ipv4(csum=14742,dst='255.255.255.255',flags=0,header_length=5,identifi >> cation=0,offset=0,option=None,proto=17,src='0.0.0.0',tos=16,total_leng >> th=328,ttl=128,version=4), >> udp(csum=52045,dst_port=67,src_port=68,total_length=308), >> dhcp(boot_file=b'\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\ >> x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x0 >> 0\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\ >> x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x0 >> 0\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\ >> x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x0 >> 0\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\ >> x00\x00\x00\x00\x00\x00\x00\x00\x00\x00',chaddr='00:00:00:00:00:01',ci >> addr='0.0.0.0',flags=0,giaddr='0.0.0.0',hlen=6,hops=0,htype=1,op=1,opt >> ions=options(magic_cookie='99.130.83.99',option_list=[option(length=1, >> tag=53,value=b'\x01'), option(length=8,tag=12,value=b'sdnhubvm'), >> option(length=13,tag=55,value=b'\x01\x1c\x02\x03\x0f\x06w\x0c,/\x1ay*' >> )],options_len=64),secs=3,siaddr='0.0.0.0',sname='\x00\x00\x00\x00\x00 >> \x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x >> 00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00 >> \x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x >> 00\x00\x00\x00\x00\x00\x00',xid=2491751989,yiaddr='0.0.0.0') >> >> >> So I guess Ryu got the truncated packets and failed to decode them... >> >> >> Thanks, >> Iwase >> >> >> On 2016年12月17日 14:59, Munther Numan wrote: >>> Dear Mr.Olivier Desnoë >>> >>> I hope you're fine and well, >>> >>> >>> >>> At first thank you very much for your fast response , actually I am just >>> start with Ryu . >>> >>> >>> >>> The issue : >>> >>> 1- The host send DHCP discover packet , I capture the packet you can >>> find it in the attached of this e-mail. >>> >>> 2- The DHCP discover packet content 4 protocols ( Ethernet , IPv4 , >>> UDP , DHCP-discover ) >>> >>> 3- The Ryu controller when received the DHCP discover packet see the >>> packet content only 3 protocols ( Ethernet , IPv4 ,UDP ), you can see the >>> message received by Ryu controller in attached file of this e-mail. >>> >>> 4- Therefor I cannot parsing the DHCP discover packet and >>> simple_dhcp_server is not work. >>> >>> >>> >>> I hope my explain for the issue is clear , and I do not why this happen , >>> is the issue form controller ? or from me ? >>> >>> >>> >>> Thank you very much >>> >>> >>> >>> Best Regards >>> >>> Munther Numan >>> Master Student >>> Faculty of Engineering >>> University Putra Malaysia >>> >>> *From:*Olivier Desnoë [mailto:olivier.des...@gmail.com] >>> *Sent:* Friday, December 16, 2016 9:23 PM >>> *To:* Munther Numan; Ryu-devel >>> *Subject:* Re: [Ryu-devel] bug in parsing dhcp packet >>> >>> >>> >>> Have you tried to put some debug prints in the parsing function of dhcp.py? >>> >>> >>> >>> Le ven. 16 déc. 2016 à 12:28, Munther Numan <munpro...@gmail.com >>> <mailto:munpro...@gmail.com>> a écrit : >>> >>> Dear all , Greeting .. >>> >>> >>> >>> I get error when I run simple dhcp server , I capture the packet in >>> wireshark and I see the packet is content 4 protocols ( Ethernet , ipv4 , >>> udp , dhcp discover ) but in Ryu framework I see only 3 protocols such as >>> below : >>> >>> >>> >>> msg =ev.msg >>> >>> pkt =packet.Packet(msg.data) >>> >>> printpkt.protocols >>> >>> """ outputs: >>> >>> >>> [ethernet(dst='ff:ff:ff:ff:ff:ff',ethertype=2048,src='a0:36:9f:2d:a7: >>> f >>> 9'), >>> >>> >>> ipv4(csum=14742,dst='255.255.255.255',flags=0,header_length=5,identif >>> i >>> cation=0,offset=0, >>> >>> >>> option=None,proto=17,src='0.0.0.0',tos=16,total_length=328,ttl=128,ve >>> r >>> sion=4), >>> >>> >>> udp(csum=39669,dst_port=67,src_port=68,total_length=308), >>> >>> >>> '\x01\x01\x06\x00F\x08\x9f\x06\x00\xc8\x00\x00\x00\x00\x00\x00\x00\x0 >>> 0 >>> \x00\x00\x00\x00\x00\x00\x00\x00\x00 >>> >>> >>> \x00\xa06\x9f-\xa7\xf9\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x0 >>> 0 >>> \x00\x00\x00\x00\x00\x00\x00\x00\x00 >>> >>> >>> \x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\ >>> x >>> 00\x00\x00\x00\x00\x00\x00\x00\x00 >>> >>> \x00\x00\x00\x00\x00\x04\n\x00\xaa\x00\x00\x00\x00'] >>> >>> """ >>> >>> I know this packet is dhcp discover becoues as you see in udp src_port >>> is 68 and dst_port is 67 but how can I parsing this packet when I write the >>> code below I did nt get any thing : >>> >>> >>> >>> dhcpPacket = pkt.get_protocol(dhcp.dhcp) >>> >>> print dhcppacket >>> >>> >>> >>> ''' output : >>> >>> None >>> >>> ''' >>> >>> >>> >>> Please if you can help me to solve this issue . >>> >>> >>> >>> >>> >>> Best Regards >>> >>> Munther Numan >>> Master Student >>> Faculty of Engineering >>> University Putra Malaysia >>> >>> >>> >>> >>> >>> >>> >>> >>> ------------------------------------------------------------------------------ >>> Check out the vibrant tech community on one of the world's most >>> engaging tech sites, SlashDot.org! >>> http://sdm.link/slashdot_______________________________________________ >>> Ryu-devel mailing list >>> Ryu-devel@lists.sourceforge.net <mailto:Ryu-devel@lists.sourceforge.net> >>> https://lists.sourceforge.net/lists/listinfo/ryu-devel >>> >>> >>> >>> --------------------------------------------------------------------- >>> - >>> -------- Check out the vibrant tech community on one of the world's >>> most engaging tech sites, SlashDot.org! http://sdm.link/slashdot >>> >>> >>> >>> _______________________________________________ >>> Ryu-devel mailing list >>> Ryu-devel@lists.sourceforge.net >>> https://lists.sourceforge.net/lists/listinfo/ryu-devel >>>
dhcp_discover_packet_from_controller_side_pkt_in_single.pcap
Description: application/vnd.tcpdump.pcap
------------------------------------------------------------------------------ Developer Access Program for Intel Xeon Phi Processors Access to Intel Xeon Phi processor-based developer platforms. With one year of Intel Parallel Studio XE. Training and support from Colfax. Order your platform today.http://sdm.link/intel
_______________________________________________ Ryu-devel mailing list Ryu-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/ryu-devel
