drivers: net: cobs l2 network interface with async uart transport #101005

mkschreder · 2025-12-14T16:35:55Z

Summary

This PR adds a new way to run Zephyr IP networking over a simple TX/RX UART link using cobs for framing. Zephyr currently does not have a proper serial line network interface with multi instance support because the existing one uses uart pipe.

The interface I'm adding in this PR uses predictable overhead COBS framing that is much better than slip and I'm also adding this as an interface of which you can have many instances. This interface is primarily meant for reliable board to board networking and I'm also adding throughput samples for both UDP and TCP so you can test how this works.

NOTE: this is a big PR and still needs to be cleaned up. Also I'm still working on refactoring the samples and my goal is to make them bare yet robust. I also plan to update docs and describe in detail how this works.

A new COBS UART async network driver that exposes a standard Zephyr network interface over UART.
A small COBS-based framing layer for serial links so the UART link has clear packet boundaries.
New samples to make bring-up and evaluation easy:
- samples/net/cobs_uart_async (basic interface + net shell)
- samples/net/cobs_throughput_client / samples/net/cobs_throughput_server (UDP echo-based throughput/latency)
- samples/net/cobs_throughput_single and samples/net/cobs_throughput_tcp (single-board, cross-wired UART testing)
New tests covering both “bytes on the wire” and “sockets on top”:
- tests/drivers/cobs_uart_async_loopback
- tests/drivers/cobs_uart_async_sockets
Documentation + devicetree binding to make configuration straightforward.

Why this is useful

Reliable serial networking: enables IP connectivity on systems that only have a basic UART link available (TX/RX + GND), without requiring hardware flow control.
Easier evaluation and regression coverage: provides ready-to-run samples for throughput testing and adds automated tests to keep the full stack (driver → network stack → BSD sockets) working over time.
Cleaner framing behavior: COBS framing is both efficient and necessary in this case for packet based communication on a stream-based transport like UART.

What’s included (high level)

Driver: drivers/net/cobs_uart_async.c (+ Kconfig + build integration)
Serial framing support: new COBS Serial L2 + net_pkt COBS helper APIs
Devicetree: binding for declaring one or more COBS UART interfaces
Samples + tests: end-to-end examples and validation coverage for real hardware and simulation scenarios

Dependencies

lib: cobs: implement streaming cobs variant #101004: COBS library extensions.

Testing

Added unit test and a socket integration samples to validate end-to-end behavior over COBS framed packet link.

jukkar

Nice work! There is a lot of code and I will continue the review later, this was just a first glance of the PR.
Couple of thoughts about this:

It might be confusing if this is called SLIP as it typically means certain framing for the packets as seen in https://en.wikipedia.org/wiki/Serial_Line_Internet_Protocol. Should we mention the COBS there or something like that?
Would it be possible to create a Linux counter part of the protocol so that this could be used from qemu or even from native_sim? So similar way the SLIP can be used.

jukkar · 2025-12-14T18:33:08Z

include/zephyr/data/cobs.h

+ * Non-destructive: tracks read position without modifying source.
+ */
+struct cobs_encode_state {
+	struct net_buf *src_frag;   /* Current source fragment being read */


Doxygen requires /**< Current source fragment being read */ style comment in order it to generate the documentation properly.

I will update all comments to follow doxygen format

This will disappear once the cobs MR is merged.

jukkar · 2025-12-14T18:35:50Z

doc/connectivity/networking/api/cobs_uart_async.rst

+
+   /* Configure IP address */
+   struct in_addr addr;
+   net_addr_pton(AF_INET, "192.168.7.1", &addr);


Please use IP address range reserved for documentation, so here you could use 192.0.2.1 for example

Sure. I think I will update them to be ipv6 addresses though.

jukkar · 2025-12-14T18:39:51Z

drivers/net/slip_uart_async.c

+#define LOG_MODULE_NAME slip_uart_async
+#define LOG_LEVEL CONFIG_SLIP_UART_ASYNC_LOG_LEVEL
+
+#include <zephyr/logging/log.h>
+LOG_MODULE_REGISTER(LOG_MODULE_NAME);


Instead of this, you could just write

#include <zephyr/logging/log.h> LOG_MODULE_REGISTER(slip_uart_async, CONFIG_SLIP_UART_ASYNC_LOG_LEVEL);

which is the style we are mainly using in zephyr.

jukkar · 2025-12-14T18:43:03Z

drivers/net/slip_uart_async.c

+		scan_count++;
+		if (byte == COBS_DELIMITER) {
+			/* Start of frame */
+			LOG_INF("✓ Found COBS delimiter (0x00), starting frame (scanned %d bytes)", scan_count);


I am not sure if it is a good idea to print non ascii chars here, it does not give much benefit and might cause some garbage to be printed.
Also this looks like a debug print than an info message. Usually there is no need to print this kind of messages unless you are debugging things.

I think this is gone now.

jukkar · 2025-12-14T18:48:21Z

drivers/net/cobs_uart_async.c

+	/* Generate MAC address (00-00-5E-00-53-xx per RFC 7042) */
+	ctx->mac_addr[0] = 0x00;
+	ctx->mac_addr[1] = 0x00;
+	ctx->mac_addr[2] = 0x5E;
+	ctx->mac_addr[3] = 0x00;
+	ctx->mac_addr[4] = 0x53;
+	ctx->mac_addr[5] = sys_rand8_get();


I am not sure we should use this MAC address space here, the values specified in the RFC are meant for documentation but as this is a driver that might be used in real products, then this is perhaps not a good thing. Could we specify that mac address in DT?

jukkar · 2025-12-14T18:54:23Z

samples/net/cobs_throughput_client/src/main.c

+#ifndef CONFIG_SLIP_THROUGHPUT_PACKET_SIZE
+#define CONFIG_SLIP_THROUGHPUT_PACKET_SIZE 512
+#endif
+
+#ifndef CONFIG_SLIP_THROUGHPUT_SERVER_IP
+#define CONFIG_SLIP_THROUGHPUT_SERVER_IP "192.168.7.1"
+#endif
+
+#ifndef CONFIG_SLIP_THROUGHPUT_DURATION_SEC
+#define CONFIG_SLIP_THROUGHPUT_DURATION_SEC 60
+#endif


I don't recommend re-defining the config variables but do it like this instead

#if defined(CONFIG_SLIP_THROUGHPUT_PACKET_SIZE) #define SLIP_THROUGHPUT_PACKET_SIZE CONFIG_SLIP_THROUGHPUT_PACKET_SIZE #else #define SLIP_THROUGHPUT_PACKET_SIZE 512 #endif

Why the Kconfig variable would be undefined, why do we even need to check this?

jukkar · 2025-12-14T18:59:56Z

samples/net/cobs_throughput_client/src/main.c

+	/* Set receive timeout */
+	timeout.tv_sec = 1;
+	timeout.tv_usec = 0;
+	ret = zsock_setsockopt(sock, SOL_SOCKET, SO_RCVTIMEO, &timeout, sizeof(timeout));


Please check the code and do not mix POSIX and network namespaced symbols. We recently merged a PR that adds a prefix to various network symbols in order to avoid conflicts with POSIX.
So here use ZSOCK_SOL_SOCKET and ZSOCK_SO_RCVTIMEO
If you want to check the usage of the correct APIs, you can set CONFIG_NET_NAMESPACE_COMPAT_MODE=n to disable the compatibility mode and make sure correct symbols are used.

These samples will be cleaned up as I mentioned in the note in PR description.

jukkar · 2025-12-14T19:02:04Z

samples/net/cobs_throughput_client/Kconfig

+
+source "Kconfig.zephyr"
+
+config SLIP_THROUGHPUT_PACKET_SIZE


We have been trying to namespace the network sample specific Kconfig symbols so that it is clear where they come from. So the symbols should be called

config NET_SAMPLE_SLIP_THROUGHPUT_PACKET_SIZE

etc

jukkar · 2025-12-14T19:03:10Z

samples/net/cobs_throughput_client/prj.conf

+
+# Packet size configuration (can be overridden)
+CONFIG_SLIP_THROUGHPUT_PACKET_SIZE=512
+CONFIG_SLIP_THROUGHPUT_SERVER_IP="192.168.7.1"


Please use the IP address space we use in the configs by default. So the address in this case should be 192.0.2.1
User can always change this in command line when compiling the application if needed.

jukkar · 2025-12-14T19:03:29Z

samples/net/cobs_throughput_client/README.rst

+- IPv6: fe80::2
+
+Default test parameters (can be overridden via Kconfig or shell):
+- Server IP: 192.168.7.1


Please change this

mkschreder · 2025-12-15T02:43:26Z

Nice work! There is a lot of code and I will continue the review later, this was just a first glance of the PR. Couple of thoughts about this:

It might be confusing if this is called SLIP as it typically means certain framing for the packets as seen in https://en.wikipedia.org/wiki/Serial_Line_Internet_Protocol. Should we mention the COBS there or something like that?

Would it be possible to create a Linux counter part of the protocol so that this could be used from qemu or even from native_sim? So similar way the SLIP can be used.

Renaming to cobs_uart_async! Thanks for the heads up!

Many transports deliver data in small, arbitrary chunks (for example, UART RX buffers). In these cases, treating COBS encoding/decoding as a single “whole buffer in / whole buffer out” operation is awkward. This paves the way for being able to add highly efficient cobs-based interfaces that operate on chunks instead of whole buffers. We avoid creating a new buffer just to hold incomplete frame and instead maintain state as we are receiving more data. Encoding is a bit more complex since cobs requires lookahead when encoding, but this is not a problem because we have access to full data when we encode so we can do lookahead when needed.

Add a new way to run Zephyr IP networking over a simple TX/RX UART link using cobs for framing. Zephyr currently does not have a proper serial line network interface with multi instance support because the existing one uses uart pipe.

sonarqubecloud · 2025-12-15T04:10:29Z

Quality Gate passed

Issues
6 New issues
0 Accepted issues

Measures
2 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud

zephyrbot added area: Networking area: Devicetree area: Devicetree Bindings area: Utilities area: Boards/SoCs area: Tests Issues related to a particular existing or missing test area: Samples Samples labels Dec 14, 2025

zephyrbot requested review from JarmouniA, andyross, dcpleung, decsny, jukkar, kartben, mbolivar, nashif, pdgendt, peter-mitsis, rlubos, rruuaanng and ssharks December 14, 2025 16:37

zephyrbot assigned rlubos and jukkar Dec 14, 2025

mkschreder force-pushed the feature/slip_cobs_uart_async branch 5 times, most recently from 2a72558 to b76e4ff Compare December 14, 2025 17:11

jukkar reviewed Dec 14, 2025

View reviewed changes

mkschreder force-pushed the feature/slip_cobs_uart_async branch 2 times, most recently from 577b850 to 19731e2 Compare December 15, 2025 02:18

mkschreder force-pushed the feature/slip_cobs_uart_async branch from 19731e2 to 1be77a0 Compare December 15, 2025 02:42

mkschreder changed the title ~~drivers: net: cobs slip l2 network interface with async uart transport~~ drivers: net: cobs l2 network interface with async uart transport Dec 15, 2025

mkschreder force-pushed the feature/slip_cobs_uart_async branch from 1be77a0 to bb5dc74 Compare December 15, 2025 02:54

mkschreder force-pushed the feature/slip_cobs_uart_async branch 2 times, most recently from 7f655d4 to fc2aa0e Compare December 15, 2025 03:31

mkschreder force-pushed the feature/slip_cobs_uart_async branch 2 times, most recently from f94aa44 to 4cf9037 Compare December 15, 2025 03:42

mkschreder mentioned this pull request Dec 15, 2025

samples: cobs_uart_async: throughput and packet loss testing #101023

Open

drivers: net: cobs l2 network interface with async uart transport #101005

Are you sure you want to change the base?

drivers: net: cobs l2 network interface with async uart transport #101005

Conversation

mkschreder commented Dec 14, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Summary

Why this is useful

What’s included (high level)

Dependencies

Testing

Uh oh!

jukkar left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

jukkar Dec 14, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

mkschreder commented Dec 15, 2025

Uh oh!

sonarqubecloud bot commented Dec 15, 2025

Quality Gate passed

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

4 participants

mkschreder commented Dec 14, 2025 •

edited

Loading

jukkar Dec 14, 2025 •

edited

Loading