rns.recipes

So this is kind of a weird problem and I haven't been able to find any potential solutions through searching. I'll try to make the explanation concise. System 1: Linux, running rnsd, with an RNode connected via USB System 2: Linux, running MeshChatX, accessing Reticulum over the LAN Phone: Android, running Columba, with an RNode connected via BLE Using the phone, I can attach an image to a message in Columba and sent it to an identity on System 2 with MeshChatX. It takes a bit of course, but seems to work fine every time. But, using System 2, when I attach an image to a message to an identity on the Phone in Columba, it just hangs indefinitely unless the file is very, very small or extr emely compressible. This also seems to impact the ability of the phone to request Nomadnet pages over LoRa, where they almost always fail. Both RNode interfaces are configured with the same values. I had the same problems regardless of what client was used on System 2 (between Nomadnet and MeshChatX) and regard less of the client on the phone (Sideband and Columba). The way it acts makes me think it's possibly MTU related, but it should be autoconfigured MTUs on both end and seems to be set to 508 by rnsd on System 1 and I don't know for sure what it is on the phone, but in Sideband it also showed 508. I guess that's determined by the target bitrate? Anyway, has anyone else experienced this or have an idea of what in the world is going on?

It's definitely MTU related. I tested with files filled with random bytes. 500 bytes up to 508 bytes works fine. Once the file is 509 bytes or larger, it hangs.

So, a bit more info. I think I've narrowed it down to BLE between Android and the RNode. I connected my RNode to my phone with USB and everything works perfectly. So there's a sort of solution at least, but it's not particularly convenient. Has anyone else experienced this?

Can you post the exact versions running on each system, RNS, client apps? Also exactly what RNode firmware variant and version, and what board it is using.

RNode interfaces always have MTU 508 regardless of bitrate, but the final bitrate your setup uses would be of use here as well. Check it with rnstatus if you don't know.

If any LXMF message doesn't fit in a single packet MDU, it would use a link and transfer it as a multi-part Resource instead. From what you describe, though, that would already happen for a 500 byte file, since the additional overhead of message signatures, et cetera, would already exceed the MDU.

For what it's worth, I have no problems here transferring large files (megabytes, if you have the patience) over for example: Sideband (BLE connected RNode) -> rnsd (WiFi connected RNode) -> Sideband (AutoInterface over Ethernet). So it should work fine without any issues.

It could be a bluetooth MTU issue, though - if the BLE handshake doesn't correctly configure the BLE MTU, that would potentially drop larger packets.

Sure thing! I'm not sure if I can get line breaks in here, but I'll try. Linux system: rns 1.5.7 connecting to a heltec v3 board running rnode firmware 1.8.6. The client was Nomadnet 1.4.4 Phone: Android 16 with Columba 2.3.1-beta (also tried with older versions) which I think uses the torlando-tech fork of rns and it shows version 1.4.2. With Sideband the ver sion is 2.2.0 which I think has either rns 1.5.5 or 1.5.7. The rnode connected to the phone is also a heltec v3 running 1.8.6 of the rnode firmware. The bitrate seems to be set to 3.16kbps everywhere. Both rnodes are configured with the same bandwidth, spreading factor, and coding rate. I feel like all of this worked fin e in the past, but there have been a lot of software updates over the past few months and I also got a newer phone, so I don't know exactly when the behavior changed or what caused the change.

Well, I guess line breaks don't work in MeshChatX. I switched back over to Nomadnet, where they do seem to work, although I had to register a different identity.

Anyway, I found a recent issue in Android about BLE and MTU issues. So it's possibly related and it seems it could be a recent regression. I do have a Motorola phone.

https://doc-4dl0-00-issuetracker.googleusercontent.com/issues/566451351

Oof, that's an annoying bug.

That looks very much like it would be the cause of it. Reticulum does request excatly a BLE MTU of 517 bytes when creating connections to an RNode. If this is not possible, communication will degrade or fail.

There might not be much else to do in your case than to wait for a fix or use a different device.

Another workaround, if you want to avoid the cabled connection, is to connect the RNode over WiFi instead. Configure the RNode to provide a WiFi access point, and sideband to connect to the RNode over WiFi, then you can connect over that instead.

PS: If you use Columba, use the builds only that ship with actual RNS. Don't use the experimental kotlin builds, Torlando has deprecated them as well.

Yeah, that's the conclusion I came to too, having to wait until there's a fix or trying to find another device. The WiFi method would be fine except I can't be connected to my home WiFi at the same time, and if I make the RNode a client of my home WiFi network I can't connect to it when I'm mobile. Hopefully Motorola or whomever has a fix in the works, but until then or I have a different device to use with it I'll probably just carry around a USB cable.

I did always make sure to use the Columba version with the python implementation of RNS, since I wasn't really confident the kotlin builds would work, but I do appreciate the advice, especially on Android where there's enough weirdness as it is. :)