~anteater 4 years ago

I've redacted your subscriber identity (IMSI), which is private information.

This looks identical to this behavior, which may be a bug in ofono. Do the ofono tools show a SubscriberNumber for you?

If not, please file a bug upstream with ofono at their mailing list. If ModemManager is able to determine the subscriber number, please mention that.

~anteater 4 years ago

Since this looks like an ofono issue, the most useful information would be your ofono logs. Those are likely to contain identifying information, so be careful to redact them or ask someone knowledgeable to do so before posting them publicly.

~amindfv 4 years ago

Yikes thanks, I didn't see anything identifying but apparently I missed.

~amindfv referenced this from #27 4 years ago

~anteater added user support 4 years ago

~anteater added ofono 4 years ago

~anteater 4 years ago

I've looked into this more, and it would really help if you could provide some more information.

1. If you don't mind divulging, what service provider do you use? I'm mostly wondering if it's AT&T, which was also mentioned by the other user who had empty SubscriberNumbers. If you're not comfortable saying, that's fine--it might be obviated by the more technical questions below.

2. You mentioned this behavior seems to come and go. Can you verify this, and have you found any pattern to it?

3. What stack are you using such that SMS and calls work with this SIM? If it's ModemManager (the default for Mobian), can you see if MM knows the subscriber number? Run mmcli -m 0 and look for a line in the output like the following:

   Numbers     |     own :   'xxxxxxxxxxx'
   

   I've been looking at how MM finds the subscriber number (called OwnNumber in MM's codebase), and it seems to use the AT+CNUM AT command (whereas I believe ofono is reading the MSISDN file from the SIM storage--in sim_msisdn_read_cb in src/sim.c). It might be necessary to add code to ofono to fall back to AT+CNUM if the MSISDN doesn't specify the subscriber number. Apparently this is known practice among a number of operators, and up to their whim.

4. Could you see whether manually running the AT+CNUM AT command returns your number? It may be necessary to end all daemons managing the modem before trying this (and possibly reboot without them starting--I had to reboot after systemctl disable ofono before it would give any output, but subsequently the command did return my number).

   $ echo 'AT+CNUM' | sudo atinout - /dev/EG25.AT - 
   

And finally, a possible workaround suggested by this research: the ofono source tree has a script at test/set-msisdn that may be able to write to the MSISDN file on the SIM. If you're feeling brave, you can see if running the following succeeds, and if it makes ofono and MMSd (and hopefully, vgmms MMS support) work:

test/set-msisdn <your number with country code but no leading +>

~anteater 4 years ago

There also seems to be a third way to find the subscriber's number (for Qualcomm modems that can be accessed over the QMI protocol, such as the one in the PinePhone)--the QMI_DMS_GET_NUMBER command. But there isn't any indication that MM or ofono uses this approach at present.

~anteater closed duplicate ticket #30 4 years ago

~amindfv 4 years ago

1. Not AT&T; a T-Mobile reseller

2. The error I get changes - and for that I haven't yet found the pattern - but I've never been able to get or receive a group thread, seemingly implying that if this is the same as #30, the problem just manifests in different ways

3. By default (with Mobian) it's using ModemManager, but when I kill that and start ofono, I can send and receive 1:1 SMS messages. Calls with ofono are not working yet but the program supposedly supports ofono

When I run "mmcli -n (number)" (note this often isn't zero - I have to call "mmcli -L" to find which number my modem's currently at), I see:

• After I've killed ModemManager to start vgmms, "mmcli -n (#)" does not display a "Numbers" line
• After re-starting with "sudo service ofono stop && sudo systemctl start ModemManager", it still does not display a "Numbers" line
• After re-starting the phone, yes, I see a ton more information, including my number in the "Numbers" section

1. My phone doesn't have atinout or /dev/EG25.AT

---

Also:

Can you clarify what "feeling brave" means in your possible workaround? I assume I risk messing up my SIM card or configuration?

Note I'm also doing

sudo systemctl stop ModemManager

but

sudo service ofono start

I assume it's fine to use service instead of systemctl here?

~anteater 4 years ago*

Thanks for all the info and investigation!

Your answers mostly confirm my existing suspicions. I can try to write a patch for ofono that uses AT+CNUM to get the subscriber number and see if that helps the situation.

It would still be nice to know if AT+CNUM does indeed work for you. You don't need /dev/EG25.AT, but it's a less ambiguous name many distros set up for the modem's AT serial interface, which also lives at /dev/ttyUSB2. atinout is a command that simplifies writing to AT modems, but it can be done without it--in one terminal, run sudo cat /dev/ttyUSB2. While the cat command is running, in a second terminal, run echo -en 'AT+CNUM\r' | sudo tee /dev/ttyUSB2. If the cat command prints your number (amidst commas, some noise, and whitespace), then this approach is viable.

re: 4., yes, I can't guarantee that running the command won't do anything bad to your SIM. It should just write to a file that stores saved numbers, so the worst I would expect is to overwrite saved contacts on your SIM, if there are any deleterious effects at all. But SIM software and modem firmware are notoriously buggy proprietary crap, and I haven't tried it myself, so I can't make any promises.

service should be fine if you aren't getting any errors. You can always verify with pgrep/top/htop whether the service did start/stop or not.

~amindfv 4 years ago

If the cat command prints your number (amidst commas, some noise, and whitespace), then this approach is viable.

It works!

~amindfv 4 years ago

To be thorough I tested this both while ModemManager was running and while ofono+mmsd+vgmms was running. It returned the phone number in all cases.

~amindfv 4 years ago

Is the issue just not being able to easily get the subscriber number? If so, is it possible to add a workaround, e.g. just providing the subscriber number as a command line argument?

~anteater 4 years ago

The best place for such a workaround is probably ofono, and probably it just looks like using set-msisdn (which simply calls the DBus interface to write to SubscriberNumbers). If you're really worried about writing to the SIM, you can hack out the actual write to the file on the SIM--ofono uses its own cached value after initialization, so the write to the modem is useful for persistence but not necessary for a workaround.

~amindfv 4 years ago

If you're really worried about writing to the SIM, you can hack out the actual write to the file on the SIM

Does this mean simply commenting out this line in ofono/test/set-msisdn?:

sim.SetProperty("SubscriberNumbers", [number]);

~anteater 4 years ago

No, that would prevent anything from happening at all.

I'll see if I can put together a small patch that does what I mean.

~anteater 4 years ago

~amindfv, here's a patch. It should make set-msisdn perfectly safe from a "doesn't touch the SIM" standpoint, and might let you get vgmms working. Changes to your subscriber number with this patch won't be persistent, but you can see if things work.

I'm still going to get around to trying to fix reading the SubscriberNumber from the modem properly, but there are a lot of demands on my time right now.

~amindfv 4 years ago

~anteater thank you! As I mentioned, my pinephone is my daily driver and I'm getting lots of complaints from friends unable to send group messages and images, so help is very much appreciates!

Here's what I did:

cd ~/mmsd/ofono
patch src/sim.c 0001-fake-set-SubscriberNumbers.patch
./bootstrap-configure
vim Makefile # remove the '-Werror'
./configure --prefix=/usr --sysconfdir=/etc --sbindir=/usr/bin
make && sudo make install
sudo systemctl stop ModemManager
sudo service ofono start
/usr/libexec/mmsd -n -d

# in a new terminal, since the above is running not as daemon:

~/mms/ofono/test/enable-modem
~/mms/ofono/test/set-msisdn '<number, starting with 1 for US>'
RUST_BACKTRACE=1 ~/mms/vgmms/target/release/vgmms

# in a third window:

 ~/mms/ofono/test/online-modem

However, I still see this error when attempting to send group messages:

MMS notification parse error: MissingSender

In the mmsd window, the only "suspicious" thing my untrained eyes see is lines like this:

mmsd[2498]: Fail to get data (http status = 404)
mmsd[2498]: retry later

~amindfv 4 years ago

I seem to recall doing something very hacky with mmcli a week or so ago that was getting 404s (as above) when attempting to retrieve messages. The solution - if I'm recalling this right - was to turn wifi off so that the wget requests I was making were going through the modem.

Is it possible that's relevant to this scenario? I did run the above with wifi turned on.

~amindfv 4 years ago

I just restarted my phone and ran all steps above except for the ofono re-install (everything after make && sudo make install) with the wifi turned off. Same error.

~anteater 4 years ago

One thing to note: do not run ./bootstrap-configure, as this passes --enable-maintainer-mode which leads to the sktest test modem being present. --enable-maintainer-mode and bootstrap-configure are intended for ofono maintainer usage, not end-user usage. You should be able to instead do something like:

./bootstrap && \
    ./configure
		--prefix=/usr \
		--mandir=/usr/share/man \
		--sysconfdir=/etc \
		--localstatedir=/var

The same is true for mmsd.

But I don't think that's necessarily causing the behavior you're seeing here. See if the test/list-modems tool shows the number you expect after running the set-msisdn script; make sure ofono has the right number before starting MMSd.

The 404 may be related to your telco's MMS interface; some require the MMSC to be contacted over the data connection, over IPv6 using the data connection, or using a special context (contexts allow the modem to provide several separate IP connections, each with different limitations and metering; some telephone companies' MMS centers will only respond when contacted over an MMS context).

These are all alternatives to something called GBA (Generic Bootstrapping Architecture) which allows the modem and service provider to work together to produce a token proving that the holder of the token is authorized to act on the modem's behalf. This token is then used when performing WiFi calling or interacting with the MMSC over WiFi, to prove that it's your telephone even though the device is connecting over an unrelated network path. Unfortunately there are to my knowledge no open-source implementations of GBA--on Android, for example, T-Mobile ships a closed-source blob sometimes referred to as gba-service-TMO-Signed.apk.

In my experience with T-mobile, I've found that using the modem's IPv6 connection works to enable downloading messages from the MMSC, but the MMSC IP address must also be looked up with DNS servers provided to the modem. This involves ofonoctl wan --append-dns and some manual editing of /etc/resolv.conf. I'm hoping to find a way to make all this less fiddly in the future.

So--first, verify whether the number hack works to change the number ofono shows, and see if that lets vgmms always start correctly. Then play with network settings and see if you can get mmsd to download MMS messages. I'm working on changes to ofono and mmsd to make MMS on T-Mobile work more robustly, but they're not finished yet.

~amindfv 4 years ago

Thanks.

You said

make sure ofono has the right number before starting MMSd

But

sudo systemctl stop ModemManager
sudo service ofono start
~/mms/ofono/test/enable-modem
~/mms/ofono/test/set-msisdn '<my-number-here>'

But it gave this error:

Setting MSISDN for modem /quectelqmi_0...
Traceback (most recent call last):
  File "/home/mobian/mms/ofono/test/set-msisdn", line 24, in <module>
    sim.SetProperty("SubscriberNumbers", [number]);
  File "/usr/lib/python3/dist-packages/dbus/proxies.py", line 72, in __call__
    return self._proxy_method(*args, **keywords)
  File "/usr/lib/python3/dist-packages/dbus/proxies.py", line 141, in __call__
    return self._connection.call_blocking(self._named_service,
  File "/usr/lib/python3/dist-packages/dbus/connection.py", line 652, in call_blocking
    reply_message = self.send_message_with_reply_and_block(
dbus.exceptions.DBusException: org.freedesktop.DBus.Error.NoReply: Did not receive a reply. Possible causes include: the remote application did not send a reply, the message bus security policy blocked the reply, the reply timeout expired, or the network connection was broken.

(I ran the same command 3 times in a row; same error each time)

I then ran

/usr/libexec/mmsd -n -d

# then in a new terminal:

mms/ofono/test/set-msisdn '<num>'

Same error again.

Then

mms/ofono/test/enable-modem
mms/ofono/test/set-msisdn '<num>'

Same error.

~amindfv 4 years ago

Gah now after a restart I'm getting this consistently:

sudo systemctl stop ModemManager
sudo service ofono start
/usr/libexec/mmsd -n -d

new terminal:

$ ~/mms/ofono/test/enable-modem
Connecting modem <modem>
  File "/home/mobian/mms/ofono/test/enable-modem", line 20, in <module>
    modem.SetProperty("Powered", dbus.Boolean(1), timeout = 120)
  File "/usr/lib/python3/dist-packages/dbus/proxies.py", line 72, in __call__
    return self._proxy_method(*args, **keywords)
  File "/usr/lib/python3/dist-packages/dbus/proxies.py", line 141, in __call__
    return self._connection.call_blocking(self._named_service,
  File "/usr/lib/python3/dist-packages/dbus/connection.py", line 652, in call_blocking
    reply_message = self.send_message_with_reply_and_block(
dbus.exceptions.DBusException: org.ofono.Error.Timedout: Operation failure due to timeout

~anteater 4 years ago*

It sounds like ofono is crashing. Try running it under gdb (instead of sudo service ofono start):

sudo gdb -ex run --args /usr/bin/ofonod -n -d

Edit: added missing d to ofonod.

~amindfv 4 years ago

I needed to run /usr/bin/ofonod (with a 'd'), but when I did it appeared to run normally.

sudo systemctl stop ModemManager
sudo gdb -ex run --args /usr/bin/ofonod -n -d

There were a bunch of lines like

ofonod[5108]: plugins/udevng.c:add_serial_device() Device is missing required OFONO_DRIVER property

Then, new terminal:

~/mms/ofono/test/enable-modem
~/mms/ofono/test/set-msisdn '<num>'   # It worked this time!
/usr/libexec/mmsd -n -d

New terminal 3:

RUST_BACKTRACE=1 ~/mms/vgmms/target/release/vgmms

New terminal 4:

~/mms/ofono/test/online-modem

Same behavior - sending group messages doesn't work; sending 1:1 messages does.

~/mms/ofono/test/list-modems

Returns a bunch of information, including:

    [ org.ofono.SimManager ]
[...]
        SubscriberNumbers = <my_number>

~amindfv 4 years ago

When it fails to send group messages, the vgmms output is still

inserting send (id) MessageInfo { sender: Number { num: (my_num) }, (rest_of_msg)
MMS notification parse error: MissingSender

~anteater referenced this from #42 4 years ago

~anteater 3 years ago

Can you see if this commit improves behavior for you at all?

If not, it's likely this needs to be fixed on the MMSd side, and the most illustrative testing might be done with its test/send-message script.