buffer_id should be ignored for OFPFC_DELETE and OFPFC_DELETE_STRICT

[jmiserez]

According to the spec (versions 1.0 through 1.5.0) , the buffer_id in ofp_flow_mod is defined as:

uint32_t buffer_id;
 /* Buffered packet to apply to, or OFP_NO_BUFFER. Not meaningful for OFPFC_DELETE*. */

and "This field is ignored by OFPFC_DELETE and OFPFC_DELETE_STRICT flow mod messages."

However, in switch.py, the _rx_flow_mod does the following:

if ofp.buffer_id is not None:
      self._process_actions_for_packet_from_buffer(ofp.actions, ofp.buffer_id,
                                                   ofp)

even if the flow mod is of type OFPFC_DELETE*. Instead, the buffer_id should be ignored for deletes and no actions should taken even if there is a value in the buffer_id other than OFP_NO_BUFFER.

See also this bug in Flowvisor for a similar description of the issue.

Openvswitch also only outputs packets for ADD and MODIFY*, and does not output packets for DELETE*s.

[MurphyMc]

Yeah, this doesn't look right; thanks for the report.

It seems like there might be other cases where we'd get bad behavior too. For example, there are several ways that _flow_mod_add() can fail, e.g., when rejecting an emergency flow with a nonzero timeout. I somehow doubt that the actions should be applied to the buffered packet in such a case.

Offhand it seems like we should do one of two things:

1. Leave executing of actions for a buffer_id to the individual _flow_mod_X() handler and removing it from _rx_flow_mod(). It's just two lines to do the processing, so this wouldn't be a whole lot of extra code. We could make it a single line by putting a check for buffer_id==None in _process_actions_for_packet() itself and having it silently do nothing in such cases.
2. Having the _flow_mod_X() handlers return a value to indicate whether action processing should take place. (Or maybe the reverse -- returning False stops action processing -- so that the default is to do so.)

[SyedMohsan]

Hello
am installing flow mode like this
msg = of.ofp_flow_mod()
msg.match.dl_type = 0x0800
msg.match.nw_proto =17
msg.match.nw_src = source_ip #string type
msg.match.nw_dst = destination_ip #string type
msg.match.tp_dst = destination_udp_port #its destination UDP port
msg.priority = 1000
msg.hard_timeout = 0
msg.idle_timeout = 0
msg.actions.append(of.ofp_action_output(port=2))
core.openflow.sendToDPID(1 , msg)

its working correctly for source to destination UDP data sending using socket programs (server , client ) but when i am interrupting to stop udp traffic between source_ip and destination_ip using flow message below its not working and subsequent packets transferring is continue

msg = of.ofp_flow_mod()
msg.match.dl_type = 0x0800
msg.match.nw_proto =17
msg.match.nw_src = source_ip #source_ip
msg.match.nw_dst = destination_ip #destination_ip
msg.priority = 1000
msg.command = of.OFPFC_DELETE_STRICT
msg.command = of.OFPFF_SEND_FLOW_REM
msg.actions.append(of.ofp_action_output(port=2))
core.openflow.sendToDPID(1 , msg)
is this delete method is faulty?Topology has single switch and 2 host only.
Anticipated thanks for your response

[MurphyMc]

This seems like it should be its own issue, but: Why are you setting .command twice for the remove? And you shouldn't need to add actions to a delete.

[SyedMohsan]

Thank you very much sir MurphyMc.
solved

[SyedMohsan]

Dear sir MurphyMc!
I want to extract time of packet in and out ,send PackectIn , when command from controller receive at switch , number of packets a switch has received , Whereas multiple clients are sending UDP traffic over multiple paths to gateway .Switch functions are written in switch.py (SoftwareSwitchBase) , but i am unable to get these time instance. How can i enable these functions in my controller ,or to dump the time statistics in file. mainly i want to explore _rx_flow_mod ,_rx_packet_out ,rx_packet methods.
Anticipated thanks for help

[jmiserez]

@SyedMohsan Does this have anything to do with the bug in question?

If not, please don't ask here on this issue, and instead see the I’ve got a problem / bug! Can you help me? page or post to the mailing list. Asking on random Github issues is not the right approach, as I'm getting notifications for each comment.