Operating System: Linux
Platform: PC

Hi Seils,

The command :
sudo ovs-vsctl add-port C1 eth0 – set Interface eth0 ofport_request=32768
is working fine with mininet version 2.1.0+ and openflow 1.3.
If you run the command :
sudo ovs-vsctl add-port C1 eth0 – set Interface eth0 ofport_request=-212

It will not accept the negative values.So it is working fine.

(In reply to Rajani Srivastava from comment #1)
> Hi Seils,
>
> The command :
> sudo ovs-vsctl add-port C1 eth0 – set Interface eth0 ofport_request=32768
> is working fine with mininet version 2.1.0+ and openflow 1.3.
> If you run the command :
> sudo ovs-vsctl add-port C1 eth0 – set Interface eth0 ofport_request=-212
>
> It will not accept the negative values.So it is working fine.

I just tested the Hydrogen base image and the issue still exists. Port numbers >32768 are represented as negative values.

Attachment attachment_for_value>32768_in_mininet.png has been added with description: checked for the value 33333

Attachment opendaylight_GUI_for_vale>32768.png has been added with description: checked in opendaylight GUI

Hi Seils,

I tested it again on Hydrogen base image.And found that for port number > 32768 ,it is working fine in command line as well in Opendaylight GUI.
Please find the attachments and update me where are you getting the negative values.

Attachment ports_info.png has been added with description: checked port number is accepted by ;

Checked that port number is accepted with following commands :

sudo ovs-vsctl list interface
sudo ovs-ofctl dump-ports br1

Hi Rajani,

If you pass a port number greater than 32767 when adding an interface to the bridge in ovs, it will show up as a negative integer in the ODL GUI when you look at the port numbers for devices. You will see the right value in ovs-vsctl dump-ports because ovs is fine with it, but ODL currently won't be able to store/discover/parse it correctly, and will show the port as a negative number.

The problem is that the open flow specification sets 16 bits aside for a port in the headers, and the third party openflowj library also accordingly reads/writes 16 bits on the wire, but java on the other hand, treats all short integers as signed. This is causing issues with the openflowj library and all other parts of the ODL code that deals with open flow ports because those 16 bits are treated as signed ints, not unsigned short ints as they should be.

I'm working on the fix for this, and the fix is complicated and will take a while.

Regards,
Vijay

Any updates on this?

Calling TCP/UDP.getSourcePort() for iperf supplied packets very often results in returned negative values. I name iperf since the client does not allow for specifying the source port and instead reserves a random available port thus almost always resulting in problems if port no. needs to be extracted from the packet.

This bug is part of the project to Move all ADSAL associated component bugs to ADSAL

Deprecated code.