https://jira.opendaylight.org This file is an XML representation of an issue en-us 8.20.10 820010 22-06-2022 https://jira.opendaylight.org/browse/OPNFLWPLUG-246 OpenFlowPlugin <p>When connecting a HP-5500 to OD-daily-version (tested with the one built on Aug 16 together with the learningswitch-sample) i get following (slice of) output:</p> <p>WARN o.o.c.sal.compatibility.NodeMapping - nodeConnectorId not supported (short): 9437207<br/> java.lang.NumberFormatException: Value out of range. Value:"9437207" Radix:10</p> <p>9437207 is a port number of the switch. After that message a NullPointerException follows. The corresponding variable should be an integer, because the current OF-specification defines at 7.2.1 "Port Structures" a 32-bits long port_no. Other tested switches work because they use small port numbers.</p> <p>Full output of the java-errors are contained in the attachment.</p> <p>Operating System: Linux<br/> Platform: PC</p> OPNFLWPLUG-246

[DEV] Too small variable for OF-Port-Number

Bug Resolved Done Martin Bobak Michael Wodniok Mon, 18 Aug 2014 08:00:01 +0000 Mon, 27 Sep 2021 09:01:17 +0000 Thu, 30 Oct 2014 09:59:59 +0000 General 0 3 <p>Attachment file_1569.txt has been added with description: complete java-error output</p> <p>pushed fix <a href="https://git.opendaylight.org/gerrit/#/c/10248/" class="external-link" target="_blank" rel="nofollow noopener">https://git.opendaylight.org/gerrit/#/c/10248/</a></p> <p>Fix will prevent NPE only. It'will still cause ConstructException in case of port number greater than uint16. However ConstructException is more suitable exception than NPE. </p> <p>Related <a href="https://bugs.opendaylight.org/show_bug.cgi?id=1234" class="external-link" target="_blank" rel="nofollow noopener">https://bugs.opendaylight.org/show_bug.cgi?id=1234</a></p> <p>Michal Rehak's explanation for <a href="https://jira.opendaylight.org/browse/CONTROLLER-575" title="Change Node_Type and Node_ID in adaptors to match AD-SAL" class="issue-link" data-issue-key="CONTROLLER-575"><del>CONTROLLER-575</del></a></p> <p>Hi Paul,<br/> the goal of BUG-1234 was to change node.id and nodeConnector.id created by sal-compatibility (md-sal &#8211; ad-sal adapters) to be the same as if they were acquired directly via ad-sal. (So that AD-SAL apps could seamlessly switch to MD-SAL.)</p> <p>I didn't realize there are other protocols and node(+nodeConnector) types which go through adapters and use MD-SAL type - both have id based on string type. There are already some fixes regarding that in order to convert only ids with "openflow:" prefix.</p> <p>But the target type of node and nodeConnector in AD-SAL reflects OF-1.0 spec where we have uint64 for datapathId and uint16 for portId. So if you need OF-1.3 port (uint32) to be converted by sal-compatibility adapters then you hit the OF-1.0 vs. OF-1.3 difference. </p> <p>I have no info regarding AD-SAL plans and OF-1.3 support and currently there is no lossless way to get OF-1.3 port through adapters.</p> <p>I guess if you need OF-1.3 then you might want to consider migration to MD-SAL API and stop using adapters.</p> <p>Regards,<br/> Michal</p> <p>Hi,<br/> The project I'm working on uses OF 1.3 and we've just migrated to Helium.</p> <p>I believe this exception wasn't occurring on Hydrogen because the method toADNodeConnectorId() from NodeMapping class (sal-compatibility) was returning </p> <p> nodeConnectorId.getValue() </p> <p>instead of </p> <p> Short.valueOf(nodeConnectorIdStripped)</p> <p>My question is: why is this conversion happening when the -of13 is enabled? Shouldn't it support an integer value for the portNumber?<br/> Also, what is the real purpose of sal-compatibility.jar when of13 is on? </p> <p>If it's really needed for the ODL internal data-model, this conversion makes no sense for newer versions of OpenFlow protocol because I can't really turn it off without removing the jar from distrubution.</p> <p>Regards,<br/> Pedro Costa</p> <p>Sal-compatibility's NodeMapping is ment to be mapper for OF1.3 to OF1.0. When you run distribution with -of13 switch, it means that OpenFlowPlugin will support openflow protocol version 1.3. It still supports version 1.0. So compatibility issues still has to be solved.</p> Development External issue ID 1569 External issue URL ODL SR Target Milestone Rank 0|i02zyv: