liamcottle / reticulum-meshchat

A simple mesh network communications app powered by the Reticulum Network Stack.
https://meshchat.app
MIT License
149 stars 10 forks source link

USB serial interface malfunction #7

Open sisari opened 3 months ago

sisari commented 3 months ago

I am using USB serial intefaces P2P link with simple config as this: [[Serial Interface]] type = SerialInterface interface_enabled = True

Serial port for the device

port = COM18
speed = 115200
databits = 8
parity = none
stopbits = 1

While messages do work, sending files STUCKs forever. Same for Win app and Python app .... I have a gess that my serial interface buffer is limited to 240bytes packets but no idea how add this in inteface's settings.

liamcottle commented 3 months ago

Hey there! Thanks for the report.

I do find that larger files don't send at all, usually over 1MB. I am yet to investigate this...

markqvist commented 1 month ago

The default incoming file limit for LXMF is 1MB, but it can be managed by the user / application with LXMRouter.delivery_per_transfer_limit. Sideband has a user option to manage this, but it's up to the individual application how to handle it.

Apparently, I forgot to add an API function for setting it, but just using setting LXMRouter.delivery_per_transfer_limit (in kilobytes) directly should be fine for now.

liamcottle commented 1 month ago

I updated MeshChat a few versions back to increase the default limit to 10MB.

This will likely become a configurable option in the settings UI down the line.

@markqvist RE files/messages failing to send when over the recipients receiving limit, do you have any thoughts on adding a response (in the link) from LXMF with a "message rejected" or "message exceeds size limit" status in this case? Currently, the LXMF router will just keep trying to send the message again, up until the max attempts, even though this message will never succeed in sending.

markqvist commented 1 month ago

Yes, but I just haven't gotten around to designing the best way to handle it yet. Ideally, it would be something the sender knew beforehand, so it doesn't have to even try delivering a large message if the recipient won't even accept it anyways. There's a few considerations to go through there, though, both implementation and privacy-wise.