rns.recipes

This computer doesn’t have an IP connection so the only way I can connect to a reticulum network is via LoRa, which makes it a bit annoying to do things that require sending larger amounts of data, like updating reticulum, since I would have to change the LoRa settings to prioritise speed rather than range whenever I need to do something like that.

Ever since I got the Heltec V4s my old V3s have been laying and collecting dust. So I figured, they have wi-fi radios, I like to code and since my brother got me that book about C last year I’ve learnt some of the basics of it so why not take this opportunity to learn how to write firmware for ESP32s and repurpose my V3s. I managed to get them to transmit and receive packets over wi-fi, so now I need to make them communicate with reticulum so they can actually be used as an 802.11 interface. I would write an interface driver but I don’t really know how to do that, I think I remember reading that that would require some kind of class, and I’m not entirely certain what a class even is (well in the context of programming at least) so that seems like a daunting task. Then there’s the pipe interface, but that still requires me to figure out how to communicate over serial, and I don’t really feel like doing that right now. Maybe I’ll do it eventually, if I have to.

For now I figured, the serial interface can already communicate over serial, and as far as I know it just uses a specific byte to separate packets from each other, and then somehow avoids that byte appearing in packets and being confused for a packet delimiter (I don’t know how exactly, just that it does it).

So theoretically, all I need to do is store each byte being received over serial in an array, and when the packet delimiter (0x7E) is received I simply transmit the packet that is in the array, and then I clear the array, so it’s ready for more packets. And when I receive a packet over wi-fi I simply send it over serial followed by 0x7E. All I’m really doing is stripping the packet delimiter from the packet and transmitting it, then adding the delimiter back in at the other end, so the other reticulum instance should receive the exact same packet that the first one sent. And from what I can tell that seems to be exactly what is happening. I plug my Heltec into my computer and look at the serial monitor in the Arduino ide and I can see the path requests and announces coming through, followed by 0x7E.

And yet for some reason when I try to get 2 reticulum instances to communicate like this, they both report receiving 0 bytes on the serial interfaces. So does anyone know if there is some flaw in trying to communicate with the serial interface this way or if I just implemented it badly and the packets actually are being changed somehow?

I got a serial monitor program called tio that can output the exact bytes received on the usb port, from the esp32. The following is a path request for this forum:
7e 08 00 6b 9f 66 01 4d 98 53 fa ab 22 0f ba 47 d0 27 61 00 9c e9 28 08 be 49 8e 9e 05 59 0f f2 7c bf df e4 61 61 20 d6 52 bc 56 d5 7f 78 a8 6b 36 40 65 93 7e

As it seems the packet was successfully received over wifi and sent over serial I’m wondering, is this packet somehow invalid or is reticulum not receiving the packets coming in on the port? Could the interface be misconfigured? This is how the interface is currently configured:
[[ESP32 802.11 Interface]]
type = SerialInterface
enabled = yes
port = /dev/ttyUSB0
mode = gateway

Should an interface configured like this ignore that packet or is this some kind of bug or?

Update: It seems to work with the following configuration:
[[Serial Interface]]
type = SerialInterface
enabled = yes
port = /dev/ttyUSB0
speed = 115200
databits = 8
parity = none
stopbits = 1

The packet loss is pretty high though. I measured it with “rnprobe -v -n 512” and it reported a packet loss of 53.71%, with most packets having a round trip return time of 80 - 200ms, and I think I remember seeing a packet with a time of 500ms once or twice. After further testing it seems most of the packets from my MacBook do reach the raspberry pi, but a lot of packets travelling in the opposite direction, from the raspberry pi to the MacBook, are lost. I tried switching the esp32s, so the MacBook was using the esp32 that the raspberry pi had been using, and vice versa, to see if it would affect this partial unidirectionality somewhat. It did not, most packets from the raspberry pi were still lost, and most packets from the MacBook weren’t. I have no idea what could be causing all this packet loss and partial unidirectionality, so not sure I’m going to be able to do anything about it. Hopefully someone else here might have some idea