[OPNFLWPLUG-558] Broken protocol handling part 1 - incorrect handshake Created: 06/Oct/15 Updated: 27/Sep/21 Resolved: 06/Oct/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 |
||
| External issue ID: | 4419 |
| Description |
|
Controller disregards switch responses during handshake phase in OpenFlow 1.3 Example. The switch sends a FEATURE REPLY which says: FLOW_STATS: False The controller immediately replies with OFPMP METER FEATURES That is broken - you are not supposed to ask the switch for meter features if it has not got any in the first place. |
| Comments |
| Comment by Michal Rehak [ 06/Oct/15 ] |
|
Talking about He-codebase, right? |
| Comment by Anton Ivanov [ 06/Oct/15 ] |
|
Yes. I will test the new one shortly with and without the config setting and if it does not behave per spec file that separately. I discussed this one with Anil - the spec is actually flawed here and the old behavior is probably the only way to work around the flaw. I assumed that you can imply that there are no meter stats if the stat related feature bits are False. However that is not the case as the spec appears to not have a direct FeatureReply feature bit to METER_FEATURES in the first place. I am going to close this one and continue going through the FSM (or to be more exact lack of) in the protocol handler and filing bugs for both old and new. |