Tunneling CAN over 10BASE-T1S
Single Pair Ethernet, especially 10BASE-T1S, is often considered a potential successor to—or complement for—CAN. A practical first step does not require a complete system redesign: CAN frames can be tunnelled over Ethernet between two existing CAN segments.
In this demonstrator, 10BASE-T1S provides only the Ethernet transport path. The same tunnel can also run over Wi-Fi, fibre Ethernet, 10BASE-TX, or 10BASE-T1L.
Why tunnel CAN over Ethernet?
This approach is not a replacement for a continuous CAN bus. It is a tool for deliberately connecting CAN and Ethernet within an existing system:
- A product that uses CAN does not initially need a hardware or software change.
- 10BASE-T1S can be inserted between two CAN segments to investigate cable length, topology, and Ethernet transport behaviour.
- A network can migrate from CAN to T1S step by step instead of replacing everything at once.
- Existing CAN components and new T1S components can be coupled.
The CAN application remains unchanged at both ends. Only the transport path between the tunnel endpoints changes.
Test setup

Pi 2 and Pi 3 are the actual CAN endpoints. They send and receive frames through can0.
Pi 1 and Pi 5 only form the tunnel endpoints. Each one connects a local CAN interface to beiis-t1s0. A 10BASE-T1S network runs between them, using 10.10.10.2 and 10.10.10.1.
Logically, Pi 2 and Pi 3 communicate directly. Pi 1 and Pi 5 are not CAN participants in the application. A complete CAN bus with multiple participants can be connected in place of either Pi 2 or Pi 3.
Important: the tunnel transports CAN frames, but it does not extend CAN arbitration across Ethernet. It is therefore suited to demonstrations, laboratory setups, and prototypes—not as a replacement for a continuous, real-time-critical CAN segment.
Preparing the setup
CAN and T1S must be available as Linux network interfaces on Pi 1 and Pi 5. First, assign the T1S transport network:
# Pi 1
$ sudo ip addr replace 10.10.10.2/24 dev beiis-t1s0
$ sudo ip link set beiis-t1s0 up
# Pi 5
$ sudo ip addr replace 10.10.10.1/24 dev beiis-t1s0
$ sudo ip link set beiis-t1s0 up
Then enable the local CAN interfaces. The setup shown here was tested up to a 1 Mbit/s CAN bit rate.
$ sudo ip link set beiis-can0 down
$ sudo ip link set beiis-can0 type can bitrate 1000000
$ sudo ip link set beiis-can0 up
The example sources use Python and SocketCAN:
$ sudo apt update
$ sudo apt install -y git python3 python3-pip
$ python3 -m pip install --user python-can
$ git clone https://github.com/philippbrechel/be-iis-sw.git
$ cd be-iis-sw
The Python tunnel reads frames from beiis-can0, sends them over UDP through beiis-t1s0, and writes them back to the local CAN interface at the other end. The code remains independent of the Ethernet PHY: T1S can later be replaced with T1L, Wi-Fi, or standard Ethernet.
Functional test: The Sorcerer’s Apprentice on the CAN bus
For the test, Pi 2 sends text as a sequence of CAN frames. On Pi 3, candump shows that the bytes arrive from the remote CAN segment:
$ candump -a can0,700:7FFFF
can0 700 [8] 48 61 74 20 64 65 72 20 'Hat der '
can0 700 [8] 61 6C 74 65 20 48 65 78 'alte Hex'
can0 700 [8] 65 6E 6D 65 69 73 74 65 'enmeiste'
can0 700 [8] 72 0A 53 69 63 68 20 64 'r.Sich d'
can0 700 [8] 6F 63 68 20 65 69 6E 6D 'och einm'
can0 700 [8] 61 6C 20 77 65 67 62 65 'al wegbe'
can0 700 [8] 67 65 62 65 6E 21 0A 'gegeben!.'

The “old sorcerer” does not arrive through a continuous CAN wire, but through an Ethernet tunnel over 10BASE-T1S—and reaches the destination bus again as ordinary CAN communication.
Conclusion
The stackable BE-IIS-HPP platform is a good basis for quickly building such gateways: a CAN HAT for the local segment and an Ethernet HAT for the transport path. This demo shows how T1S tunnelling can be integrated into existing CAN architectures without immediately rebuilding the products at the CAN endpoints.
As an alternative to the T1S HAT, the BE-IIS-HPP-T1L can be used for 10BASE-T1L. The tunnel logic stays the same; only the Linux network-interface name and IP configuration need to be adjusted. The BE-IIS-HPP-LAN is another Ethernet option for other physical transport paths.
This is a tested demonstrator, not a production-ready serial gateway. All sources are open and intentionally compact. This makes behaviour and faults easy to understand; AI tools can additionally help review and improve the small Python components quickly.
Products and tools
- BE-IIS-HPP-T1S
- BE-IIS-HPP-CAN
- Alternative Ethernet HATs: BE-IIS-HPP-T1L and BE-IIS-HPP-LAN
- Tool: HAT Stack Builder
- Open sources: BE-IIS Software Repository