[OPNFLWPLUG-557] Broken protocol handling part 1 - incorrect handshake Created: 06/Oct/15  Updated: 27/Sep/21  Resolved: 02/Nov/15

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

Type: Bug
Reporter: Anton Ivanov Assignee: Unassigned
Resolution: Cannot Reproduce Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


External issue ID: 4418

 Description   

Handshake in Openflow (both 1.0 and 1.3) is incorrect.

Spec says that a HELLO exchange must be completed for controller and switch to agree to the features. Controller starts issuing further protocol dependent requests BEFORE it gets the first HELLO from the switch. This is a violation of the spec.

Compliance to the spec should be the standard behavior and should be possible to override it when dealing with non-compliant implementations via a settable config property.



 Comments   
Comment by Michal Rehak [ 06/Oct/15 ]

Hi Anton,
what makes you think that openflowPlugin sends further requests before receiving get-features reply from switch?

Comment by Anton Ivanov [ 16/Oct/15 ]

Trying to reproduce it again - I lost the tpcdump trace where the controller was sending the stats request before it should. Once I have it, will update the bug.

Comment by Icaro Camelo [ 30/Oct/15 ]

Hi guys,

I tested handshake with ODL and Ryu, but only Ryu follows exactly what the specs says. A OFPT_HELLO response message isn't sent back to device.

  • Controller IPL: 10.0.1.6

Captures here:

ODL handshake: https://www.cloudshark.org/captures/750ff9b41e8f
Ryu handshake: https://www.cloudshark.org/captures/6e1f33a9deb0

I think it's not exactly a bug, but a matter of protocol conformity.

Comment by Icaro Camelo [ 02/Nov/15 ]

I talked to Michal and he told me that the pipeline flushing was optimized.
That's why we can see a OFPT_HELLO response from controller inside of OFPT_FEATURES_REQUEST (packet #2) here: https://www.cloudshark.org/captures/750ff9b41e8f.

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