fastboot: add UDP protocol.
Implements a UDP protocol for fastboot, documented in
fastboot_protocol.txt.
This version of the protocol does not include multi-packet windowing,
which will likely be needed to achieve reasonable speeds over WiFi.
Since we don't have any WiFi use cases yet, we'd like to get this in
now and update the protocol later if it becomes necessary.
Usage:
fastboot -s udp:<hostname>[:port] <command>
Bug: http://b/26154914
(cherry picked from commit 4601c978cad8b69e15ed63664ebb5dcf6aaf21b3)
Change-Id: Ia5bbae6bcd6405671f594d7120b3994746d234d3
diff --git a/fastboot/fastboot_protocol.txt b/fastboot/fastboot_protocol.txt
index 4aa48b1..2801703 100644
--- a/fastboot/fastboot_protocol.txt
+++ b/fastboot/fastboot_protocol.txt
@@ -17,9 +17,9 @@
* The protocol is entirely host-driven and synchronous (unlike the
multi-channel, bi-directional, asynchronous ADB protocol)
-* TCP
+* TCP or UDP
* Device must be reachable via IP.
- * Device will act as the TCP server, fastboot will be the client.
+ * Device will act as the server, fastboot will be the client.
* Fastboot data is wrapped in a simple protocol; see below for details.
@@ -217,3 +217,226 @@
Host [0x00][0x00][0x00][0x00][0x00][0x00][0x00][0x0B]getvar:none
Device [0x00][0x00][0x00][0x00][0x00][0x00][0x00][0x04]OKAY
Host <disconnect>
+
+
+UDP Protocol v1
+---------------
+
+The UDP protocol is more complex than TCP since we must implement reliability
+to ensure no packets are lost, but the general concept of wrapping the fastboot
+protocol is the same.
+
+Overview:
+ 1. As with TCP, the device will listen on UDP port 5554.
+ 2. Maximum UDP packet size is negotiated during initialization.
+ 3. The host drives all communication; the device may only send a packet as a
+ response to a host packet.
+ 4. If the host does not receive a response in 500ms it will re-transmit.
+
+-- UDP Packet format --
+ +----------+----+-------+-------+--------------------+
+ | Byte # | 0 | 1 | 2 - 3 | 4+ |
+ +----------+----+-------+-------+--------------------+
+ | Contents | ID | Flags | Seq # | Data |
+ +----------+----+-------+-------+--------------------+
+
+ ID Packet ID:
+ 0x00: Error.
+ 0x01: Query.
+ 0x02: Initialization.
+ 0x03: Fastboot.
+
+ Packet types are described in more detail below.
+
+ Flags Packet flags: 0 0 0 0 0 0 0 C
+ C=1 indicates a continuation packet; the data is too large and will
+ continue in the next packet.
+
+ Remaining bits are reserved for future use and must be set to 0.
+
+ Seq # 2-byte packet sequence number (big-endian). The host will increment
+ this by 1 with each new packet, and the device must provide the
+ corresponding sequence number in the response packets.
+
+ Data Packet data, not present in all packets.
+
+-- Packet Types --
+Query The host sends a query packet once on startup to sync with the device.
+ The host will not know the current sequence number, so the device must
+ respond to all query packets regardless of sequence number.
+
+ The response data field should contain a 2-byte big-endian value
+ giving the next expected sequence number.
+
+Init The host sends an init packet once the query response is returned. The
+ device must abort any in-progress operation and prepare for a new
+ fastboot session. This message is meant to allow recovery if a
+ previous session failed, e.g. due to network error or user Ctrl+C.
+
+ The data field contains two big-endian 2-byte values, a protocol
+ version and the max UDP packet size (including the 4-byte header).
+ Both the host and device will send these values, and in each case
+ the minimum of the sent values must be used.
+
+Fastboot These packets wrap the fastboot protocol. To write, the host will
+ send a packet with fastboot data, and the device will reply with an
+ empty packet as an ACK. To read, the host will send an empty packet,
+ and the device will reply with fastboot data. The device may not give
+ any data in the ACK packet.
+
+Error The device may respond to any packet with an error packet to indicate
+ a UDP protocol error. The data field should contain an ASCII string
+ describing the error. This is the only case where a device is allowed
+ to return a packet ID other than the one sent by the host.
+
+-- Packet Size --
+The maximum packet size is negotiated by the host and device in the Init packet.
+Devices must support at least 512-byte packets, but packet size has a direct
+correlation with download speed, so devices are strongly suggested to support at
+least 1024-byte packets. On a local network with 0.5ms round-trip time this will
+provide transfer rates of ~2MB/s. Over WiFi it will likely be significantly
+less.
+
+Query and Initialization packets, which are sent before size negotiation is
+complete, must always be 512 bytes or less.
+
+-- Packet Re-Transmission --
+The host will re-transmit any packet that does not receive a response. The
+requirement of exactly one device response packet per host packet is how we
+achieve reliability and in-order delivery of packets.
+
+For simplicity of implementation, there is no windowing of multiple
+unacknowledged packets in this version of the protocol. The host will continue
+to send the same packet until a response is received. Windowing functionality
+may be implemented in future versions if necessary to increase performance.
+
+The first Query packet will only be attempted a small number of times, but
+subsequent packets will attempt to retransmit for at least 1 minute before
+giving up. This means a device may safely ignore host UDP packets for up to 1
+minute during long operations, e.g. writing to flash.
+
+-- Continuation Packets --
+Any packet may set the continuation flag to indicate that the data is
+incomplete. Large data such as downloading an image may require many
+continuation packets. The receiver should respond to a continuation packet with
+an empty packet to acknowledge receipt. See examples below.
+
+-- Summary --
+The host starts with a Query packet, then an Initialization packet, after
+which only Fastboot packets are sent. Fastboot packets may contain data from
+the host for writes, or from the device for reads, but not both.
+
+Given a next expected sequence number S and a received packet P, the device
+behavior should be:
+ if P is a Query packet:
+ * respond with a Query packet with S in the data field
+ else if P has sequence == S:
+ * process P and take any required action
+ * create a response packet R with the same ID and sequence as P, containing
+ any response data required.
+ * transmit R and save it in case of re-transmission
+ * increment S
+ else if P has sequence == S - 1:
+ * re-transmit the saved response packet R from above
+ else:
+ * ignore the packet
+
+-- Examples --
+In the examples below, S indicates the starting client sequence number.
+
+Host Client
+======================================================================
+[Initialization, S = 0x55AA]
+[Host: version 1, 2048-byte packets. Client: version 2, 1024-byte packets.]
+[Resulting values to use: version = 1, max packet size = 1024]
+ID Flag SeqH SeqL Data ID Flag SeqH SeqL Data
+----------------------------------------------------------------------
+0x01 0x00 0x00 0x00
+ 0x01 0x00 0x00 0x00 0x55 0xAA
+0x02 0x00 0x55 0xAA 0x00 0x01 0x08 0x00
+ 0x02 0x00 0x55 0xAA 0x00 0x02 0x04 0x00
+
+----------------------------------------------------------------------
+[fastboot "getvar" commands, S = 0x0001]
+ID Flags SeqH SeqL Data ID Flags SeqH SeqL Data
+----------------------------------------------------------------------
+0x03 0x00 0x00 0x01 getvar:version
+ 0x03 0x00 0x00 0x01
+0x03 0x00 0x00 0x02
+ 0x03 0x00 0x00 0x02 OKAY0.4
+0x03 0x00 0x00 0x03 getvar:foo
+ 0x03 0x00 0x00 0x03
+0x03 0x00 0x00 0x04
+ 0x03 0x00 0x00 0x04 OKAY
+
+----------------------------------------------------------------------
+[fastboot "INFO" responses, S = 0x0000]
+ID Flags SeqH SeqL Data ID Flags SeqH SeqL Data
+----------------------------------------------------------------------
+0x03 0x00 0x00 0x00 <command>
+ 0x03 0x00 0x00 0x00
+0x03 0x00 0x00 0x01
+ 0x03 0x00 0x00 0x01 INFOWait1
+0x03 0x00 0x00 0x02
+ 0x03 0x00 0x00 0x02 INFOWait2
+0x03 0x00 0x00 0x03
+ 0x03 0x00 0x00 0x03 OKAY
+
+----------------------------------------------------------------------
+[Chunking 2100 bytes of data, max packet size = 1024, S = 0xFFFF]
+ID Flag SeqH SeqL Data ID Flag SeqH SeqL Data
+----------------------------------------------------------------------
+0x03 0x00 0xFF 0xFF download:0000834
+ 0x03 0x00 0xFF 0xFF
+0x03 0x00 0x00 0x00
+ 0x03 0x00 0x00 0x00 DATA0000834
+0x03 0x01 0x00 0x01 <1020 bytes>
+ 0x03 0x00 0x00 0x01
+0x03 0x01 0x00 0x02 <1020 bytes>
+ 0x03 0x00 0x00 0x02
+0x03 0x00 0x00 0x03 <60 bytes>
+ 0x03 0x00 0x00 0x03
+0x03 0x00 0x00 0x04
+ 0x03 0x00 0x00 0x04 OKAY
+
+----------------------------------------------------------------------
+[Unknown ID error, S = 0x0000]
+ID Flags SeqH SeqL Data ID Flags SeqH SeqL Data
+----------------------------------------------------------------------
+0x10 0x00 0x00 0x00
+ 0x00 0x00 0x00 0x00 <error message>
+
+----------------------------------------------------------------------
+[Host packet loss and retransmission, S = 0x0000]
+ID Flags SeqH SeqL Data ID Flags SeqH SeqL Data
+----------------------------------------------------------------------
+0x03 0x00 0x00 0x00 getvar:version [lost]
+0x03 0x00 0x00 0x00 getvar:version [lost]
+0x03 0x00 0x00 0x00 getvar:version
+ 0x03 0x00 0x00 0x00
+0x03 0x00 0x00 0x01
+ 0x03 0x00 0x00 0x01 OKAY0.4
+
+----------------------------------------------------------------------
+[Client packet loss and retransmission, S = 0x0000]
+ID Flags SeqH SeqL Data ID Flags SeqH SeqL Data
+----------------------------------------------------------------------
+0x03 0x00 0x00 0x00 getvar:version
+ 0x03 0x00 0x00 0x00 [lost]
+0x03 0x00 0x00 0x00 getvar:version
+ 0x03 0x00 0x00 0x00 [lost]
+0x03 0x00 0x00 0x00 getvar:version
+ 0x03 0x00 0x00 0x00
+0x03 0x00 0x00 0x01
+ 0x03 0x00 0x00 0x01 OKAY0.4
+
+----------------------------------------------------------------------
+[Host packet delayed, S = 0x0000]
+ID Flags SeqH SeqL Data ID Flags SeqH SeqL Data
+----------------------------------------------------------------------
+0x03 0x00 0x00 0x00 getvar:version [delayed]
+0x03 0x00 0x00 0x00 getvar:version
+ 0x03 0x00 0x00 0x00
+0x03 0x00 0x00 0x01
+ 0x03 0x00 0x00 0x01 OKAY0.4
+0x03 0x00 0x00 0x00 getvar:version [arrives late with old seq#, is ignored]