USB serial interface malfunction

[sisari]

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]

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...

• Have you tried sending a smaller file? Something around 20KB?
• Have you tried using Sideband with the same config? Does the file that fails in MeshChat work in Sideband?

[markqvist]

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]

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

• 117b02c

• reticulum-meshchat/meshchat.py

  Line 114 in c92ddac

  self.message_router.delivery_per_transfer_limit = self.config.lxmf_delivery_transfer_limit_in_bytes.get() / 1000

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]

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.