Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

PHYPayload Unmarshalling -> uplink #3

Closed
KtorZ opened this issue Jan 13, 2016 · 1 comment
Closed

PHYPayload Unmarshalling -> uplink #3

KtorZ opened this issue Jan 13, 2016 · 1 comment

Comments

@KtorZ
Copy link
Contributor

KtorZ commented Jan 13, 2016

Hey !
I just stumble across a small issue. How to unmarshal a payload if you don't know by advance if its uplink or downlink ?

payload = new(PHYPayload) // or PHYPayload{}, doesn't really matter here
payload.UnmarshalBinary(raw) 

PHYPayload.uplink is false by default, so, the above line is equivalent to:

payload = NewPHYPayload(false)
payload.UnmarshalBinary(raw)

But what if can't make the assumption whether the payload is relative to an uplink or a downlink ?
I feel a bit uncomfortable with having to handle externally to the PHYPayload itself the way it is going to be marshalled or unmarshalled regarding to an unexported attribute. Do you agree ?
Shall we find a way to make unmarshalBinary works in both cases in order to obtain the correct under-relying structure ?

Otherwise, each time one transmits a raw sequence of bytes representing a physical payload, one's also has to transmit whether or not its an uplink or downlink payload (this is obvious when you consider a context where the receiver / sender knows what they are doing, but considering libraries which manipulate payloads out of any context, this is not that straightforward).

As far as I see in the implementation, the uplink attribute is only used by MAC commands to check if the payload refers to a valid command depending on its nature (commands are split into two groups, uplink-related commands, and downlink-related commands). Nevertheless, isn't the nature of the payload defined by the command (and not the opposite way) ?

Let me know,
Thanks.

@brocaar
Copy link
Owner

brocaar commented Jan 15, 2016

Thanks again for your input :-)

There are a couple of things that are depending on the direction of the payload: calculation of MIC, MAC commands (uplink and downlink share the same bits in the CID field), encryption and frame counters. So without knowing if it's uplink or downlink, there is no way to decode and validate a payload correctly.

It is possible to guess the direction by looking at the MType field. This will work in most cases, except for MType=Proprietary, so this is not a solid solution.

So I think there is no way to know for sure if the payload is uplink or downlink by looking at the byte slice, unfortunately.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants