Added description of ZBOSS NCP protocol

[eexarevsky]

No description provided.

[eexarevsky]

What is wrong with CI?

[fxlb]

Try to run ./regen_html_pages.sh and commit the new linktypes/LINKTYPE_ZBOSS_NCP.html and the updated linktypes.html.

[eexarevsky]

Try to run ./regen_html_pages.sh and commit the new linktypes/LINKTYPE_ZBOSS_NCP.html and the updated linktypes.html.

Thanks! Done.

[infrastation]

The workflow is documented better now (see README.md). As usual, if merging these changes, please squash them.

[eexarevsky]

Hi!
Any chance to get it merged?

[infrastation]

What exactly was the result of the review? What was the reason for committing the work in progress commits?

[infrastation]

Michael, I asked what the review result was and you didn't provide any answer. You did not actually review these changes before merging, is this correct? (yes/no)

[mcr]

Michael, I asked what the review result was and you didn't provide any answer. You did not actually review these changes before merging, is this correct? (yes/no)

I read the issue, I read the changes, and I noted that fxlb had delegated the decision to me.
I also checked afterwards, that that regen man pages script didn't make any changes, confirming that they had run it correctly.

[infrastation]

Thank you for replying. Please note that Francois-Xavier requested feedback from you and also from Guy. Getting the CI to pass is a very basic check, long term pain often comes from the way link-layer headers are defined.

If these changes cannot be confirmed good anytime soon, I suggest to back them out and to take time to get it done right.

[infrastation]

I tried to have a critical look at this new header type; one thing that does not make sense in the new document is "All multi-byte numerical fields are little-endian." because all header fields before the payload are 1 byte long.

Other than that, it looks very difficult to misinterpret so long as one does not look inside the payload. @guyharris, could you please confirm whether the new header type is good enough to leave it in place and to move on?

[guyharris]

I tried to have a critical look at this new header type; one thing that does not make sense in the new document is "All multi-byte numerical fields are little-endian." because all header fields before the payload are 1 byte long.

I suppose if a later version of the protocol (version 1 or later) has multi-byte fields, it could apply there.

But maybe it should be removed until such a version is added, just in case somebody changes their mind and makes version 1 have a big-endian multi-byte numeric field.

[guyharris]

@guyharris, could you please confirm whether the new header type is good enough to leave it in place and to move on?

So the payload is described by the "ZBOSS NCP Serial Protocol" document linked to by the link-types page?

If so, does it begin with the "Low-level protocol" header, as described in section 3.2, so that the first two bytes of the payload are 0xde 0xad, in order? And, after 7 bytes of the low-level protocol header, including the header CRC, it has a 2-byte packet body CRC, followed by a "high-level protocol" packet, as described in section 3.4.3 "High level packet contents"? Or is the packet body CRC stripped out?

[infrastation]

@eexarevsky, you do not want to provide the feedback and you are fine with these changes reverted, is that correct?

[eexarevsky]

Hi!
Sorry for late replay: there were non-working days in Russia toll 01/09.
What was the problem?
I see questions about protocol details in your thread.
Is the problem in the little-endian issue?
BTW full dissector for ZBOSS NCP is in review in Wireshark now.

If so, does it begin with the "Low-level protocol" header, as described in section 3.2, so that the first two bytes of the payload are 0xde 0xad, in order?

[EE]
Yes

And, after 7 bytes of the low-level protocol header, including the header CRC, it has a 2-byte packet body CRC, followed by a "high-level protocol" packet, as described in section 3.4.3 "High level packet contents"? Or is the packet body CRC stripped out?

[EE]
Packet body CRC is included only if the body itself is present. Packet body is present if packet length is bigger than the header length. Some packets, like ACK/NACK, consists of header only.

[infrastation]

@guyharris, is this information sufficient? I presume it belongs to the DLT description page.

[eexarevsky]

If you need more info, please, describe what is missing - I can add the required description

[infrastation]

@guyharris, are the CRC comments clear enough to be copied into LINKTYPE_ZBOSS_NCP.html as they appear above? All other clarifications are already there.