eeeeeta / matrix-appservice-sms Goto Github PK

matrix-appservice-sms[2275]: note: Run with `RUST_BACKTRACE=1` for a backtrace.
matrix-appservice-sms[2275]: thread '<unnamed>' panicked at 'urc_rx stopped producing', libcore/option.rs:917:5
matrix-appservice-sms[2275]: Error: HuaweiModemFuture failed: an error occurred when formatting an argument
matrix-appservice-sms[2275]: Sending part 1/1...

essentially, we need the whole bridge to crash & burn whenever the future dies, so systemd can restart it. otherwise, requests just 500 and everything stops.

This was a bit of a stupid oversight.

If you use your modem with software that sends SMS-SUBMIT PDUs and stores them in the STO SENT/STO UNSENT memory, our parser breaks, because it currently only expects SMS-DELIVER PDUs despite asking for all messages (including outgoing ones). This is stupid. We should do one of the following:

• not ask for messages we can't handle
• figure out which PDU type it is by which memory store it's in, and parse intelligently

We should also, like, consider making AT+CMGL more failure-tolerant. If one person sends you a bad PDU (although that shouldn't be doable), they could break everything. That's no fun.

As seen in #13, if we fail to deliver a message, it just gets dropped on the floor. That's less than ideal. Ideally, we'd stash it in the DB somewhere, and retry delivery with a backoff, alerting the user (if possible) that this is happening.

this is stupid:

May 22 14:13:54 nichtsdestoweniger matrix-appservice-sms[20290]: +CMGL complete
May 22 14:13:54 nichtsdestoweniger matrix-appservice-sms[20290]: Processing message received from 3Message
May 22 14:13:54 nichtsdestoweniger matrix-appservice-sms[20290]: Processing message received from 3Message
May 22 14:13:54 nichtsdestoweniger matrix-appservice-sms[20290]: Registering new user @_sms_D0517710111511597103101:theta.eu.org
May 22 14:13:54 nichtsdestoweniger matrix-appservice-sms[20290]: Registering new user @_sms_D0517710111511597103101:theta.eu.org
May 22 14:13:55 nichtsdestoweniger matrix-appservice-sms[20290]: Creating new room
May 22 14:13:55 nichtsdestoweniger matrix-appservice-sms[20290]: Creating new room
May 22 14:13:55 nichtsdestoweniger matrix-appservice-sms[20290]: Error: Failed to process received message: Error from homeserver: BadRequestReply { errcode: "M_UNKNOWN", error: Some("Room alias already taken") }        

Essentially, we need to create a new table for new users, and do some fancy SQL locking magic to ensure that only one person tries to create a new user at a time.

Actually, wait, no, that ain't gonna work, because this is futures, so we can't do locking. You'd probably use a mutex.

Except we ain't got none of those, because this is futures. So, I guess we just use message-passing like it says in that issue thread, and make new-user-messages linear. That'd probably work.

I have a Huawei E173u-2 now, which has this functionality!

Currently, sending images &c is kinda borked, because the recipient just gets a mxc:// URL.

People running the bridge may want to keep a track of how many messages they've sent, in order to figure out when they need to top up a PAYG SIM. We should keep a track of that in the DB, and alert the user in the admin room at 90%, 95%, etc. of quota used (where the quota should be user-configurable).
(Also, if we wanted to go full Snapchat, we could adapt this feature into one of those garbage messages sent:received ratio things...)

if the bridge crashes, we want to ensure that we read any messages when the bridge starts up again, so stuff gets delivered. currently we just wait for +CNMI, which is less than ideal.
(come to think of it, polling for messages every ~10min or something wouldn't be a bad idea either)

(this is mostly a note to self tbh)

i.e. keep a track of SMSes sent, and allow for configurable warnings in order to manage pay-as-you go SIMs and stuff

Currently, we just log errors to stdout, which doesn't help anybody except the most vigilant of server admins. We should also log errors to the admin room, so the user actually knows when things go wrong.

It would be great to do that in order to use a SIM card as a family number, forwarding messages to all family members, and being able to forward answers and conversations to people using SMS. That would also be great in order to do conferencing including multiple users on both sides

When starting back up, refuse to send events with an origin_server_ts too far back in the past. Also, warn loudly about dropping said messages.

1. Our reception of new messages is entirely dependent on CNMI indications; we should probably also poll every so often, just to be doubly sure
2. Currently, the bridge just flat-out breaks if your modem doesn't support sending +CNMI indications on new messages.

So yeah, we probably need some polling functionality as well.

If we process multiple CSMS parts in parallel, two attempts to set the room state can race with each other, meaning that we clobber one of the CSMS parts with the other :(

To be honest, the messages aren't dropped on the floor, because this is Matrix; we should be able to get at them with some room state poking. Still, not fun.