InterfaceConfiguration encode/decode matches spec... but not reality

[rdaum]

As I discovered and reported to SubIoT team: Sub-IoT/Sub-IoT-Stack#129

Your implementation is technically correct (the best kind of correct).

But in reality the 'TE' byte is not properly parsed or produced by the reference implementation in C or the pyd7a library in Python. So 'Forward' action packets produced using your library will not be processed correctly by the gateway.

Not sure what the right thing to do here is.

[Stratus51]

Thanks for the feedback.

I've started a heavy refactoring of the library which will support multiple ALP versions, thus will allow supporting ALP implementations deviating from the specification.
But that refactoring is nowhere near complete, and I kinda have my hands full right now.

In the meantime, I've created a branch (ref_compat) whose purpose is to be compatible with Sub-IoT-Stack.

I'll publish that "reference compatible" library with the version scheme: 0.1.0-ref-compat.x.
I just published 0.1.0-ref-compat.0, containing the removal of the TE byte.
This should allow current devs to use this rust library's official releases with objects currently using the Sub-IoT-Stack implementation.

Do you have a way to test the compatibility of this new release with the Sub-IoT-Stack implementation?
Does this new "quick fix" version solve your current issue?

[rdaum]

I have local work which exercises your code against a local SubIoT stack installation on an STM board. I'll check your branch later today.
FWIW I wrote code that does the serial communication necessary to tunnel the ALP stuff over over USB serial to speak to a gateway node. I'll hopefully have something I can submit as a PR at some point, unless it'd be better as a separate library.

[Stratus51]

I believe the serial communication layer should be written as a separate library.
The Dash7 specification does not specify the transport layer of the ALP packets.
I think it was left out of the specification on purpose in order to leave the hardware link and associated the packet transport protocol customizable depending on the hardware implementation.

I know of another proprietary dash7 stack implementation and I think it uses a different serial communication protocol (I'll double check later).

If you end up writing a library for the serial communication of the open source implementation, I'd gladly add a link to it in the README of this library.

[rdaum]

Ok your changes seem to work for me.

One caveat is that I'm having issues with multiple request file commands in sequence (RequestFileData in a loop), the second result seems to not come back correctly. I'm suspecting there's potentially another similar issue somewhere in another message which I'll try to diagnose today by comparing byte by byte to the reference implementation again.

In the meantime the Sub-IoT people have acknowledged the "TE" issue with the spec and hopefully will work out some way to fix it in the reference implementation while also providing backward compat.

[Stratus51]

closed by #30