~anteater added blocked 4 years ago

~anteater referenced this from #14 4 years ago

~anteater added vgmms 4 years ago

~amindfv 4 years ago

This is my biggest worry about using vgmms as my daily driver (which my PinePhone currently is)

~anteater 4 years ago

So, this is really about general lifetime interaction of ofono, MMSd, and vgmms.

Here's my current understanding of these:

The modem will queue messages until ofono requests them.

vgmms will not (at present) start before the modem is powered on. Once powered on, org.ofono.SimManager provides the subscriber number and vgmms can start. But vgmms won't be able to send messages until the modem is online.

When ofono brings the modem online, it will ask the modem for any pending received messages and notify about them. It then forgets about them, so this is our last chance to hear of them--vgmms must already be running by now. Presumably (I haven't verified yet), MMSd can presumably be started via dbus activation at this point.

Once the modem is online, vgmms can send messages and will receive notifications of any new incoming messages.

The upshot of all this is that we want the following setup sequence:

1. ofono runs
2. mmsd runs
3. modem poweron
4. vgmms runs
5. modem online

and the reverse shutdown sequence:

1. modem offline
2. end vgmms
3. modem poweroff
4. terminate mmsd
5. terminate ofono

This should avoid any loss of incoming messages. But we'll still need #2 to ensure that messages are sent reliably and can be resend if necessary.

~anteater 4 years ago*

How should this be implemented? ofono can be started as a system service, as long as nothing brings the modem online before vgmms is ready. vgmms could automatically ask the modem to come online, but that seems like a side effect that a chat program shouldn't have--I'd prefer system configuration to orchestrate that kind of global changes.

Another way to look at this is: how do ofono-based systems get the modem online right now?

Manjaro is shipping a package of MartijnBraam's ofonoctl with a ofonoctl systemd service.

It runs ofonoctl poweron and ofonoctl online on boot.

Instead of this, I'm envisioning a scheme like the following:

1. run ofono at boot via systemd service (as it does now).
2. ofonoctl poweron via systemd service (similar to now).
3. start MMSd at user login with an unconditional systemd user service.
4. start vgmms with a systemd user service depending on mmsd.service.
5. run ofonoctl online with a systemd user service that waits for vgmms to show up on dbus.
   • this can be done with an Exec entry like gdbus wait -e org.vgmms && ofonoctl online.

The one missing part of this setup sequence is to trigger the rest of what ofonoctl.service does now (ofonoctl wan --connect and ofonoctl wan --append-dns). The latter of these can't be done by user because it writes to /etc/resolv.conf.

~anteater referenced this from #40 4 years ago

~fuzzy7k 4 years ago*

Hmm, In ModemManager, messages are not deleted until it is requested, and purple-mm-sms has an option to enable or disable their deletion. It looks like message deletion is specific to the qmimodem driver because of this turd. If ofono does not do something responsible with the message, I would consider that an ofono bug.

Messages should not be deleted until they are 'received'. Actually receiving the message is out of ofono's scope. That's like the mail man shredding your letter because you didn't answer the door.

~anteater added integration 4 years ago

~fuzzy7k 4 years ago

From what I just witnessed, both ofono & mmsd do the right thing here. I haven't dug too deep on this, but it appeared that ofono held the messages until mmsd retrieved them, and mmsd queued the notifications until it was able to fetch the messages. Maybe this could be implemented with the GetMessages method of mmsd? SMS would need the same attention if all of this checks out.

~anteater 4 years ago

I've been looking into this more. I think it's likely that problems at least some users are having are caused by not using ofonoctl wan --append-dns (and, even then, moving the ofonoctl entries to the top of the file so they're preferred), and in addition there are problems with attempting to put all DNS information in /etc/resolv.conf at all--glibc and other common libcs have MAXNS set to 3, so only 3 nameservers can be listed in this file (between WLAN and WWAN, IPv4, and IPv6), while T-Mobile, for instance, provides 4 nameservers for WWAN alone (2 v4 and 2 v6).

I'm going to patch MMSd to preferentially retrieve DNS settings from ofono's DBus interface rather than the system DNS configuration, which will help with the missing part of the last sequence I described.

~anteater 4 years ago

The patch (which has been pushed to my MMSd repo) works and makes things significantly more robust, but I'm still trying to pin down an ideal setup sequence.

The below works (with Megi's modem power driver, and my patched versions of ofono/mmsd/ofonoctl), but has a window between steps 6 and 8 where MMSes could be missed:

1. cd /sys/class/modem-power/modem-power/device/ || exit 1;
2. echo 1 | sudo tee powered;
3. while [ "$(cat powered)" == "0" ]; do sleep 1; done; cd -
4. sudo ofonod -n -d &
5. ofonoctl poweron
6. ofonoctl online
7. sudo ofonoctl wan --connect
8. /usr/libexec/mmsd -n -d

The problem is that MMSd needs to use network routes applied by sudo ofonoctl wan --connect but should be listening for MMS notifications before ofonoctl online is run.

~anteater 4 years ago

I need to investigate how eg25-manager might help with this, despite the caveat that it seems to integrate with ModemManager but not ofono at present.

~anteater referenced this from #69 4 years ago

~anteater REPORTED FIXED 3 years ago*

With the current state of eg25-manager, mmsd-tng, and ModemManager, I believe this is resolved when using the following initialization sequence:

1. boot
2. run ModemManager
3. start vgmms
4. start mmsd-tng

It would be nice to fix this for ofono too, but a single working stack is enough for me for now.