It look like data loss possible when data transfer.

[IhorNehrutsa]

According to the https://man7.org/linux/man-pages/man2/write.2.html

Note that a successful write() may transfer fewer than count bytes.

These fix it https://github.com/IhorNehrutsa/tncattach/blob/c9685738625570af1b54b8c047b0b1d60f8b4f73/KISS.c#L23-L32 https://github.com/IhorNehrutsa/tncattach/blob/c9685738625570af1b54b8c047b0b1d60f8b4f73/KISS.c#L86-L96

[markqvist]

You are right! For network and tty devices I think this will only happen if the kernels buffers for the file descriptor are full or the fd becomes unavailable, but I am not sure. At least, in many thousand hours of operation, I have not have this occur without the actual device becoming unavailable. Either way, your solution is better. Thanks for the pull request.

Out of curiosity, did you experience this happening while the device(s) where still attached/available, or was it more a precautionary change?

Also, did you test these changes on actual hardware for at least some time to verify it?

Thanks again

[IhorNehrutsa]

I have two CP2102 USB-TTL converters cross-connected as null modem RXD1<-TXD2, TXD1->RXD2 https://www.aliexpress.com/item/4000761083018.html

pc@ubuntu:~/tncattach$ 
pc@ubuntu:~/tncattach$ sudo tncattach /dev/ttyUSB0 115200 --ethernet --mtu 576 --noipv6 --ipv4 192.168.193.10/24 -d
TNC interface configured as tnc0
pc@ubuntu:~/tncattach$ sudo tncattach /dev/ttyUSB1 115200 --ethernet --mtu 576 --noipv6 --ipv4 192.168.193.11/24 -d
TNC interface configured as tnc1
pc@ubuntu:~/tncattach$ 

ifconfig is:

pc@ubuntu:~/tncattach$ ifconfig
ens33: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        inet 192.168.193.128  netmask 255.255.255.0  broadcast 192.168.193.255
        inet6 fe80::ef2d:e13d:12a9:7956  prefixlen 64  scopeid 0x20<link>
        ether 00:0c:29:2b:5f:d1  txqueuelen 1000  (Ethernet)
        RX packets 4639393  bytes 5202216614 (5.2 GB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 2139503  bytes 232942921 (232.9 MB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

lo: flags=73<UP,LOOPBACK,RUNNING>  mtu 65536
        inet 127.0.0.1  netmask 255.0.0.0
        inet6 ::1  prefixlen 128  scopeid 0x10<host>
        loop  txqueuelen 1000  (Local Loopback)
        RX packets 809055  bytes 87325720 (87.3 MB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 809055  bytes 87325720 (87.3 MB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

tnc0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 576
        inet 192.168.193.10  netmask 255.255.255.0  broadcast 192.168.193.255
        ether 7a:ba:44:1c:61:19  txqueuelen 10  (Ethernet)
        RX packets 2215  bytes 430788 (430.7 KB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 11850  bytes 921657 (921.6 KB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

tnc1: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 576
        inet 192.168.193.11  netmask 255.255.255.0  broadcast 192.168.193.255
        ether be:2f:bb:0a:9c:24  txqueuelen 10  (Ethernet)
        RX packets 11820  bytes 916886 (916.8 KB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 2215  bytes 430788 (430.7 KB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

pc@ubuntu:~/tncattach$ 

Then start ping in two terminals :

pc@ubuntu:~$ ping -I 192.168.193.11 192.168.193.10

pc@ubuntu:~$ ping -I 192.168.193.10 192.168.193.11

[IhorNehrutsa]

Also I have two E32-433T30D (SX1278 433MHz 1W DIP Wireless Module) https://www.cdebyte.com/product_serch/E32-433T30D/1/

I want to make an aerial radio bridge Ubuntu <-> CP2102 USB-TTL <-> E32-433T30D <- ~~~ -> E32-433T30D <-> CP2102 USB-TTL <-> Ubuntu

[markqvist]

Looking at the screenshots, right now no traffic is passed to the serial adapters. Actually, no data will even reach tncattach. Since both interfaces are on the same machine, the kernel just passes packets between them directly in-kernel. Did you also try on separate machines/VMs? You should be able to verify the data is passed to the serial adapters by checking the TX/RX LEDs on the boards.

[markqvist]

I don', know what kind of firmware those devices are running, but I know that a lot of those UART-to-LoRa converters ar pretty "dumb", in that they don't even have proper listen-before-talk or multiple-access schemes implemented. If that is the case with these modules, you will have a lot of trouble running IPv4/IPv6 over them, since the amount of packet collisions will be way too high. But you can always try and see how well they do. If it fails, I would suggest using an RNode in TNC mode instead, which is verified to work well with IP over LoRa.