Skip to content
This repository has been archived by the owner on Apr 22, 2024. It is now read-only.

Version unpacking problems #344

Closed
erickvermot opened this issue Apr 3, 2017 · 4 comments
Closed

Version unpacking problems #344

erickvermot opened this issue Apr 3, 2017 · 4 comments
Assignees
Milestone

Comments

@erickvermot
Copy link
Contributor

Wrong unpack version.
Should lead to exception.
::

>>> from pyof.v0x01.common.utils import unpack_message
>>> m = unpack_message(b'\x04\x00\x00\x08\x00\x00\x00\x01') # v0x04 Hello message
>>> m.header.version
UBInt8(1)
@erickvermot erickvermot modified the milestone: 2017.1b2 Apr 3, 2017
@renanrodrigo
Copy link
Contributor

It happens because unpack_message creates the header before unpacking the data to it, and the version is defined in creation.
I think the best way to solve this problem is not a local correction, but refactoring the code to put unpack_message in /foundation/ and changing it's behavior: unpack the whole data (including the protocol version).

@diraol
Copy link
Contributor

diraol commented Apr 3, 2017

Proposal:

Create a "general" unpack method under foundation/utils and a specific unpack under <version>/utils, for each version. The "general" unpack would discover the correct version to be used and then call the specific unpack.

May be the specific unpack methods should raise some exception, but I think that this (validation/exception) may be related to the issue #96 anyway.

@erickvermot
Copy link
Contributor Author

erickvermot commented Apr 3, 2017

I agree. But I also think 'version handling' could be implemented in some other way.
The problem with "disovering" the correct version is that a connection that was setup for working with v0x01 or some other version, should reject packets from other versions. [update: sorry, this is not a problem if the 'specific' unpack is used like suggested]
blueprint EP09 talks about this, and in Proposal/Other comments section proposes a way to deal with versions.

@erickvermot
Copy link
Contributor Author

this will be solved if issue #407 is solved.

macartur added a commit to macartur/python-openflow that referenced this issue Nov 22, 2017
Reuse unpack_message method from v0x01.common.utils and v0x04.common.utils
Fix kytos#344
macartur added a commit to macartur/python-openflow that referenced this issue Nov 22, 2017
Reuse unpack_message method from v0x01.common.utils and v0x04.common.utils
Fix kytos#344
macartur added a commit to macartur/python-openflow that referenced this issue Nov 22, 2017
Reuse the methods unpack_message from pyof.[version].common.utils
Create a constant called MESSAGE_TYPES
Fix kytos#344
macartur added a commit to macartur/python-openflow that referenced this issue Nov 22, 2017
Reuse the methods unpack_message from pyof.[version].common.utils
Create a constant called MESSAGE_TYPES
Fix kytos#344
macartur added a commit to macartur/python-openflow that referenced this issue Nov 22, 2017
Reuse the methods unpack_message from pyof.[version].common.utils
Create a constant called MESSAGE_TYPES
Fix kytos#344
@macartur macartur self-assigned this Nov 22, 2017
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests

4 participants