Operating System: Windows
Platform: PC

Attachment buffer_id_issue.pcapng has been added with description: Refer to frames 3,4,5,6 for which the buffer id is not set to correct value.

Sindhuri, while trying to reproduce this bug, in the packet-out - buffer_id it shows the value None and I don't see this value OFP_NO_BUFFER. Can you tell me the exact settings or configurations you have done at your end, due to which you are able to see that particular value?

Hi Debolina,

I have used CPqD switches . You can install CPqD switch from internet.
Mininet command to create topology:
sudo mn --topo linear,2 --controller 'remote,ip=<controllerip>,port=6653' --switch user

From mininet prompt, you can use “h1 ping –c 5 h2”.

From Rest client I have configured flow to the switches:

URI: http://localhost:8080/restconf/config/opendaylight-inventory:nodes/node/openflow:1/table/0/flow/300

Xml body:

<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<flow xmlns="urn:opendaylight:flow:inventory">
<strict>false</strict>
<instructions>
<instruction>
<order>0</order>
<apply-actions>
<action>
<order>0</order>
<output-action>
<output-node-connector>CONTROLLER</output-node-connector>
<max-length>40</max-length>
</output-action>
</action>
</apply-actions>
</instruction>
</instructions>
<table_id>0</table_id>
<id>300</id>
<cookie_mask>255</cookie_mask>
<installHw>false</installHw>
<match>
<ethernet-match>
<ethernet-type>
<type>2054</type>
</ethernet-type>
</ethernet-match>
</match>
<hard-timeout>1200</hard-timeout>
<flags>FlowModFlags [_cHECKOVERLAP=false, _rESETCOUNTS=false, _nOPKTCOUNTS=false, _nOBYTCOUNTS=false, _sENDFLOWREM=false]</flags>
<cookie>1</cookie>
<idle-timeout>1000</idle-timeout>
<flow-name>Fo1</flow-name>
<priority>2</priority>
<barrier>false</barrier>
</flow>

Thanks,
Sindhuri.

Any update on this Debolina?

(In reply to Abhijit Kumbhare from comment #3)
> Any update on this Debolina?

We were looking into the OPNFLWPLUG-72 which talks about the packet-out not having the buffer id for the corresponding packet-in which has the buffer id. While debugging we came across the code where the translation happens which is in the PacketInTranslator.Java from OFPlugin.
If you see this PacketInTranslator code, this takes in the message from the open flow and translates to mdsal message, while doing so it is not preserving the buffer id from our understanding.
So we were thinking to add a field in the PacketReceivedBuilder, effectively in the PackerReceiverImpl in the file PacketReceivedBuilder. We diescussed this with Michal Rehak and he mentioned to contact Ed Warnicke regarding this, as we are not sure on who else is using the PacketReceivedImpl and what implications it might have. This seems like a more architectural view question according to Michal.
Questions we had were:
1. Is adding the field bufferid into the PacketReceivedImpl the right way to go?
2. What modules should we be testing if we change this PacketReceivedImpl?
3. This is something that we are still yet to debug, where is this received packet digested by mdsal and also the other half of the flow which is packet out needs to be debugged as well. Michal/Ed, if you guys know then you can point us there. We will debug as we go over the flow.

We mailed Ed regarding the above questions but since its an enhancement bug, no response was received as it was not the priority that time.

No response more than 3 years. Closing.