driver-api/surface_aggregator/ssh.rst

50 The fundamental communication unit of the SSH protocol is a frame
51 (:c:type:`struct ssh_frame <ssh_frame>`). A frame consists of the following
54 .. flat-table:: SSH Frame
64      - Type identifier of the frame.
68      - Length of the payload associated with the frame.
74 Each frame structure is followed by a CRC over this structure. The CRC over
75 the frame structure (|TYPE|, |LEN|, and |SEQ| fields) is placed directly
76 after the frame structure and before the payload. The payload is followed by
78 the frame has ``LEN=0``), the CRC of the payload is still present and will
80 equals the number of bytes between the CRC of the frame and the CRC of the
97 A message consists of |SYN|, followed by the frame (|TYPE|, |LEN|, |SEQ| and
98 CRC) and, if specified in the frame (i.e. ``LEN > 0``), payload bytes,
101 same sequence ID (|SEQ|), stored inside the frame (more on this in the next
104 A frame can have the following types
107 .. flat-table:: SSH Frame Types
121      - Sent to acknowledge receival of |DATA| frame.
134 different frame types will be described in more depth in the next section.
141 |DATA_NSQ|-type frame, followed by its CRC, payload, and payload CRC. In
142 case of a |DATA_NSQ|-type frame, the exchange is then finished. In case of a
143 |DATA_SEQ|-type frame, the receiving party has to acknowledge receival of
144 the frame by responding with a message containing an |ACK|-type frame with
145 the same sequence ID of the |DATA| frame. In other words, the sequence ID of
146 the |ACK| frame specifies the |DATA| frame to be acknowledged. In case of an
148 containing an |NAK|-type frame. As the sequence ID of the previous data
149 frame, for which an error is indicated via the |NAK| frame, cannot be relied
150 upon, the sequence ID of the |NAK| frame should not be used and is set to
151 zero. After receival of an |NAK| frame, the sending party should re-send all
158 used to associate an ``ACK`` with its ``DATA_SEQ``-type frame, but not
165     tx: -- SYN FRAME(D) CRC(F) PAYLOAD CRC(P) -----------------------------
166     rx: ------------------------------------- SYN FRAME(A) CRC(F) CRC(P) --
168 where both frames have the same sequence ID (``SEQ``). Here, ``FRAME(D)``
169 indicates a |DATA_SEQ|-type frame, ``FRAME(A)`` an ``ACK``-type frame,
170 ``CRC(F)`` the CRC over the previous frame, ``CRC(P)`` the CRC over the
175     tx: -- SYN FRAME(D) CRC(F) PAYLOAD CRC(P) -----------------------------
176     rx: ------------------------------------- SYN FRAME(N) CRC(F) CRC(P) --
178 upon which the sender should re-send the message. ``FRAME(N)`` indicates an
179 |NAK|-type frame. Note that the sequence ID of the |NAK|-type frame is fixed
184     tx: -- SYN FRAME(DATA_NSQ) CRC(F) PAYLOAD CRC(P) ----------------------
196 Commands are sent as payload inside a data frame. Currently, this is the
203 from the frame payload length given in the corresponding frame, i.e. it is
204 ``frame.len - sizeof(struct ssh_command)``. The command struct contains the
244 detection mechanism (e.g. CRCs), this is solely done on the frame level.
270 Frame-protocol wise these are two separate exchanges, and may even be
315 commands (ACKed frame but no command response) has been observed. For five
320 occasional frame drops happen. Apart from this, with a limit of three
321 pending requests, no dropped commands (i.e. command being dropped but frame
331 depend on the assumption that there is only one non-acknowledged data frame.
333 number. This means that, if a frame that has been successfully received by
335 will only detect this if it has the sequence ID of the last frame received
338 frame as such, and thus execute the command in this frame each time it has
343 In conclusion, this suggests a limit of at most one pending un-ACKed frame
345 frames) and at most three pending commands. The limit to synchronous frame