+/*
+ * Communicate to the Devantech ETH008 relay card via TCP and Ethernet.
+ *
+ * See http://www.robot-electronics.co.uk/files/eth008b.pdf for device
+ * capabilities and a protocol discussion.
+ * See https://github.com/devantech/devantech_eth_python for Python
+ * source code which is maintained by the vendor.
+ *
+ * The device provides several means of communication: HTTP requests
+ * (as well as an interactive web form). Raw TCP communication with
+ * binary requests and responses. Text requests and responses over
+ * TCP sockets. Some of these depend on the firmware version. Version
+ * checks before command transmission is essentially non-existent in
+ * this sigrok driver implementation. Binary transmission is preferred
+ * because it is assumed that this existed in all firmware versions.
+ * The firmware interestingly accepts concurrent network connections
+ * (up to five of them, all share the same password). Which means that
+ * the peripheral's state can change even while we control it.
+ *
+ * It's assumed that WLAN models differ from Ethernet devices in terms
+ * of their hardware, but TCP communication should not bother about the
+ * underlying physics, and WLAN cards can re-use model IDs and firmware
+ * implementations. Given sigrok's abstraction of the serial transport
+ * those cards could also be attached by means of COM ports.
+ *
+ * TCP communication seems to rely on network fragmentation and assumes
+ * that software stacks provide all of a request in a single receive
+ * call on the firmware side. Which works for local communication, but
+ * could become an issue when long distances and tunnels are involved.
+ * This sigrok driver also assumes complete reception within a single
+ * receive call. The short length of binary transmission helps here
+ * (the largest payloads has a length of three bytes).
+ *
+ * The lack of length specs as well as termination in the protocol
+ * (both binary as well as text variants over TCP sockets) results in
+ * the inability to synchronize to the firmware when connecting and
+ * after hiccups in an established connection. The fixed length of
+ * requests and responses for binary payloads helps a little bit,
+ * assuming that TCP connect is used to recover. The overhead of
+ * HTTP requests and responses is considered undesirable for this
+ * sigrok driver implementation. [This also means that a transport
+ * which lacks the concept of network frames cannot send passwords.]
+ * The binary transport appears to lack HELLO or NOP requests that
+ * could be used to synchronize. Firmware just would not respond to
+ * unsupported commands. Maybe a repeated sequence of identity reads
+ * combined with a read timeout could help synchronize, but only if
+ * the response is known because the model was identified before.
+ *
+ * The sigrok driver source code was phrased with the addition of more
+ * models in mind. Only few code paths require adjustment when similar
+ * variants of requests or responses are involved in the communication
+ * to relay cards that support between two and twenty channels. Chances
+ * are good, existing firmware is compatible across firmware versions,
+ * and even across hardware revisions (model upgrades). Firmware just
+ * happens to not respond to unknown requests.
+ *
+ * TODO
+ * - Add support for other models. Currently exclusively supports the
+ * ETH008-B model which was used during implementation of the driver.
+ * - Add support for password protection?
+ * - See command 0x79 to "login" (beware of the differing return value
+ * compared to other commands), command 0x7a to check if passwords
+ * are involved and whether the login needs refreshing, command 0x7b
+ * for immediate "logout" in contrast to expiration.
+ * - Alternatively consider switching to the "text protocol" in that
+ * use case, which can send an optional password in every request
+ * that controls relays (command 0x3a).
+ * - How to specify the password in applications and how to pass them
+ * to this driver is yet another issue that needs consideration.
+ */
+
+#include "config.h"
+
+#include <string.h>
+