[OPNFLWPLUG-246] [DEV] Too small variable for OF-Port-Number Created: 18/Aug/14  Updated: 27/Sep/21  Resolved: 30/Oct/14

Status: Resolved
Project: OpenFlowPlugin
Component/s: General
Affects Version/s: None
Fix Version/s: None

Type: Bug
Reporter: Michael Wodniok Assignee: Martin Bobak
Resolution: Done Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: Linux
Platform: PC

Attachments: Text File file_1569.txt    
External issue ID: 1569

 Description   

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:

WARN o.o.c.sal.compatibility.NodeMapping - nodeConnectorId not supported (short): 9437207
java.lang.NumberFormatException: Value out of range. Value:"9437207" Radix:10

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.

Full output of the java-errors are contained in the attachment.

 Comments   
Comment by Michael Wodniok [ 18/Aug/14 ]

Attachment file_1569.txt has been added with description: complete java-error output

Comment by Martin Bobak [ 25/Aug/14 ]

pushed fix https://git.opendaylight.org/gerrit/#/c/10248/

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.

Related https://bugs.opendaylight.org/show_bug.cgi?id=1234

Michal Rehak's explanation for CONTROLLER-575

Hi Paul,
the goal of BUG-1234 was to change node.id and nodeConnector.id created by sal-compatibility (md-sal – 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.)

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.

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.

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.

I guess if you need OF-1.3 then you might want to consider migration to MD-SAL API and stop using adapters.

Regards,
Michal

Comment by Pedro Costa [ 20/Oct/14 ]

Hi,
The project I'm working on uses OF 1.3 and we've just migrated to Helium.

I believe this exception wasn't occurring on Hydrogen because the method toADNodeConnectorId() from NodeMapping class (sal-compatibility) was returning

nodeConnectorId.getValue()

instead of

Short.valueOf(nodeConnectorIdStripped)

My question is: why is this conversion happening when the -of13 is enabled? Shouldn't it support an integer value for the portNumber?
Also, what is the real purpose of sal-compatibility.jar when of13 is on?

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.

Regards,
Pedro Costa

Comment by Martin Bobak [ 30/Oct/14 ]

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.

Generated at Wed Feb 07 20:31:57 UTC 2024 using Jira 8.20.10#820010-sha1:ace47f9899e9ee25d7157d59aa17ab06aee30d3d.