Lines Matching full:frame
49 The fundamental communication unit of the SSH protocol is a frame
50 (:c:type:`struct ssh_frame <ssh_frame>`). A frame consists of the following
53 .. flat-table:: SSH Frame
63 - Type identifier of the frame.
67 - Length of the payload associated with the frame.
73 Each frame structure is followed by a CRC over this structure. The CRC over
74 the frame structure (|TYPE|, |LEN|, and |SEQ| fields) is placed directly
75 after the frame structure and before the payload. The payload is followed by
77 the frame has ``LEN=0``), the CRC of the payload is still present and will
79 equals the number of bytes inbetween the CRC of the frame and the CRC of the
96 A message consists of |SYN|, followed by the frame (|TYPE|, |LEN|, |SEQ| and
97 CRC) and, if specified in the frame (i.e. ``LEN > 0``), payload bytes,
100 same sequence ID (|SEQ|), stored inside the frame (more on this in the next
103 A frame can have the following types
106 .. flat-table:: SSH Frame Types
120 - Sent to acknowledge receival of |DATA| frame.
133 different frame types will be described in more depth in the next section.
140 |DATA_NSQ|-type frame, followed by its CRC, payload, and payload CRC. In
141 case of a |DATA_NSQ|-type frame, the exchange is then finished. In case of a
142 |DATA_SEQ|-type frame, the receiving party has to acknowledge receival of
143 the frame by responding with a message containing an |ACK|-type frame with
144 the same sequence ID of the |DATA| frame. In other words, the sequence ID of
145 the |ACK| frame specifies the |DATA| frame to be acknowledged. In case of an
147 containing an |NAK|-type frame. As the sequence ID of the previous data
148 frame, for which an error is indicated via the |NAK| frame, cannot be relied
149 upon, the sequence ID of the |NAK| frame should not be used and is set to
150 zero. After receival of an |NAK| frame, the sending party should re-send all
157 used to associate an ``ACK`` with its ``DATA_SEQ``-type frame, but not
164 tx: -- SYN FRAME(D) CRC(F) PAYLOAD CRC(P) -----------------------------
165 rx: ------------------------------------- SYN FRAME(A) CRC(F) CRC(P) --
167 where both frames have the same sequence ID (``SEQ``). Here, ``FRAME(D)``
168 indicates a |DATA_SEQ|-type frame, ``FRAME(A)`` an ``ACK``-type frame,
169 ``CRC(F)`` the CRC over the previous frame, ``CRC(P)`` the CRC over the
174 tx: -- SYN FRAME(D) CRC(F) PAYLOAD CRC(P) -----------------------------
175 rx: ------------------------------------- SYN FRAME(N) CRC(F) CRC(P) --
177 upon which the sender should re-send the message. ``FRAME(N)`` indicates an
178 |NAK|-type frame. Note that the sequence ID of the |NAK|-type frame is fixed
183 tx: -- SYN FRAME(DATA_NSQ) CRC(F) PAYLOAD CRC(P) ----------------------
195 Commands are sent as payload inside a data frame. Currently, this is the
202 from the frame payload length given in the corresponding frame, i.e. it is
203 ``frame.len - sizeof(struct ssh_command)``. The command struct contains the
243 detection mechanism (e.g. CRCs), this is solely done on the frame level.
269 Frame-protocol wise these are two separate exchanges, and may even be
313 commands (ACKed frame but no command response) has been observed. For five
318 occasional frame drops happen. Apart from this, with a limit of three
319 pending requests, no dropped commands (i.e. command being dropped but frame
329 depend on the assumption that there is only one non-acknowledged data frame.
331 number. This means that, if a frame that has been successfully received by
333 will only detect this if it has the sequence ID of the last frame received
336 frame as such, and thus execute the command in this frame each time it has
341 In conclusion, this suggests a limit of at most one pending un-ACKed frame
343 frames) and at most three pending commands. The limit to synchronous frame