Operating System: Linux
Platform: PC

Attachment Screenshot from 2014-09-02 17:52:32.png has been added with description: Debugged MatchconvertorImplto find the mac address is wrongly set.

Assigning it to Prasanna - in the meeting we had discussed this was a user error - but lets see.

The Mac address in the addflowinputbuilder is actually set incorrectly

Attachment error.JPG has been added with description: The Mac address in the flow input builder is actually set incorrectly

Anil,

I don't think it will be the case but could this be anything to do with the MAC address comparator bug?

• Abhijit

Hi Abhijit,

No, comparator comes to the picture where we fetch statistics data from switch. I believe this issue is happening while sending flow down to the switch.

Thanks
Anil

Prasanna had sent the following note to Shuva after investigation:

Hello,
As discussed please move the bug(Mac address issue) to MD-SAL and assign it to default user.

Abhijit:
Shuva bypassed MD-SAL and tested with plugin and library and MAC address provision works.
Rgds
Prasanna

Hello - A summary of the problem / solution was request at the MD-SAL status meeting today.

Could someone please summarize what the problem is and what the propose solution is? People are just interested in what is going on with this one.

Thank you!

Devin

Can you expand your problem report with the type of "mac" and how it is being initialized?

Added testcase which shows this is not bug of MD-SAL.

https://git.opendaylight.org/gerrit/11307

Testcase write correctly constructed mac address in flow:
ethernet-match with source mac, source destination and also apply-actions
with set-dl-dst and set-dl-src.

Then testcase read it and compares MAC address value with original one.
This showcase MD-SAL did not change mac address as was supplied by user.

As Robert mentioned, please show how this flow was constructed, because everything points it is user bug, when some did something as:

MacAddress original;
MacAddress mac = new MacAddress(original.toString()) instead of
new MacAddress(original) or new MacAddress(original.getValue()).

Returning it back to Openflowplugin, since submitted test case shows it is not Openflowplugin bug.

Also integration testsuite https://jenkins.opendaylight.org/integration/job/integration-master-csit-base-of13/2629/robot/report/log.html
reports flow with mac address as working.

The attachment clearly shows that value of exposed MacAddress contains toString output of some probably internal instance of mac address:

getAddress "MacAddressvalue="

The attachment clearly shows that value of exposed MacAddress contains toString output of some (probably internal) instance of mac address:

getAddress=MacAddress [_value=MacAddress [_value=a0:b1:c2:d3:e4:35]]

MacAddress.toString() looks like this:
java.lang.StringBuilder builder = new java.lang.StringBuilder(org.opendaylight.yang.gen.v1.urn.ietf.params.xml.ns.yang.ietf.yang.types.rev100924.MacAddress.class.getSimpleName()).append(" [");
boolean first = true;

if (_value != null) {
if (first)

else

builder.append("_value=");
builder.append(_value);
}
return builder.append(']').toString();

where _value is of type String and contains mac address in hex-format.

Correct dump would look like this:
getAddress=MacAddress [_value=a0:b1:c2:d3:e4:35]

Assigning to reporter.

The anamoly is identified in the org.opendaylight.controller.frm.impl.FlowForwarder which implements the DataChangeListener interface.

Is it possible that the issue is in the DataListener code path?

The anomaly is identified in the org.opendaylight.controller.frm.impl.FlowForwarder which implements the DataChangeListener interface.

Is it possible that the issue is in the DataListener code path?

The anomaly is identified in the org.opendaylight.controller.frm.impl.FlowForwarder which implements the DataChangeListener interface.

Is it possible that the issue is in the DataListener code path?

Hi Mehar,
the attached picture of debug session is reason to believe that corrupted flow was created at the beginning of the pipeline:

1. app/user creates flow
2. send it to datastore/config (using API or restconf)
3. FlowForwarder is notified and invokes appropriate rpc on corresponding service provider
4. openflowplugin translates flow from MD-SAL model to OFJava-API model and invokes OFJava rpc
5. OFJavaRPC encodes the input into flowMod message and writes it to byteBuffer
6. Netty.io sends content of the buffer to corresponding switch

So if:

• the malformed macAddress was observed in FlowForwarder (3.).
• and there exist flows containing macAddress which successfully pass this pipeline
  then the input at the very beginning of the pipeline should be checked. And as it was already noted - there is probably somewhere copy constructor of macAddress invoked with string presentation of macAddress instead of object reference or macAddress.getValue().

Please check input.

Moved to Helium 1 as SFC (sfcofl2) is not blocked on this and there is still an opinion from the OpenFlow plugin team that there was an issue with the input (see Michal Rehak's last comment).

no response