Hi all: This bug looks similar to the one Yi-Shou had on the NetFPGA platform. The problem happened in the NetFPGA platform when the first pkt that generated the pkt_in is acted upon by 2 actions. If let's say you don't act upon the first packet and drop it, and only insert a flow_mod without specifying the buf_id, then it used to work fine.
Maybe Tatsuya can mail you his patch and you can give this a try. Thanks Srini. On Mon, May 9, 2011 at 6:59 AM, Vishal <[email protected]> wrote: > Hi Yiannis, > > Here is the portion of log: For all good flow_mod actions= output:no. > > May 06 18:45:30|01904|poll_loop|DBG|[POLLIN] on fd 24: 0x805740c 0x8050c9b > 0x8053532 0x805356b 0x409ce7 > May 06 18:45:30|01905|vconn|DBG|unix:/tmp/vconn-unix.16632.0: sent > (Success): packet_in (xid=0x0): total_len=62 in_port=3 data_len=62 > buffer=0x000002c1 > tcp,in_port=3,dl_vlan=0xffff,dl_vlan_pcp=0x00,dl_src=00:30:48:54:f3:9e,dl_dst=00:09:44:46:64:bc,nw_src=10.1.1.2,nw_dst=10.1.1.3,nw_tos=0x00,tp_src=8080,tp_dst=2729, > > May 06 18:45:30|01906|poll_loop|DBG|[POLLIN] on fd 36: 0x805a770 0x8050cc6 > 0x8053532 0x805356b 0x409ce7 > May 06 18:45:30|01907|vconn|DBG|unix:/tmp/vconn-unix.16632.0: received: > flow_mod > (xid=0x0):tcp,in_port=3,dl_vlan=0xffff,dl_vlan_pcp=0x00,dl_src=00:30:48:54:f3:9e,dl_dst=00:09:44:46:64:bc,nw_src=10.1.1.2,nw_dst=10.1.1.3,tp_src=8080,tp_dst=2729, > ADD: cookie:0 idle:5 hard:0 pri:32768 buf:0x2c1 flg:0x1 > actions=CONTROLLER:128 > > ofdatapath: lib/ofpbuf.c:168: ofpbuf_prealloc_headroom: Assertion `size <= > ofpbuf_headroom(b)' failed. > May 06 18:45:30|01908|fault|EMER|Caught signal 6. > 0x0805666f > 0x001e6400 (__kernel_sigreturn+0x0) > 0x00420e42 (abort+0x182) > 0x004168e8 (__assert_fail+0xf8) > 0x08059729 > 0x0805974e (ofpbuf_push_uninit+0x1e) > 0x080507c7 (dp_output_control+0x57) > 0x080500c8 > 0x08052204 (dp_run+0x3b4) > 0x08053525 (udatapath_cmd+0x595) > 0x0805356b (main+0x1b) > 0x00409ce7 (__libc_start_main+0xe7) > > > regards, > Vishal > > On Sun, May 8, 2011 at 4:26 PM, Vishal <[email protected]> wrote: >> >> Hi Yiannis, >> >> Yes. I do install the flow after the packet in. >> >> However, i check for the reason (ofp_packet_in_reason) for packet in >> (ofp_packet_in). >> if the reason is OFPR_ACTION then I do not install the flow. if the reason >> is No match, then I install the rule with 2 actions. One to forward it to >> the destination and other to send it to the controller. >> >> I find that ofdatapath is crashing in lib/ofbuf.c. I can send the >> ofdatapath log as well as pcap capture file if required. >> >> Is multiple actions not supported in ofdatapath ? >> >> Thanks a lot for help. >> >> Regards, >> Vishal >> >> On Fri, May 6, 2011 at 7:31 PM, Yiannis Yiakoumis <[email protected]> >> wrote: >>> >>> (dropping nox-dev as this sounds cloer to an openflow related issue) >>> Hi Vishal, >>> Do you install the flow after a packet-in request? If so, make sure that >>> you install one only when a packet-in is due to no-match-found, otherwise >>> you'll end with a loop between the controller and the switch. >>> Regards, >>> Yiannis >>> >>> On Fri, May 6, 2011 at 3:23 PM, Vishal <[email protected]> wrote: >>>> >>>> Hello Murphy, >>>> >>>> I changed max_len to 128 for the action -> send to >>>> openflow.OFPP_CONTROLLER and tried again. >>>> >>>> what i observe is : The switch sends a Port Status Message >>>> (ofp_port_status) with OFPPR_MODIFY with reason field set as "Some >>>> attribute of the port has changed". >>>> >>>> The Physical Port Header field shows Port #: Local (local openflow >>>> "port") and Port Name : tap1. >>>> >>>> After this message is received the connection between controller and >>>> switch is down. >>>> >>>> I suspect this change in port status happens because the controller >>>> sends -> off_action with OFPAT_OUTPUT --> with output port to Controller. >>>> >>>> This is how i started the ofdatapths-> ofdatapath >>>> punix:/var/run/dp0.sock -i eth0,eth2 --local-port=tap:tap1 >>>> >>>> Is this a bug with openflow datapath or I am doing something wrong ? >>>> >>>> I would really appreciate any help in debugging this and making it work. >>>> >>>> Thanks a lot, >>>> >>>> Regards, >>>> Vishal >>>> >>>> On Thu, May 5, 2011 at 8:31 PM, Murphy McCauley <[email protected]> wrote: >>>>> >>>>> This looks fine to me on quick glance. Even if it wasn't, I'd say it >>>>> shouldn't >>>>> crash ofdatapath. You might want to bring it up on one of the OpenFlow >>>>> mailing lists like openflow-discuss (or maybe openflow-support now?). >>>>> >>>>> -- Murphy >>>>> >>>>> On Thursday, May 05, 2011 03:13:00 PM Vishal wrote: >>>>> > Hi, >>>>> > >>>>> > I want to duplicate a particular data flow to the controller. >>>>> > >>>>> > My set up includes nox based controller and userspace openflow >>>>> > switches >>>>> > (ofdatapath and ofprotocol) running on ubuntu. >>>>> > >>>>> > In pyswitch.py, I set up the following 'action': >>>>> > >>>>> > actions = [[openflow.OFPAT_OUTPUT, [0, prt[0]]], >>>>> > *[openflow.OFPAT_OUTPUT, >>>>> > [0, openflow.OFPP_CONTROLLER]]*] >>>>> > install_datapath_flow(dpid, flow, CACHE_TIMEOUT, >>>>> > openflow.OFP_FLOW_PERMANENT, >>>>> > actions, bufid, openflow.OFP_DEFAULT_PRIORITY, inport, buf) >>>>> > >>>>> > It seems this is not working and causes the ofdatapath process to >>>>> > crash. >>>>> > >>>>> > Is the above way correct way to apply multiple forwarding action for >>>>> > a >>>>> > matching flow? >>>>> > >>>>> > Does userspace openflow ofdatapath does not support multiple actions >>>>> > or >>>>> > action involving sending the flow to the controller. >>>>> > >>>>> > Thanks a lot for help, >>>>> > >>>>> > Regards, >>>>> > Vishal >>>> >>>> >>>> _______________________________________________ >>>> openflow-discuss mailing list >>>> [email protected] >>>> https://mailman.stanford.edu/mailman/listinfo/openflow-discuss >>>> >>> >> > > > _______________________________________________ > openflow-discuss mailing list > [email protected] > https://mailman.stanford.edu/mailman/listinfo/openflow-discuss > > _______________________________________________ openflow-discuss mailing list [email protected] https://mailman.stanford.edu/mailman/listinfo/openflow-discuss
