Slipmux: Using an UART interface for diagnostics, configuration, and packet transfer

Status of This Memo

This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.¶

Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.¶

Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."¶

This Internet-Draft will expire on 15 June 2026.¶

Copyright Notice

Copyright (c) 2025 IETF Trust and the persons identified as the document authors. All rights reserved.¶

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document.¶

Table of Contents

1. Introduction

Many research and maker hardware modules for Internet of Things experimentation ("platforms") offer a serial ("UART") interface. This is often used for programming, diagnostic output, as well as a crude command interface ("AT interface"). Alternatively, it is used with SLIP (RFC1055) to transfer IP packets only; this may require the use of another serial interface for diagnostics and configuration.¶

The present report describes how to use a single serial interface for diagnostics, configuration commands and state readback, as well as packet transfer.¶

2. Using a UART interface

The serial interfaces provided by today's platforms often do not actually use EIA-232 ("RS-232") levels, but some form of logic levels (TTL or more likely 3.3 V CMOS). The present report does not discuss physical interfacing, but assumes that a TXD (transmit data) pin, a RXD (receive data) pin, and a GND (common ground) pin are all that is available. To interface laptops and similar devices to these serial interfaces, inexpensive ($2) USB to UART adapters based on chips such as PL2303, CP2102 or CH340 are easily obtainable. (The usual care needs to be taken when mixing 3.3 V and 5 V platforms; this is well understood but beyond the scope of the present report.)¶

The general assumption is that a serial port configuration of 8N1 (8 bits per character, no parity, 1 stop bit) and a bit rate of 115200 bit/s is used. As with the logic levels, alternative arrangements are possible, but a 3.3 V CMOS, 115200 bit/s interface is most likely to provide the best interoperability.¶

While it would be possible to run relatively complex and versatile protocols such as PPP [RFC1661] on such serial interfaces, this goes against a need for simplicity and ease of setup. In today's systems, either weird ad-hoc protocols based on "AT commands" are used that are not interoperable at all, or a simple encapsulation such as SLIP [RFC1055] is used for packet transfer only.¶

For the purposes of the present report, on top of the serial UART protocol, the frame format defined by [RFC1055] is indeed employed. The detailed descriptions below generally describe the frame data before applying SLIP escaping in the transmitter or after removing it in the receiver.¶

The approach described here is informally referred to as "slipmux".¶

3. Packet Transfer

Packet transfer uses the definitions of [RFC1055]. However, contrary to the statement in section DEFICIENCIES of [RFC1055], multiplexing is very well possible. A frame used for packet transfer is detected by an initial byte of one of the two forms:¶

• 0x45 to 0x4f: IPv4 packet¶

• 0x60 to 0x6f: IPv6 packet¶

This initial byte forms part of the packet; it is not removed from the payload as with the other formats defined below.¶

There are no changes to the formats defined by [RFC1055], so there should be immediate interoperability with tools such as tunslip.¶

4. Diagnostics Transfer

While not transferring a frame bearing a packet, the platform can alternatively transmit a diagnostic frame. These are encoded (and escaped) using SLIP framing exactly like packet frames, but start with the byte 0x0a (ASCII newline) and contain UTF-8 encoded characters after that byte. There is no semantics attached to the diagnostics message, except that it is intended as a human-readable debug or diagnostic message from the platform code. It is generally preferable to end the payload of a diagnostics message in another newline (0x0a, which on the wire is then followed by 0xc0 due to the SLIP framing). Note that, as long as only ASCII characters are used, there is no need to actually perform escaping on the diagnostic message.¶

Since diagnostic messages are intended for humans, they are only defined for the direction from platform to host (e.g., laptop); for robustness when connecting two platform modules, they should be ignored by platform modules.¶

5. Configuration

Configuration is performed by sending CoAP messages [RFC7252] in SLIP framing. The encapsulation of a CoAP message starts with an additional byte 0xA9, with the bytes of the CoAP message following (which, as for all data in frames, are escaped as necessary as per [RFC1055]).¶

In contrast to the packet and diagnostics frames defined above, CoAP frames benefit from a frame check mechanism. After the CoAP message, the last two bytes of a CoAP frame therefore contain a 16-bit CRC FCS computed over the byte 0xA9 followed by the (unescaped) bytes of the CoAP message, computed as specified in [RFC1662]. (Note that the two bytes of the CRC are escaped, as necessary, by the SLIP framing, as are all other bytes of the CoAP message.)¶

CoAP messages with incorrect CRCs are silently discarded.¶

Where a local URI needs to be formed for the configuration messages, the URI scheme "coap+uart" is used; the authority part of that URI might be used to refer to local interface names as needed, as in:¶

coap+uart://ttyUSB0/APlist

The client could also be using a local mapping table to provide some indirection in translating the authority part to a local identifier of the serial port(e.g., COM0 to ttyUSB0).¶

Using an empty URI authority allows the client to use a default port, as in:¶

coap+uart:///APlist

A later version of this report might define some common CoAP resources that research or maker platforms might want to provide, e.g. to cover the configuration and status checking often done by "AT commands" today.¶

6. Framing considerations

To make SLIP framing robust, it is important to send SLIP frame delimiters (0xc0) before and after each SLIP frame (maybe unless frames follow each other back to back). This means that empty frames need to be silently ignored by a receiver.¶

If a platform starts to send a packet or message, but then decides it should not complete the message before having sent the rest of the frame, it can send the SLIP ESC (0xdb) followed by SLIP END (0xc0) to abort the frame. Note that this goes beyond the error handling suggested by the section "SLIP DRIVERS" in [RFC1055] and might therefore be of limited interoperability at first.¶

Messages in slipmux are strictly sequential; there is no [RFC2687] style suspension. In particular, this means that diagnostic messages that are generated while another message is in progress may have to be buffered (unless they are important enough to abort the frame as described above).¶

7. Discussion

8. IANA Considerations

The present report does not foresee adding additional frame types, but as a matter of precaution, this section might define a registry for initial bytes in a frame. At this point, this would contain:¶

• 0x0a: Diagnostics¶

• 0x45 to 0x4f: IPv4 packet¶

• 0x60 to 0x6f: IPv6 packet¶

• 0xA9: CoAP message with 16-bit FCS¶

If such a registry is desired, the following values for initial bytes should probably be reserved (while all these values could be used if required, implementation is easier if they are not):¶

• 0x00¶

• 0xc0: [RFC1055] END¶

• 0xdb: [RFC1055] ESC¶

There might also be a need to formally register the URI scheme "coap+uart".¶

9. Security Considerations

The usual security considerations apply to the IP packets transferred in packet frames.¶

When displaying information from diagnostic frames, care should be taken that features of a terminal triggered e.g. by escape sequences cannot be used for nefarious purposes.¶

The CoAP configuration interface does not itself provide any security. This may be appropriate for the local configuration needs of an experimentation platform that is not expected to be physically connected to any system that is not allowed full control over it (e.g., by using the same physical interface for reflashing new firmware). Where the platform might connect to other systems over serial, object security for CoAP [RFC8613] might be employed, or the configuration interface might be restricted to a read-only mode only providing information that does not need confidentiality protection. (It would be possible to provide a DTLS encapsulation, but this might go beyond the objective of extreme simplicity.)¶

10. References

Appendix A. Implementation Status

This section is to be removed before publishing as an RFC.¶

(The following boilerplate is excerpted from Section 2.1 of [RFC7942] (BCP205). That RFC does not consider implementation status sections in IRTF Internet-drafts, so the reader is requested to perform the necessary cognitive transfer.)¶

This section records the status of known implementations of the protocol defined by this specification at the time of posting of this Internet-Draft, and is based on a proposal described in [RFC7942]. The description of implementations in this section is intended to assist the IETF in its decision processes in progressing drafts to RFCs. Please note that the listing of any individual implementation here does not imply endorsement by the IETF. Furthermore, no effort has been spent to verify the information presented here that was supplied by IETF contributors. This is not intended as, and must not be construed to be, a catalog of available implementations or their features. Readers are advised to note that other implementations may exist.¶

According to [RFC7942], "this will allow reviewers and working groups to assign due consideration to documents that have the benefit of running code, which may serve as evidence of valuable experimentation and feedback that have made the implemented protocols more mature. It is up to the individual working groups to use this information as they see fit".¶

https://github.com/Lobaro/slip
https://github.com/Lobaro/util-slip

Acknowledgements

TBD¶

Authors' Addresses