A socketCAN on TCP client/server
usage: tcpcan.py [-h] [--host HOST] [--port PORT] [--serve] [-v] canif
Tunnel SocketCAN on TCP.
positional arguments:
canif SocketCAN interface
optional arguments:
-h, --help show this help message and exit
--host HOST TCP host (default: localhost)
--port PORT TCP port (default: 20010)
--serve
-v, --verbose
tcpcan vcan0 --serve
tcpcan vcan0
This section describes the protocol used by tcpcan. Every message has a two byte header containing a prefix (1 byte) and a length (1 byte). The protocol is big endian if nothing else is stated. A connection always starts with a protocol version negotiation using the Protocol version message. No other messages than Protocol version messages must be sent before a version agreement has been met.
| --------------- | ----------------- | --------------------------------- |
| Prefix (1 byte) | Length N (1 byte) | Prefix specific payload (N bytes) |
| --------------- | ----------------- | --------------------------------- |
Prefix | Format | Description | Supported in version |
---|---|---|---|
v | I | Protocol version | 1 |
d | B* | SocketCAN data, 16 B (can_frame) or 72 B (canfd_frame) | 1 |
A client initiates the negotiation by proposing a protocol version it supports, typically its highest supported version. The server responds with either the same version number as an acknowledgement that an agreement has been met or it proposes a lower version number. If the version number is lowered the negotiation continue until an agreement is made. If the version reaches 0, no agreement could be made and the connection is terminated. A communicating party must not respond to a Protocol version message if it contains the same version number as the party itself has proposed earlier.