# Uavcan gui tool over ethernet ip/udp **URL:** \ **Category:** Applications & Usage\ **Created:** [November 13, 2020, 3:20pm UTC](https://forum.opencyphal.org/t/uavcan-gui-tool-over-ethernet-ip-udp/996 "2020-11-13T15:20:52Z")\ **Posts on this page:** 1\ **Showing post:** 2
**Author:** ![pavel.kirienko](https://forum.opencyphal.org/user_avatar/forum.opencyphal.org/pavel.kirienko/32/9_2.png) [@pavel.kirienko](https://forum.opencyphal.org/u/pavel.kirienko)\ **Post date:** [November 13, 2020, 4:48pm UTC](https://forum.opencyphal.org/t/uavcan-gui-tool-over-ethernet-ip-udp/996/2 "2020-11-13T16:48:49Z")
1. No. 2. I am not aware of any. 3. I wouldn’t do it this way because SLCAN is more of a quick hack rather than a proper protocol. It is highly inefficient, does not support CAN FD, designed for unframed low-level byte-oriented links, and there is no single commonly supported standard – vendor-to-vendor variability is huge. My educated (and biased, admittedly) opinion is that UAVCAN/UDP is much better suited for the task of transferring CAN frames (or any other real-time data, for that matter) over a UDP/IP network. Just make a pair of publishers/subscribers on either end of the link and exchange messages of type [**`uavcan.metatransport.can.Frame`**](https://github.com/UAVCAN/public_regulated_data_types/blob/master/uavcan/metatransport/can/Frame.0.1.uavcan) between them. There is also a full-featured exploratory CAN adapter control interface defined but it is more of a network service design excercise than a production-ready solution because it was never deployed in any practical application: [On CAN adapters and stateless interfaces](https://forum.opencyphal.org/t/on-can-adapters-and-stateless-interfaces/613) If you decided to go this way, you can use PyUAVCAN on the host side and a somewhat modified Libcanard (or a trivial custom implementation) on the device side. _Edit: added an elaboration about libcanard_ --- _[View the full topic](https://forum.opencyphal.org/t/uavcan-gui-tool-over-ethernet-ip-udp/996)._