IP over CAN ISO-TP multi-host
Closed this issue · 2 comments
Hi,
sorry for writing here, but I could not find any other directed channel for this.
I am searching for an alternative to 100Mbps Ethernet for some low bandwidth IoT application (<20, maybe max 40 devices on a single bus, few meters distance), peak below 1Mbps (with optimization I can make it 1/10 of that) needed. It is a hobby project, so some non-standard solutions are very much an option here.
I am considering CAN, because of simplified cabling, and not requiring a switch. So it should be easier on hardware side compared to Ethernet.
I would like to use IP (IPv6 optionally too) tho. (I know that IP + TCP/UDP headers will eat a lot, but for my use case it is fine).
I noticed few experimental IETF drafts, and articles, but nothing concrete.
Then I found this project, with its isotptun proof of concept.
Looks promising, but as I understand it, it is point-to-point, requires a bit of manual configuration and between two Linux hosts only.
Few questions:
-
Would it be possible to extend it to be multi-host, i.e. make each host add a network, not just other host. So, i.e. each host only needs to add one tuntap interface, and be able to communicate with all other devices.
-
Would it be possible to have things like ARP, DHCP, broadcast, or something similar, to allow more automatic configuration of IPv4 / IPv6?
-
Is it be possible to implement TCP/IP stack on non-Linux devices to be compatible with the
iotptun(I presume there is some framing, fragmentation protocol to follow, etc). Things like ESP32, Arduino, (I should have plenty of memory to this, but I have no idea about hardware side to implement ISO-TP), etc. Some of them do have built-in CAN FD controller, so I only need a small transceiver to interface. Most of them tho only support CAN (no CAN FD), at up to 1Mbps, with about 64 bytes of receive FIFO, and support for standard (11-bit ID) and extended frame format (29-bit ID). There are now some RISC-V boards (with about 64MB of memory), that are cheap and could run real Linux (after trimming it a lot of course), but it is likely such system will use more power and be a little bit unsuitable for real time operations.
Hi,
Looks promising, but as I understand it, it is point-to-point, requires a bit of manual configuration and between two Linux hosts only.
Yes. The usual communication paradigm for isotp is to create a point-to-point communication using two different CAN identifiers. The sender is sending single frame (SF) or first frame (FF) and the receiver announces its ability to receive and control the segmented transfer using the flow control (FC) frame. That's why you need two different CAN IDs for the two hosts/directions.
As you have lots of CAN IDs you can establish lots of point-to-point isotp channels - which is a bit like duplex UDP (without IP addresses). Maybe this is already what you need to let the IoT systems to talk to each other?!?
Now the question "is it possible to implement 1:n communication instead of 1:1" ?
The Linux kernel implements a special communication mode that does not wait for the FC frame but sends the entire PDU directly (set the CAN_ISOTP_CF_BROADCAST flag) - btw. this feature is not part of the ISO15765-2 standard. On the receiving side you can assemble isotp PDUs without sending FC frames by setting the CAN_ISOTP_LISTEN_MODE flag.
Of course this means, that the sender is not waiting for the receiver indicating that he's ready to receive data. I have no idea if this really reduces the reliability. But at least this is a possibility for 1:n communication which you might use for multicast with or without IP addressing.
1. Would it be possible to extend it to be multi-host, i.e. make each host add a network, not just other host. So, i.e. each host only needs to add one tuntap interface, and be able to communicate with all other devices.
As written above you can implement 1:1 and 1:n isotp channels. The endpoint is a Linux network socket that you can use with tuntap.
2. Would it be possible to have things like ARP, DHCP, broadcast, or something similar, to allow more automatic configuration of IPv4 / IPv6?
If you use the 1:n paradigm from above you might use the isotp PDUs similar to an Ethernet frame.
But depending on your IoT use case you can also think about some "CAN ID DHCP" to sort out communication relations (aka CAN IDs) between the IoT devices without IP mechanisms.
3. Is it be possible to implement TCP/IP stack on non-Linux devices to be compatible with the `iotptun` (I presume there is some framing, fragmentation protocol to follow, etc). Things like ESP32, Arduino, (I should have plenty of memory to this, but I have no idea about hardware side to implement ISO-TP), etc. Some of them do have built-in CAN FD controller, so I only need a small transceiver to interface. Most of them tho only support CAN (no CAN FD), at up to 1Mbps, with about 64 bytes of receive FIFO, and support for standard (11-bit ID) and extended frame format (29-bit ID). There are now some RISC-V boards (with about 64MB of memory), that are cheap and could run real Linux (after trimming it a lot of course), but it is likely such system will use more power and be a little bit unsuitable for real time operations.
isotp is comparably simple to implement on SoCs that have a CAN(FD) controller on board. You can use the Linux kernel code as reference or python_isotp or other stuff out there. The only thing is that you might need to reserve more memory if you need more instances/endpoints for isotp communication. In Linux these buffers are automatically allocated for every CAN network socket.
When you have the re-assembled isotp PDU this data is sent into the IP stack for further processing. This is what isotptun is doing. If you have an IP stack on your device you can pass the data analogue to an Ethernet frame.
IMHO I would ask myself whether it makes sense to run the IoT communication on "bare isotp" 1:1/1:n communication or if it makes sense to put IPv4/IPv6 addressing on top of it.
I decided to explore 10BASE-T1S instead, multidrop, short range, good speed, can integrated into existing ETH MACs with small PHY chip, etc.
If that does not pan out, will consider CAN ISO-TP again, but probably not, as 10BASE-T1S (with TCP) is essentially successor of CAN in some areas.
Thanks for elaboration.